Nimrod programming language

[Andreas Rumpf]

Dear Python-users,

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.

Regards,
Andreas Rumpf

______________________________________________________
GRATIS für alle WEB.DE-Nutzer: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://movieflat.web.de

 

[kay]

Dear Python-users,

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.

Regards,
Andreas Rumpf

______________________________________________________
GRATIS für alle WEB.DE-Nutzer: Die maxdome Movie-FLAT!
Jetzt freischalten unterhttp://movieflat.web.de

On a first impression it looks quite pleasant to me, your new
language! Two obvious questions on a Python list.

1) How to interface with Nimrod from Python?
2) Lack of typed hash-tables. Is this one of those particular features
that are planned to be implemented in version 0.80 and summarized
under "generic containers"?

 

[Paul Rubin]

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?

 

[Paul Boddie]

Looks nice in many ways.  You also know about PyPy and Felix
(felix.sf.net)?

Try http://felix-lang.org/ for the latter, I believe.

Paul

 

[Florian Wollenschein]

Dear Python-users,

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.

Regards,
Andreas Rumpf

______________________________________________________
GRATIS für alle WEB.DE-Nutzer: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://movieflat.web.de

Looks really interesting. I think I'll give it a try later on.
Thanks for your announcement.

Reagrds,
Listick
http://www.listick.org

 

[rumpf_a]

On a first impression it looks quite pleasant to me, your new
language! Two obvious questions on a Python list.

1) How to interface with Nimrod from Python?
2) Lack of typed hash-tables. Is this one of those particular features
that are planned to be implemented in version 0.80 and summarized
under "generic containers"?

1) Via a wrapper that is in the works. It will work like embedding
Python into a C application.
2) Yes. Some syntactic sugar will probably be provided, e.g. a
constructor {} like Python. However, I have not made my mind
completely: Maybe they should be built-in? This would allow more
optimizations.

 

[rumpf_a]

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 =
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 =
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. ;-)

 

[Mensanator]

Nimrod has very different goals from PyPy, I cannot comment on Felix.


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.


Well "ptr" is unsafe, "ref" is not; mixing the two requires a "cast".
Basically "cast" is the only unsafe feature.


Me too.


Interesting idea. Right now the generic iterator is named "items" and
can be overloaded for user-defined types.


That is already the case: The Pascal version is translated to Nimrod
and than compiles itself. Bootstrapping works.


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 =
  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 =
  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. ;-)

 

[Paul Rubin]

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

 

[Lawrence D'Oliveiro]

In message <57f4c81a-3537-49fa-a5f6-

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.

Are you sure they're using UTF-16? I would use UCS-2 or UCS-4.

 

[rumpf_a]

The language and library are missing arbitrary precision integer

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

Well, you could write a wrapper for GMP (and contribute to the
project ;-)).

 

[rumpf_a]

That is already the case: The Pascal version is translated to Nimrod

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

Not until version 1.0 is out. This way the language can evolve more
easily.

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.

Well STM transactions in an imperative context are still being
actively researched. Sorry I have no better answer.

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

Yes. It's awsome. But the next mainstream programming language also
needs a massive amount of money to take off, so I don't think it will
be Nimrod.

 

[Mensanator]

Well, you could write a wrapper for GMP (and contribute to the
project ;-)).

But such a thing already exists in Python. And I spend my time
USING arbitrary precision numbers to do math research.

Just thought you'ld like to be aware that some people actually
make their language choices based on the availability (and
performance)
of arbitrary precision numbers.

 

[George Sakkis]

But such a thing already exists in Python. And I spend my time
USING arbitrary precision numbers to do math research.

Just thought you'ld like to be aware that some people actually
make their language choices based on the availability (and
performance)
of arbitrary precision numbers.

I'm sure developers of a new language have to deal with much more
pressing issues before accommodating each and every self important
niche.

 

[namekuseijin]

Dear Python-users,

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.

heh, looks more like a streamlined Object Pascal (i.e class
declarations) than Python. And indeed I see that it has a nice bridge
to old Object Pascal code.

OTOH, Python always felt to me very close to Pascal in the choice of
syntax keywords and readability. Some people of late have been
comparing Python to Basic, but I guess that's only to widespread it
more among the american public, where Pascal as foreign tech never
quite grasped foot.

 

[Mensanator]

I'm sure developers of a new language have to deal with much more
pressing issues before accommodating each and every self important
niche.

If he gets enough feedback, won't he learn which niches are important
enought to accommodate? Such feedback was solicited, was it not? If
he
has more pressing issues to deal with, why is he trolling here?

 

[Dikkie Dik]

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.

What? Off COURSE texts have no header stating the encoding! And it is
the programmer's responsibility to know what a text's encoding is. So do
not ignore HTTP headers when downloading or other means of communicating
the encoding.

That is the whole problem with texts represented as strings. A string is
a free sequence of bytes, whereas a text is a free sequence of
characters WITH AN ENCODING. This may be a default encoding, but you
must still know which one that is. That is your JOB as a programmer.

Putting the encoding as some sort of header in the string itself is the
worst "solution" that has ever been proposed. Do you put the only key to
a safe inside the very same safe and lock it? Then why do you have to
hack a string (is is not a text as it is not accompanied by an encoding)
to see what encoding is hidden inside?

Ask yourself: would the following "headers" ever work (each given in the
stated encoding off course)?

<meta http-equiv="Content-type" Value="text/html;charset=iso-8859-1">
<meta http-equiv="Content-type" Value="text/html;charset=utf-8">
<meta http-equiv="Content-type" Value="text/html;charset=utf-7">
<meta http-equiv="Content-type" Value="text/html;charset=utf-16">
<meta http-equiv="Content-type" Value="text/html;charset=utf-32">
<meta http-equiv="Content-type" Value="text/html;charset=ebcdic">