Nimrod programming language

Paul Rubin http
Sun May 10 04:40:56 EDT 2009


Andreas Rumpf <Rumpf_A 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)?

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.

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.

I'd like to see ML-like algebraic types with pattern matching, not
just tuple unpacking.  

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.

It's sort of surprising that the compiler is written in a Pascal
subset.  Why not implement in Nimrod directly, and bootstrap through C?

The language and library are missing arbitrary precision integer
arithmetic, using GMP or something like that.

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.

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?

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?



More information about the Python-list mailing list