Nimrod programming language

[rumpf_a at web.de]

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/Any feedback 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.

> 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 perhaps http://tinystm.org/. Of
course, this is only wishful thinking. ;-)