Nimrod programming language

[Mensanator]

On May 11, 4:55 pm, rump... at web.de wrote:
> On 10 Mai, 10:40, Paul Rubin <http://phr...@NOSPAM.invalid> wrote:> Andreas Rumpf <Rump... at web.de> writes:
> > > I invented a new programming language called "Nimrod" that combines
> > > Python's readability with C's performance. Please check it out:
> > >http://force7.de/nimrod/Anyfeedback is appreciated.
>
> > Looks nice in many ways.  You also know about PyPy and Felix
> > (felix.sf.net)?
>
> Nimrod has very different goals from PyPy, I cannot comment on Felix.
>
> > It seems a little bit hackish that the character type is a byte.
> > Python did something like that but it ended up causing a lot of
> > hassles when dealing with real Unicode.  I think you have to bite
> > the bullet and have separate byte and char types, where char=unicode.
>
> I am dissatisfied with Python's (or Java's) Unicode handling:
> 1) IO overhead to convert UTF-8 (defacto standard on UNIX) into
> UTF-16.
> 2) For simple tasks the output file will be in the same encoding as
> the input file automatically.
> 3) Most text files have no header specifying the encoding anyway. How
> should the programm/programmer know? And often he does not need to
> know anyway.
> 4) UTF-16 (or 32) use more memory.
> 5) In particular using UTF-16 internally does not make sense: It just
> encourages programmers to ignore surrogates. Unicode has more than
> 2^16 characters nowadays.
>
> > It scares me a little about how there are references that can have
> > naked pointers, escape the gc, etc.  It would be good if the type
> > system were powerful enough to guarantee the absence of these effects
> > in some piece of data, unless the data is somehow marked with an
> > "unsafe" type.
>
> Well "ptr" is unsafe, "ref" is not; mixing the two requires a "cast".
> Basically "cast" is the only unsafe feature.
>
> > I'd like to see ML-like algebraic types with pattern matching, not
> > just tuple unpacking.  
>
> Me too.
>
> > The generic system should be able to analyze the AST of type
> > parameters, e.g. iterator<T> would be able to automatically generate
> > an iterator over a list, a tree, or some other type of structure, by
> > actually figuring out at compile time how T is constructed.
>
> Interesting idea. Right now the generic iterator is named "items" and
> can be overloaded for user-defined types.
>
> > It's sort of surprising that the compiler is written in a Pascal
> > subset.  Why not implement in Nimrod directly, and bootstrap through C?
>
> That is already the case: The Pascal version is translated to Nimrod
> and than compiles itself. Bootstrapping works.
>
> > The language and library are missing arbitrary precision integer
> > arithmetic, using GMP or something like that.
>
> True, but currently not a high priority for me.

Too bad. That makes Nimrod officially "worthless", i.e., of no
value to me.

>
> > It would be good to also be able to have value serialization and
> > deserialization to both human readable (nested lists, etc) and binary
> > (for IPC) formats.
>
> Yes. Planned for version 0.9.0.
>
> > It's not obvious from the blurbs whether simple functional programming
> > is supported, e.g. how would you implement a function like "map" or
> > "filter"?  What would the types be of those two functions?
>
> proc map[T, S](data: openarray[T], op: proc(x: T): S): seq[S] =
>   result = @[]
>   for d in items(data): result.add(op(d))
>
> Or - if you don't want the "openarray[T]" restriction:
> proc map[T, S, U](data: T, op: proc(x: U): S): seq[S] =
>   result = @[]
>   for d in items(data): result.add(op(d))
>
> > The roadmap says you might implement threading with transactional
> > memory.  How will the transactional memory interact with mutable data?
> > Are you going to use OS threads, lightweight threads, or both?
>
> Probably both. Lightweight threads could be done using coroutines and
> explicit task switching. OS threads with transactional memory. The
> plan is to use LLVM as a backend and perhapshttp://tinystm.org/. Of
> course, this is only wishful thinking. ;-)