NJoy
Christian Szegedy — 2003-02-03 13:24:34
I have implemented an enhanced version of joy
interpreter at the weekend (I called it NJoy).
Features:
1) Module system (with possibly nested module, private functions)
2) Arbitrary precision integers
3) Pretty printing of the whole parsed program database.
Not implemented:
Sets ( I don't plan to do it)
Some library functions are missing (about 70% is implemented), i.e.
most file IO is missing.
The interpreter is written in ocaml and has acceptable performance.
It is not very well tested, but still performs remarkable stable.
Plaese send me an email if you want a copy.
Best Regards, Christian
Nick Forde — 2003-02-03 14:55:50
Christian Szegedy writes:
> I have implemented an enhanced version of joy
> interpreter at the weekend (I called it NJoy).
Great to hear! I've been anticipating someone doing this for a while.
Strangely enough I used the same name as you for a small Joy I've been
experimenting with written in C++. In my case the "N" was for "New" or
"Nick" :-)
> Features:
> 1) Module system (with possibly nested module, private functions)
Please share with us what you implemented and why.
> 2) Arbitrary precision integers
This has been on my wish list for a while. Must they be explicitly
created or is the switch between integer or float automatic?
> 3) Pretty printing of the whole parsed program database.
>
> Not implemented:
> Sets ( I don't plan to do it)
Any reason why? I've been experimenting with various implementations
of C++ STL sets in Joy and find it to be very useful to be able to
create and manipulate sets of other builtin types. I think the
existing interpreter's limitation with sets is one of it's least
attractive "features".
> Some library functions are missing (about 70% is implemented), i.e.
> most file IO is missing.
Do you mean primitive functions? Does your implementation work
directly with Manfred's libraries?
> The interpreter is written in ocaml and has acceptable performance.
Cool. But what is "acceptable"? How does it compare with John and
Manfred's implementation?
> It is not very well tested, but still performs remarkable stable.
>
> Plaese send me an email if you want a copy.
Would you mind sharing it with the group? If not you could upload it
to the concatenative file area at Yahoo?
Regards,
Nick.
gyogyfu <szegedy@or.uni-bonn.de> — 2003-02-03 15:17:51
--- In
concatenative@yahoogroups.com, Nick Forde <nickf@c...> wrote:
> Christian Szegedy writes:
> > I have implemented an enhanced version of joy
> > interpreter at the weekend (I called it NJoy).
>
> Great to hear! I've been anticipating someone doing this for a while.
> Strangely enough I used the same name as you for a small Joy I've been
> experimenting with written in C++. In my case the "N" was for "New" or
> "Nick" :-)
>
> > Features:
> > 1) Module system (with possibly nested module, private functions)
>
> Please share with us what you implemented and why.
>
> > 2) Arbitrary precision integers
>
> This has been on my wish list for a while. Must they be explicitly
> created or is the switch between integer or float automatic?
All integers are arbitrary precision by default.
Any numeric operation involving an integer and a float has float as a return value.
> > 3) Pretty printing of the whole parsed program database.
> >
> > Not implemented:
> > Sets ( I don't plan to do it)
>
> Any reason why? I've been experimenting with various implementations
> of C++ STL sets in Joy and find it to be very useful to be able to
> create and manipulate sets of other builtin types. I think the
> existing interpreter's limitation with sets is one of it's least
> attractive "features".
>
I am planning to introduce more powerful hashes (that is finite functions), which can act as sets as well.
>
> Do you mean primitive functions? Does your implementation work
> directly with Manfred's libraries?
I mean the core library. Original joy files can not be compiled yet, because of the incompatible syntax. However, I plan to write a simple script to transform Manfred's libraries into the njoy syntax. The other problem is the somewhat different handling of numeric values.
> Cool. But what is "acceptable"? How does it compare with John and
> Manfred's implementation?
>
I have not made any comparisons, but a joy loop over 1000000 objects does not take a second on my Athlon 600 box.
> If not you could upload it to the concatenative file area at Yahoo?
OK, it's there.
gyogyfu <szegedy@or.uni-bonn.de> — 2003-02-03 16:17:58
--- In
concatenative@yahoogroups.com, Nick Forde <nickf@c...>
I have tested the following loop:
1 1000000 [ 1 + ] times
It runs exactly as fast in njoy as in joy. (Altough I
use arbitary precision integers per default.)
Of course, it does not mean too much, but it shows
that the performance is not inaccaptable.
Best Regards, Christian
Nick Forde — 2003-02-03 16:30:41
I would expect this to be fast in all implementations, even with
arbitrary precision integers. A better quick test would be to run the
little Mandelbrot implementation at:
http://groups.yahoo.com/group/concatenative/files/mandel.html#6.%20Joy%20Implementation%204
This does some small scale list, numeric and stack manipulation which
should give some more meaningful results.
Regards,
Nick.
"gyogyfu <
szegedy@...-bonn.de>" <
szegedy@...-bonn.de> writes:
> --- In concatenative@yahoogroups.com, Nick Forde <nickf@c...>
> I have tested the following loop:
>
> 1 1000000 [ 1 + ] times
>
> It runs exactly as fast in njoy as in joy. (Altough I
> use arbitary precision integers per default.)
>
> Of course, it does not mean too much, but it shows
> that the performance is not inaccaptable.
>
> Best Regards, Christian
gyogyfu <szegedy@or.uni-bonn.de> — 2003-02-03 18:13:25
phimvt@lurac.latrobe.edu.au — 2003-02-06 04:26:06
On Mon, 3 Feb 2003, gyogyfu <
szegedy@...-bonn.de> wrote:
> --- In concatenative@yahoogroups.com, Nick Forde <nickf@c...> wrote:
[..]
> > http://groups.yahoo.com/group/concatenative/files/mandel.html#6.%20Joy%20Implementation%204
>
> I have tried the first implementation.
>
> Joy:
> real 0m1.872s
> user 0m1.160s
> sys 0m0.040s
>
> NJoy:
> real 0m1.426s
> user 0m1.390s
> sys 0m0.000s
>
> So, NJoy is slightly slower, but this is no
> significant loss of performance.
Quite agree.
I am impressed by what you have written in this and your previous
postings. I have several questions:
1. I take it your NJoy was compiled ML
Am I right in believing that ML can also run in interpreted
mode, which would be slower.
2. Since the Joy stack has to be able to contain items of all
sorts of types, does it require special trickery to do this
in the strong but polymorphic typing system of ML?
(Everybody seems to have written a version of Lisp-in-Lisp,
but I have never seen ML-in-ML for presumably that reason.)
3. In your timing comparison, did you use Joy with or without
the BDW garbage collector?
4. Do you use ML's reader or did you write your own scanner
and parser?
5. I would very much like to study your ML source code. I can't
run it, but I can get a good idea of how it works by trying
to read it. However, I am having difficulty unpacking the
file you left at the concatenative files area. I tried all
the unixy things I know of, with no avail. Could you perhaps
leave another version there, or even just your raw text files
(it does not seem that they are very large). Alternatively,
would you be so kind and simply email them to me, please.
Thank you for your contribution. I very much welcome other
implementations of Joy or other concatenative languages.
Mit freundlichem Gruss
- Manfred
Nick Forde — 2003-02-06 10:16:03
phimvt@... writes:
> 5. I would very much like to study your ML source code. I can't
> run it, but I can get a good idea of how it works by trying
> to read it. However, I am having difficulty unpacking the
> file you left at the concatenative files area. I tried all
> the unixy things I know of, with no avail. Could you perhaps
> leave another version there, or even just your raw text files
> (it does not seem that they are very large). Alternatively,
> would you be so kind and simply email them to me, please.
It's compressed using bzip2. I've uploaded an uncompressed tar version
of the same file.
Regards,
Nick.
gyogyfu <szegedy@or.uni-bonn.de> — 2003-02-06 11:02:55
--- In
concatenative@yahoogroups.com, phimvt@l... wrote:
> >
> > I have tried the first implementation.
> >
> > Joy:
> > real 0m1.872s
> > user 0m1.160s
> > sys 0m0.040s
> >
> > NJoy:
> > real 0m1.426s
> > user 0m1.390s
> > sys 0m0.000s
> >
> > So, NJoy is slightly slower, but this is no
> > significant loss of performance.
>
> Quite agree.
I made a bit profiling and it turned out, that the storing the stack-traceback consumed significant time. Since joy does not do it, I made it optional. (The traceback of an error is given only printed when started with -g flag).
Without the traceback, mandel take 0.7s user time to run through.
So runtime is even better.
>
> 1. I take it your NJoy was compiled ML
> Am I right in believing that ML can also run in interpreted
> mode, which would be slower.
Yes I test it normally in bytecode.
> 2. Since the Joy stack has to be able to contain items of all
> sorts of types, does it require special trickery to do this
> in the strong but polymorphic typing system of ML?
> (Everybody seems to have written a version of Lisp-in-Lisp,
> but I have never seen ML-in-ML for presumably that reason.)
It is simply a variant. I can do it, since the number of types is fixed.
> 3. In your timing comparison, did you use Joy with or without
> the BDW garbage collector?
I don't know, I just compiled your package without making any additional efforts.
> 4. Do you use ML's reader or did you write your own scanner
> and parser?
I used ocamllex and ocamlyacc.
> 5. I would very much like to study your ML source code. I can't
> run it, but I can get a good idea of how it works by trying
> to read it. However, I am having difficulty unpacking the
> file you left at the concatenative files area. I tried all
> the unixy things I know of, with no avail. Could you perhaps
> leave another version there, or even just your raw text files
> (it does not seem that they are very large). Alternatively,
> would you be so kind and simply email them to me, please.
>
> Thank you for your contribution. I very much welcome other
> implementations of Joy or other concatenative languages.
I placed a package on the server. The package contains a compiled executable for linux (njoy), and a platform-independent njoy.bytecode. To run the bytecode, one needs of course the same version of ocaml I used: ocaml-3.06. The package contains a mandel.joy file. This is slightly modified version of fraclib.joy.
Best Regards, Christian
wtanksleyjr@cox.net — 2003-02-06 17:43:53
From:
phimvt@...
>2. Since the Joy stack has to be able to contain
>items of all sorts of types, does it require
>special trickery to do this in the strong but
>polymorphic typing system of ML?
No trickery; ML's made to do it with variant records.
> - Manfred
-Billy
phimvt@lurac.latrobe.edu.au — 2003-02-07 10:27:24
Thank you all for answering my various questions.
I have had a chance to bunzip2 and untar the package in the files area.
So I have now spent the last three hours studying the .ml files.
As you know, I do not have access to any version of ML and hence
only have a superficial knowledge of the language. But I am
prompted to say two things:
1. This looks like a very professionally written implementation.
Thank you very much, Christian.
(Real bonza, mate - as we say here down under.)
2. ML is clearly superior to C for writing _readable_ implementations
of other languages. I was surprised how easy it was to understand
the code - especially with my only superficial knowledge of the
language ML. (Admittedly, knowing what the code was supposed to
do helped a lot, too.) It does make me wonder what the future
will be for Joy.
So, thanks again.
- Manfred
gyogyfu <szegedy@or.uni-bonn.de> — 2003-02-07 23:38:28
Manfred wrote:
> As you know, I do not have access to any version of ML and hence
Ocaml is a free software and a self installing Windows installer can be downloaded from:
http://caml.inria.fr/distrib/ocaml-3.06/ocaml-3.06-win.exe
Anyway, I forgot to say, that the source code becomes quite ugly, if one does not replace each tabulator character by 3 spaces...