Nimrod programming language

[bearophileHUGS at lycos.com]

rump... at web.de:
> Eventually the "rope" data structure (that the compiler uses heavily)
> will become a proper part of the library:

Ropes are a complex data structure, that it has some downsides too.
Python tries to keep its implementation too simple, this avoids lot of
troubles (and is one of the not much visible design ideas that have
determined the success of Python).

--------

I've seen that in Nimrod the following names are the same one:
justaname JustAName just_a_name just__aname Justaname

So like Pascal (and unlike Python/C) it doesn't tell apart names just
on the base of their case (this is positive for newbie programmers,
they usually use the convention of natural written language where
'Hello' and 'hello' are the same word, they need some time to learn
the case-sensitivity).

Nimrod also seems to ignore underscores inside names, seeing them as
blanks. Some languages ignore underscores inside number literals, but
I have never seen a language ignoring them into names too.

In a class if you have a method like:
change_table_color
Isn't much good to also have a method named:
changeTableColor
Good programming practice tells you to avoid names that can be
confused (as 'chop' and 'chomp' in the string functions of D Phobos
lib). To avoid that most languages adopt a convention, so for example
in Python the change_table_color is the only used name, Java uses
changeTableColor, etc. Such conventions solve most of such problems.

So I don't know how much I like this design detail of Nimrod.

In Python you often see code like:
node = Node()

Sometimes in a case-sensitive language I'd like to have a compilation
warning switch that tells me that in a namespace there are two or more
names that differ only on character case or underscore count. This may
help avoid some bugs. A language may even enforce this as a syntax
error, so you have to write things like:
n = Node()
Or:
anode = Node()

Bye,
bearophile