Nimrod programming language
Andreas Rumpf
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
k...@fiber-space.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
>
> ______________________________________________________
Looks really interesting. I think I'll give it a try later on.
Thanks for your announcement.
Reagrds,
Listick
http://www.listick.org
Tomasz Rola
> 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
Interesting.
One question I ask myself upon seeing a new language is if it is possible
to program amb (amb=ambiguous) operator in it. This page gives a very
nice, "code first" explanation of amb and how it is supposed to work:
http://www.randomhacks.net/articles/2005/10/11/amb-operator
I am not sure if this kind of extension is doable in your Nimrod. Perhaps
it can be somewhat extrapolated from docs, but at the moment I have no
time to do this (and could not google anything interesting).
As can be seen on the page mentioned, in Ruby this seems to be quite light
and effortless. From what I know about Python, it is either hard or
impractical (to the point of being impossible) to write amb in it.
Two additional notes regarding amb:
1. Even if Nimrod cannot support amb in an elegant way, it is still nice
idea. Especially if you can make it to be kind of Python superset, so that
Python programmer can cross the boundary between the two without much
hassle (and maybe in both directions). Of course, not everything can be
copied.
2. The amb itself is not really important so much, and I may never feel
any need to actually use it. But it stroke me how nice it was looking in
Ruby, even if I finally decided not to learn Ruby (not in this year, at
least).
In Scheme, it is a bit more hackish, but still looks nice, at least to me:
http://www.ccs.neu.edu/home/dorai/t-y-scheme/t-y-scheme-Z-H-16.html#node_chap_14
http://planet.plt-scheme.org/package-source/murphy/amb.plt/1/0/planet-docs/amb/index.html
Anyway, I think amb is quite a test of a language. If you can do it,
please show the code.
Regards,
Tomasz Rola
--
** A C programmer asked whether computer had Buddha's nature. **
** As the answer, master did "rm -rif" on the programmer's home **
** directory. And then the C programmer became enlightened... **
** **
** Tomasz Rola mailto:tomas...@bigfoot.com **
rum...@web.de
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.
rum...@web.de
> > I invented a new programming language called "Nimrod" that combines
> > Python's readability with C's performance. Please check it out:
> 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[S] =
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[S] =
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. ;-)
rum...@web.de
> to program amb (amb=ambiguous) operator in it. This page gives a very
> nice, "code first" explanation of amb and how it is supposed to work:
>
> http://www.randomhacks.net/articles/2005/10/11/amb-operator
>
using brute force. It seems to require continuations. AFAIK
continuations are extremely hard to implement efficiently, so probably
it won't be done in Nimrod.
Mensanator
> On 10 Mai, 10:40, Paul Rubin <http://phr...@NOSPAM.invalid> wrote:> Andreas Rumpf <Rump...@web.de> writes:
> > > I invented a new programming language called "Nimrod" that combines
> > > Python's readability with C's performance. Please check it out:
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[S] =
> 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[S] =
> 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
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[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
Tomasz Rola
> > One question I ask myself upon seeing a new language is if it is possible
> > to program amb (amb=ambiguous) operator in it. This page gives a very
> > nice, "code first" explanation of amb and how it is supposed to work:
> >
> > http://www.randomhacks.net/articles/2005/10/11/amb-operator
> >
> Hm. I am not sure either. To me, it looks like a constraint solver by
> using brute force.
Yes, kind of. From what I understand [1], it's goal is to simulate
nondeterministic "get right answer in one try", only this "one try"
requires browsing the solution space (because we have only "classic"
hardware). It is easy to use amb in wrong way, but I can see some cases
when I would like it.
[1] John McCarthy's paper still waits to be read by me, so... Ok, I have
just had a look at it and it seems that Ruby implementation is a bit
primitive compared to original concept. But still, this is what would be
needed in most real life cases, I suppose.
I think ability to define amb would allow me to write more concise code.
As far as I can tell, this kind of stuff plays more and more important
role in my programing.
> It seems to require continuations. AFAIK
> continuations are extremely hard to implement efficiently, so probably
> it won't be done in Nimrod.
Pity, a little. But not really big problem for me. Nimrod may be
interesting anyway, time will tell :-).
Lawrence D'Oliveiro
a0cc0d...@o14g2000vbo.googlegroups.com>, rum...@web.de wrote:
> 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.
k...@fiber-space.de
> On Mon, 11 May 2009, rump...@web.de wrote:
> > > One question I ask myself upon seeing a new language is if it is possible
> > > to program amb (amb=ambiguous) operator in it. This page gives a very
> > > nice, "code first" explanation of amb and how it is supposed to work:
>
> > >http://www.randomhacks.net/articles/2005/10/11/amb-operator
>
> > Hm. I am not sure either. To me, it looks like a constraint solver by
> > using brute force.
>
> Yes, kind of. From what I understand [1], it's goal is to simulate
> nondeterministic "get right answer in one try", only this "one try"
> requires browsing the solution space (because we have only "classic"
> hardware). It is easy to use amb in wrong way, but I can see some cases
> when I would like it.
In Python you can use a generator expression. Dan Piponis example can
be stated as
g = ((i,j) for i in range(2,100) for j in range(2,i) if i*j == 481)
which doesn't require any call/cc hacks but is a deterministic "get
right in one try". Once Nimrod has coroutines it's just a matter of
sugaring them into comprehensions.
>
> [1] John McCarthy's paper still waits to be read by me, so... Ok, I have
> just had a look at it and it seems that Ruby implementation is a bit
> primitive compared to original concept. But still, this is what would be
> needed in most real life cases, I suppose.
>
> I think ability to define amb would allow me to write more concise code.
> As far as I can tell, this kind of stuff plays more and more important
> role in my programing.
>
> > It seems to require continuations. AFAIK
> > continuations are extremely hard to implement efficiently, so probably
> > it won't be done in Nimrod.
>
> Pity, a little. But not really big problem for me. Nimrod may be
> interesting anyway, time will tell :-).
>
> Regards,
> Tomasz Rola
>
> --
> ** A C programmer asked whether computer had Buddha's nature. **
> ** As the answer, master did "rm -rif" on the programmer's home **
> ** directory. And then the C programmer became enlightened... **
> ** **
> ** Tomasz Rola mailto:tomasz_r...@bigfoot.com **
Martin Vilcans
> 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.
Nice with a language with a new language designed for high
performance. It seems like a direct competitor with D, i.e. a
high-level language with low-level abilities. The Python-like syntax
is a good idea.
There are two showstoppers for me though:
1. Introducing a new programming language where the char type is a
byte is anachronistic. You're saying that programmers don't have to
care about the string encoding and can just treat them as an array of
bytes. That is exactly what causes all the problems with applications
that haven't been designed to handle anything but ASCII. If you're
doing any logic with strings except dumb reading and writing, you
typically *have to* know the encoding. Forcing programmers to be aware
of this problem is a good idea IMO.
You can certainly have a string type that uses byte arrays in UTF-8
encoding internally, but your string functions should be aware of that
and treat it as a unicode string. The len function and index operators
should count characters, not bytes. Add a byte array data type for
byte arrays instead.
2. The dynamic dispatch is messy. I agree that procedural is often
simpler and more efficient than object-oriented programming, but
object-oriented programming is useful just as often and should be made
a simple as possible. Since Nimrod seems flexible, perhaps it would be
possible to implement an object-orientation layer in Nimrod that hides
the dynamic dispatch complexity?
bearoph...@lycos.com
> Nice with a language with a new language designed for high
> performance. It seems like a direct competitor with D, i.e. a
> high-level language with low-level abilities.
> The Python-like syntax is a good idea.
There is Delight too:
http://delight.sourceforge.net/
But I agree, one disadvantage (and one advantage) the D language is
its significant syntactic and semantic compatibility with C.
I like the syntax of Nimrod, but I think Nimrod designer has to work
more on data parallelism and higher level forms of parallelism.
At the moment D language has not enough data parallelism features for
scientific programming purposes.
Bye,
bearophile
rum...@web.de
>
> 1. Introducing a new programming language where the char type is a
> byte is anachronistic. You're saying that programmers don't have to
> care about the string encoding and can just treat them as an array of
> bytes. That is exactly what causes all the problems with applications
> that haven't been designed to handle anything but ASCII. If you're
> doing any logic with strings except dumb reading and writing, you
> typically *have to* know the encoding. Forcing programmers to be aware
> of this problem is a good idea IMO.
>
> You can certainly have a string type that uses byte arrays in UTF-8
> encoding internally, but your string functions should be aware of that
> and treat it as a unicode string. The len function and index operators
> should count characters, not bytes. Add a byte array data type for
> byte arrays instead.
>
(and a string literal syntax b"abc") which is quite alarming to me
that they chose the wrong default.
Eventually the "rope" data structure (that the compiler uses heavily)
will become a proper part of the library: By "rope" I mean an
immutable string implemented as a tree, so concatenation is O(1). For
immutable strings there is no ``[]=`` operation, so using UTF-8 and
converting it to a 32bit char works better.
> 2. The dynamic dispatch is messy. I agree that procedural is often
> simpler and more efficient than object-oriented programming, but
> object-oriented programming is useful just as often and should be made
> a simple as possible. Since Nimrod seems flexible, perhaps it would be
> possible to implement an object-orientation layer in Nimrod that hides
> the dynamic dispatch complexity?
>
Yes, I already have an idea how to improve it.
rum...@web.de
> > > arithmetic, using GMP or something like that.
>
> > True, but currently not a high priority for me.
>
> Too bad. That makes Nimrod officially "worthless", i.e., of no
> value to me.
>
project ;-)).
rum...@web.de
> > and than compiles itself. Bootstrapping works.
>
> I meant why not get rid of the translation step and implement the
> compiler in idiomatic Nimrod.
>
easily.
> > 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.
>
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
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
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
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?
Martin Vilcans
>> You can certainly have a string type that uses byte arrays in UTF-8
>> encoding internally, but your string functions should be aware of that
>> and treat it as a unicode string. The len function and index operators
>> should count characters, not bytes. Add a byte array data type for
>> byte arrays instead.
>>
> It's not easy. I think Python3's byte arrays have an "upper" method
> (and a string literal syntax b"abc") which is quite alarming to me
> that they chose the wrong default.
I suppose that is to make it possible to use the 'bytes' data type for
text strings if you really want to (and for backwards-compatibility).
Default text strings should use Unicode (as in Python 3), and that
should be supported by the language.
> Eventually the "rope" data structure (that the compiler uses heavily)
> will become a proper part of the library: By "rope" I mean an
> immutable string implemented as a tree, so concatenation is O(1). For
> immutable strings there is no ``[]=`` operation, so using UTF-8 and
> converting it to a 32bit char works better.
Consider a string class that keeps track of its own encoding and can
change it on the fly as needed.
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">
bearoph...@lycos.com
> 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
MRAB
"i"? In most languages using the Latin alphabet they would be, but in
Turkish they wouldn't.
Piet van Oostrum
>b> Nimrod also seems to ignore underscores inside names, seeing them as
>b> blanks. Some languages ignore underscores inside number literals, but
>b> I have never seen a language ignoring them into names too.
You may not have seen it, but Fortran and Algol 60 belong to that
category.
--
Piet van Oostrum <pi...@cs.uu.nl>
URL: http://pietvanoostrum.com [PGP 8DAE142BE17999C4]
Private email: pi...@vanoostrum.org
bearoph...@lycos.com
> You may not have seen it, but Fortran and Algol 60 belong to that
> category.
I see. It seems my ignorance is unbounded, even for the things I like.
I am very sorry.
Bye,
bearophile
MRAB
The example I remember is:
FORD=STOP
Variable name were a single letter, optionally followed by a digit, so
that's:
FOR D = S TO P
Tomasz Rola
> On 12 Mai, 02:10, Tomasz Rola <rto...@ceti.com.pl> wrote:
> > On Mon, 11 May 2009, rump...@web.de wrote:
> > > > One question I ask myself upon seeing a new language is if it is possible
> > > > to program amb (amb=ambiguous) operator in it. This page gives a very
> > > > nice, "code first" explanation of amb and how it is supposed to work:
> >
> > > >http://www.randomhacks.net/articles/2005/10/11/amb-operator
> >
> > > Hm. I am not sure either. To me, it looks like a constraint solver by
> > > using brute force.
> >
> > Yes, kind of. From what I understand [1], it's goal is to simulate
> > nondeterministic "get right answer in one try", only this "one try"
> > requires browsing the solution space (because we have only "classic"
> > hardware). It is easy to use amb in wrong way, but I can see some cases
> > when I would like it.
>
> In Python you can use a generator expression. Dan Piponis example can
> be stated as
>
> g = ((i,j) for i in range(2,100) for j in range(2,i) if i*j == 481)
>
> which doesn't require any call/cc hacks but is a deterministic "get
> right in one try". Once Nimrod has coroutines it's just a matter of
> sugaring them into comprehensions.
Yep, to be frank everything complicated can be achieved by means of a
"for" loop (so said one friend of mine, and this is dirty, dirty way of
thinking). Or putting generators in a row... but try to do this trick
with ten of them and things start to look messy. Or ugly. Or both - and I
don't like neither.
There is another example, below Don Piponis' one. I like the look of
simplicity. I don't like ten or seven nested loops, that would have been
used instead. Perhaps amb could be somehow simulated with recursion, but
to use recursion in a language, I need to know it is safe and doesn't
overflow on 50th call. So, either I use the language that allows me to
express things in a way appealing to my taste, or I use something else and
perhaps end up with nested loops.
Besides, having search space defined with amb-statements may allow me to
try other ideas than brute-force search. Like, say, genetic algorithm
under the hood. No change to program, just link with other library (import
amb's definition from other path etc). I cannot imagine trying such trick
with nested loops without writing new program (writing new loop(s)).
Generators don't give me nice looking alternative to amb. So, if the
problem requires two or three nested loops, ok, I can go for it. If more -
I want another way out. Just my personal opinion, not forcing anybody to
follow.
However, the question I wanted to be answered, was how far Nimrod would
allow me to go. I've got my answer and, well, for some near future I will
just sit and see what happens. So, discussing amb's usefulness or if the
same ca be done with whatever else is not very interesting, because of
course everything can be done with loops - no need for continuations,
coroutines, recursion, macros etc.
Regards
Tomasz Rola
--
** A C programmer asked whether computer had Buddha's nature. **
** As the answer, master did "rm -rif" on the programmer's home **
** directory. And then the C programmer became enlightened... **
** **
** Tomasz Rola mailto:tomas...@bigfoot.com **