Nimrod programming language

[Paul Rubin]

rumpf_a at web.de writes:
> 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.

So use UTF-8 internally.  You can still iterate through strings
efficiently.  Random access would take a performance hit.  When that's
an issue, the programmer can choose to use a char array (char =
UCS-4).  The same generic functions could largely handle both types.
 
> That is already the case: The Pascal version is translated to Nimrod
> and than compiles itself. Bootstrapping works.

I meant why not get rid of the translation step and implement the
compiler in idiomatic Nimrod.


> 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))

This is hard for me to comprehend but I mayb look at the docs to try to
figure it out.

> The plan is to use LLVM as a backend and perhaps
> http://tinystm.org/. Of course, this is only wishful thinking. ;-)

Oh cool, I didn't know about tinystm.  But, my question about
mutability is how you protect STM transactions when other threads can
have references into shared mutable structures and clobber the
referents.  GHC uses its type system to prevent that, but I don't see
how Nimrod can really do the same, especially without GHC's rich set
of immutable types including stuff like immutable maps.

Have you ever looked at Tim Sweeney's presentation "The Next
Mainstream Programming Language"?  It's at:

http://www.st.cs.uni-saarland.de/edu/seminare/2005/advanced-fp/docs/sweeny.pdf