Case is insignificant in Nimrod and even underscores are ignored:
This_is_an_identifier and ThisIsAnIdentifier are the same identifier. This
feature enables you to use other people's code without bothering about a naming
convention that conflicts with yours. It also frees you from remembering the
exact spelling of an identifier (was it parseURL or parseUrl or parse_URL?).<

So the "_" is not usable, and if you search for names in the code you need to
set it to ignore underscores.
-------------------

Comments are tokens; they are only allowed at certain places in the input file
as they belong to the syntax tree! This feature enables perfect
source-to-source transformations (such as pretty-printing) and superior
documentation generators.<

-------------------

Hexadecimal literals are prefixed with 0x, binary literals with 0b and octal
literals with 0o. A leading zero alone does not produce an octal.<

-------------------

To call a procedure that returns a value just for its side effects and ignoring
its return value, a discard statement has to be used. Nimrod does not allow to
silently throw away a return value:<

Automatic type conversion in expressions with different kinds of floating point
types is performed: the smaller type is converted to the larger. Integer types
are not converted to floating point types automatically and vice versa. The
toInt and toFloat procs can be used for these conversions.<

-------------------
It has integral subranges (ranged types of Pascal, Ada):
type
TSubrange = range[0..5]
-------------------
One of the compilation options is to turn on "hints" (there are warnings and
errors too):
hints on|off Turns the hint messages of the compiler on or off.
-------------------
Overall it looks like a quite nice language. I have not tried to program with
it yet.
Bye,
bearophile

Overall it looks like a quite nice language. I have not tried to progra=

=20

of your posts here ;)). You can find some performance benchmarks
here: https://bitbucket.org/jmb/shootout/wiki/Home
IMO the concept is interesting (especially the Python-like syntax
for a compiled language), but there are a lot of rough edges and
development is very slow.
Jerome
--=20
mailto:jeberger free.fr
http://jeberger.free.fr
Jabber: jeberger jabber.fr

Thank you for the link, I will carefully read your Nimrod implementations.

IMO the concept is interesting (especially the Python-like syntax
for a compiled language),

There several other examples of the same thing (like the Python compiler I'm
helping the development, ShedSkin), Boo, etc.

but there are a lot of rough edges and development is very slow.

Nimrod seems to contain no new ideas, and probably some large ideas of D2 are
missing, but the syntax and some smaller details are nice.
The authors of Nimrod seem kind of the opposite of this language designer that
was famous in the Amiga scene. This person keeps trying to invent something
sharply different from the languages we use today (and someday I think he will
produce something very good):
http://strlen.com/programming-languageshttp://strlen.com/language-design-overview
Bye,
bearophile

Our initial plan with D2 was to include AST macros, but we decided to see how
string mixins swim and defer macros to D3. The D forums are virtually silent on
the topic of macros now, and it's definitely not because the community is being
coy :o).<

You are right that lately no serious discussions have happened here about AST
macros. But the causes are not coyness or because string mixins are good
enough. I think the causes are:
- AST Macros a not a minor feature, they require some time and thinking to
design them well, some syntax support, some code in the front-end, some
documentation for users, and some time to learn to use them.
- D2 has many bugs and some unfinished parts. Most people here know that adding
more features now is not right. And generally Walter and you are (rightly)
adding major new features to D2 right now. Once D2 is more finished and
debugged some discussions about AST macros may start again.
- Lot of people here probably are not experienced with AST macros.
- I like the idea of AST macros, they are powerful, but they add a significant
amount of complexity to the language. So I am not pushing a lot for them,
despite I almost hate string mixings and creating code with string snippets.
--------------------
kapilash :

The forum I was referring to had too many useless discussions about the length
of the word "immutable", unnecessary arguments about D vs other languages and
far too much emphasis on reddit.<

I don't mark threads as this "Nimrod language" as OT because a new language
like D2 must keep eyes open on other new languages and some computer science.
Bye,
bearophile

This language looks *very* interesting and sensibly designed. The author se=
ems to have taken, in addition to much input from C-like languages and Pyth=
on, the best of the Pascal line tradition. Also, he obviously "dared" getti=
ng rid of some legacy garbage. Unfortunately, not all, and took dome more. =
(Even reproduced "elif" and kept the stupid ':' of Python ;-).
On Sat, 01 Jan 2011 13:00:15 -0500
bearophile <bearophileHUGS lycos.com> wrote:

I show some Nimrod features [...]

=46rom the tutorial:
"Parameters are constant in the procedure body. Their value cannot be chang=
ed because this allows the compiler to implement parameter passing in the m=
ost efficient way. If the procedure needs to modify the argument for the ca=
ller, a var parameter can be used"
Bravo! For me, the primary effect is not allowing optimisation, but that no=
w "parameter" means parameter; so that one can reason about the code.
Denis
-- -- -- -- -- -- --
vit esse estrany =E2=98=A3
spir.wikidot.com

Python doesn't have the switch statement, so to write a switch you sometimes
use a sequence of if statements, in this case "elif" helps keep the code more
tidy:
x = 3
if x == 0:
pass
elif x = 1:
pass
else:
pass

and kept the stupid ':' of Python ;-).

It comes from usability studies on the ABC language. If you are going to use a
Python-like syntax, then removing those ":" is stupid.

"Parameters are constant in the procedure body. Their value cannot be changed
because this allows the compiler to implement parameter passing in the most
efficient way.

I have missed that part of the docs. What kind of "most efficient way"?
Bye,
bearophile

However, ABC’s authors did invent the use of the colon that separates the
lead-in clause from the indented block. After early user testing without the
colon, it was discovered that the meaning of the indentation was unclear to
beginners being taught the first steps of programming. The addition of the
colon clarified it significantly: the colon somehow draws attention to what
follows and ties the phrases before and after it together in just the right
way.<

Python doesn't have the switch statement, so to write a switch you someti=

e more tidy:

=20
x =3D 3
if x =3D=3D 0:
pass
elif x =3D 1:
pass
else:
pass

Sorry, my words were too imprecise; and too strong for such a little issues=
. I aggre with you, but it's not my point (I wrote "elif" in quote: it's ab=
out the term). "elif" is nearly unguessable: should be "elseif" or "elsif" =
(--> Lua does it right).

and kept the stupid ':' of Python ;-).

Sorry again, for "stupid".=20

It comes from usability studies on the ABC language. If you are going to =

IIRC, said usability studies were about indented code structure (as opposed=
to token-delimited structure). I have never read anything in studies about=
':'. This non-token, that does not mean anything, should at best be option=
al, just like the ';' statement terminator (which is allowed in python, but=
no one uses it outside multi-statement lines, probably because, precisely,=
it does not mean anything).
When I used python everyday, I constantly repeted 2 syntax errors:
* forgetting ':' (just like forgetting ';' in D)
* using '=3D' instead of '=3D=3D' (obvious reason, same in D)
These are for me 2 grammatical design errors.

"Parameters are constant in the procedure body. Their value cannot be c=

he most efficient way.

=20
I have missed that part of the docs. What kind of "most efficient way"?

nsure. I guess the author refers to the possibility to pass _any_ non-var p=
arameter by ref under the hood if more efficient, since it won't be changed=
. (arrays, which have copy semantics in Nimrod , its tuples ~ structs, and =
object types also are value types apparently)
I plan to do the same for my toy project one day. Pleased to see I'm not th=
e only fool ;-)
Denis
-- -- -- -- -- -- --
vit esse estrany =E2=98=A3
spir.wikidot.com