ANNOUNCE: joy 1.0 beta 1 available!
John Cowan — 2001-04-24 17:48:55
This is to announce the first beta release of Joy 1.0, an Open
Source implementation of Joy based on Manfred's source code.
After it is debugged, it will eventually become the official
reference implementation. Source code is temporarily available at
http://www.ccil.org/~cowan/joy.tar.gz .
I have built it on the following platforms: Solaris 8, Cygnus/Win32,
Linux/i386. I will be very interested in builds for other platforms,
especially native Win32.
To build, type "make", which tries to build the garbage collector.
If it builds on your system, it will be used; if not, then the
old GC will be used (which does not garbage-collect strings).
The basic new features are:
o
Floating-point numbers
o
Access to files
o
Industrial-strength garbage collection (optional)
o
Bugs fixed
o
New operators and combinators
o
LIBRA has equivalent syntax DEFINE
o
Period has equivalent syntax "!"
There are only two backward incompatibilities. In this release, "32."
means not "32" followed by ".", but rather the floating-point number
32.0. The workaround is to use either "32 ." or "32!".
In the standard library, the name of the "exp" (exponentiate) function
has been changed to "ipow"; "exp" is now the ANSI C exp function, which
raises e to the power of its argument.
Here are the new floating-point words:
iffloat float formatf strtod trunc tanh tan sqrt sinh sin pow modf
log10 log ldexp frexp floor exp cosh cos ceil atan2 atan asin acos
Here are the words which now support floating-point contagion -- if the
argument (either argument, in the case of binadic words) is a float,
so is the result:
= != < <= > >= null abs sign rem / * - +
"Null" is true of 0.0 and false of all other floats.
Here are the file-based words. With the exception of "fclose", "file",
and "iffile", they always leave the file object on the stack.
iffile file ftell fseek fputch fput frename fremove fwrite fread
fopen fgets fgetch fflush ferror feof fclose stderr stdout stdin
Here are the remaining new words, mostly based on ANSI C standard
functions.
getenv setundeferror fold intern srand format strtol strftime mktime
gmtime localtime neg div rem rand time undeferror
If "undeferror" is true, it is an error to invoke an undefined
function; otherwise, undefined function invcation does nothing.
If "autoput" equals 2, then the whole stack is printed and nothing
is removed from it.
All these words are documented tersely by "manual" and "helpdetail".
--
There is / one art || John Cowan <
jcowan@...>
no more / no less ||
http://www.reutershealth.com
to do / all things ||
http://www.ccil.org/~cowan
with art- / lessness \\ -- Piet Hein
John Cowan — 2001-04-24 18:34:42
I forgot to mention two important points:
1) All this is being done with Manfred's approval, though he has
not yet had time to examine the code.
2) Joy 1.0 is licensed under the new-style BSD license (no
advertising requirement). As a result, it can be incorporated
into proprietary, BSD-licensed, or GPL-licensed programs.
--
There is / one art || John Cowan <
jcowan@...>
no more / no less ||
http://www.reutershealth.com
to do / all things ||
http://www.ccil.org/~cowan
with art- / lessness \\ -- Piet Hein
Manfred von Thun — 2001-04-26 05:44:01
This group is now One Year Old. Happy birthday !
Our thanks to Billy for setting it all up.
My thanks to all for the many discussions.
It is only fitting that our birthday should
coincide with John Cowan's big extension of Joy.
I have unpacked and compiled it on a Sun under Linux,
without any problems. But I have done no tests so far.
I hope that some of you will find the time for
testing it. I suggest that it could become THE JOY,
and that my old implementation should fade away slowly.
Any opinions ?
Manfred von Thun
Manfred von Thun — 2001-04-27 00:27:34
On Tue, 24 Apr 2001, John Cowan wrote:
> This is to announce the first beta release of Joy 1.0, an Open
> Source implementation of Joy based on Manfred's source code.
> After it is debugged, it will eventually become the official
> reference implementation. Source code is temporarily available at
> http://www.ccil.org/~cowan/joy.tar.gz .
I unpacked the tar file, and it compiled without any complaints
on a Sun under Linux.
Below is a listing of some tests.
1. the new inbuilt "fold" is wrong for unitlists.
2. there are problems with "dup", "swap" and "first"
when using reals. How this can arise I do not understand,
but I have not yet had time to examine the source code.
I hope to do some more tests soon.
Thank you again for your effort
- Manfred
JOY - compiled at 12:54:11 on Apr 26 2001 (BDW)
1 setautoput.
DEFINE properfold == [swap] dip step.
(* using properfold to find sum of list of integers: *)
[ 1 2 3 ] 0 [+] properfold.
6
[ 1 2 ] 0 [+] properfold.
3
[ 1 ] 0 [+] properfold.
1
[ ] 0 [+] properfold.
0
(* the new inbuilt fold is wrong for lists of size 1: *)
[ 1 2 3 ] 0 [+] fold.
6
[ 1 2 ] 0 [+] fold.
3
[ 1 ] 0 [+] fold.
[1]
[ ] 0 [+] fold.
0
(* problems with dup, swap and first using reals: *)
111 dup +.
222
1.1 dup +.
1.1
1.1 1.1 +.
2.2
111 222 swap +.
333
1.1 2.2 swap +.
1.18433e-269
[ 111 222 ] first.
111
[ 1.1 2.2 ] first.
5.91968e-270
Time: 0 CPU
John Cowan — 2001-04-27 15:20:32
Manfred von Thun wrote:
> I unpacked the tar file, and it compiled without any complaints
> on a Sun under Linux.
The following patch to interp.c fixes the reported bugs. The problem
with "fold" was a simple oversight.
The other problem was a failure to completely remove the assumption
that "u.num" is the whole content of a node, no matter what its type.
(This was never a good idea anyway, as pointers may not be equal to
longs on some machines.) I had fixed all direct newnode calls,
but not the indirect ones mediated through NULLARY, UNARY, and BINARY.
The affected words are: swap, dup, first, uncons, unswons,
of, at, dip, nullary, unary, binary, binrec, treestep, treegenrec.
Due to a gcc bug (which I have reported), new macros GNULLARY etc.
are needed.
The new version is at
http://www.ccil.org/~cowan/joy.tar.gz .
This is beta 2. I recommend downloading it rather than
trying to install this patch, which is provided chiefly for
information.
164a165,170
> #define GNULLARY(TYPE,VALUE) \
> stk = newnode(TYPE,(Types)(VALUE),stk)
> #define GUNARY(TYPE,VALUE) \
> stk = newnode(TYPE,(Types)(VALUE),stk->next)
> #define GBINARY(TYPE,VALUE) \
> stk = newnode(TYPE,(Types)(VALUE),stk->next->next)
263,264c269,270
< BINARY(SAVED1->op,SAVED1->u.num);
< NULLARY(SAVED2->op,SAVED2->u.num);
---
> GBINARY(SAVED1->op,SAVED1->u);
> GNULLARY(SAVED2->op,SAVED2->u);
270c276
< NULLARY(stk->op,stk->u.num);
---
> GNULLARY(stk->op,stk->u);
781c787
< UNARY(stk->u.lis->op,stk->u.lis->u.num);
---
> GUNARY(stk->u.lis->op,stk->u.lis->u);
838c844
< UNARY(SAVED1->u.lis->op,SAVED1->u.lis->u.num);
---
> GUNARY(SAVED1->u.lis->op,SAVED1->u.lis->u);
866c872
< NULLARY(SAVED1->u.lis->op,SAVED1->u.lis->u.num);
---
> GNULLARY(SAVED1->u.lis->op,SAVED1->u.lis->u);
964c970
< BINARY(n->op,n->u.num); \
---
> GBINARY(n->op,n->u); \
1331c1337
< NULLARY(SAVED2->op,SAVED2->u.num);
---
> GNULLARY(SAVED2->op,SAVED2->u);
1540c1546
< { NULLARY(DMP1->op,DMP1->u.num);
---
> { GNULLARY(DMP1->op,DMP1->u);
1574c1580
< { stk = newnode(SAVED3->op, SAVED3->u, stk); }
---
> { stk = newnode(SAVED3->u.lis->op, SAVED3->u.lis->u, stk); }
1992c1998
< NULLARY(dump2->op,dump2->u.num);
---
> GNULLARY(dump2->op,dump2->u);
2010c2016
< { NULLARY(item->op,item->u.num);
---
> { GNULLARY(item->op,item->u);
2083c2089
< NULLARY(SAVED1->op,SAVED1->u.num);
---
> GNULLARY(SAVED1->op,SAVED1->u);
--
There is / one art || John Cowan <
jcowan@...>
no more / no less ||
http://www.reutershealth.com
to do / all things ||
http://www.ccil.org/~cowan
with art- / lessness \\ -- Piet Hein
Manfred von Thun — 2001-05-01 06:06:00
On Fri, 27 Apr 2001, John Cowan wrote:
...
> The other problem was a failure to completely remove the assumption
> that "u.num" is the whole content of a node, no matter what its type.
> (This was never a good idea anyway, as pointers may not be equal to
> longs on some machines.)
Yes - I was worried about that when I wrote it. I never knew that
my prototype would be ported so widely. Thanks.
...
I have had time to look at your code, and I am most impressed.
It is clear to me that you are a far better C-programmer than
I ever will be. I might have mentioned this before in the group:
Joy is my first C-program (after "hello.."), but I had written
a lot of Pascal before.
You are obviously a most worthy contender of the title
MASTER OF JOY
and I, on the authority invested in me as the Father of Joy,
hereby anoint you to this newly created exalted title.
[I could not resist this, sorry]
I look forward to studying your code in more detail.
> The new version is at http://www.ccil.org/~cowan/joy.tar.gz .
Will do - soon.
I'll also respond to your interesting and lively debate with
Billy Tanksley - soon.
- Manfred
John Cowan — 2001-05-01 12:22:51
Manfred von Thun scripsit:
> I have had time to look at your code, and I am most impressed.
> It is clear to me that you are a far better C-programmer than
> I ever will be. I might have mentioned this before in the group:
> Joy is my first C-program (after "hello.."), but I had written
> a lot of Pascal before.
In that case, *I* am most impressed, especially with the clever
use of macros, a distinctively C-ish feature. The main places
where lack of experience betrays itself is a tendency to
re-implement stuff that's in the standard library already.
> You are obviously a most worthy contender of the title
> MASTER OF JOY
> and I, on the authority invested in me as the Father of Joy,
> hereby anoint you to this newly created exalted title.
*blush*
Now I only wish I were better at programming in Joy, as distinct
from implementing Joy. It was by no means obvious to me
how to express "fold" in terms of the existing primitives,
which was why I went ahead and implemented it in C.
--
John Cowan
cowan@...
One art/there is/no less/no more/All things/to do/with sparks/galore
--Douglas Hofstadter
Billy Tanksley — 2001-05-01 18:04:50
From: Manfred von Thun [mailto:
phimvt@...]
>You are obviously a most worthy contender of the title
> MASTER OF JOY
>and I, on the authority invested in me as the Father of Joy,
>hereby anoint you to this newly created exalted title.
All hail the new MASTER OF JOY!
(Applause!)
> - Manfred
-Billy
Manfred von Thun — 2001-05-02 08:52:13
John Cowan wrote:
> use of macros, a distinctively C-ish feature. The main places
> where lack of experience betrays itself is a tendency to
> re-implement stuff that's in the standard library already.
Yes, feel free to eliminate my (probably amateurish) re-implementation.
I still don't have any manual for the standard library
and all the other fancy ones.
> from implementing Joy. It was by no means obvious to me
> how to express "fold" in terms of the existing primitives,
> which was why I went ahead and implemented it in C.
You were quite right, it should be implemented in C in the
interpreter. Maybe one could even write a C-macro which
expresses what is common to "fold" and "step".
- Manfred
Manfred von Thun — 2001-05-03 08:02:20
On Thu, 26 Apr 2001, Manfred von Thun (Father of Joy)wrote:
>
> This group is now One Year Old. Happy birthday !
> Our thanks to Billy for setting it all up.
>
[standard anointment deleted]
All hail the FATHER OF CONCAT
[loud cheers from the crowd]
- Manfred
Manfred von Thun — 2001-05-10 07:33:24
beta 2 under DEC VMS
John, I tried to compile your beta 2 with the standard C compiler under
VMS on our Alpha.
Result: two trivial problems and one major one as follows:
main.c OK
scan.c OK
interp.c lines 188,189,190: at end of line
Informational: extraneous semicolon
lines 234,234: online manual
Error: unexpected newline character in string constant
lines 18,183 and MANY others ...(Types)...
Error: In this statement "Types" is a union type which is
not scalar
utils.c a few lines again: ...(Types)...
Error: In this statement "Types" ...
The (Types) error is a nuisance, because it means that the
problem that you pointed out about my implementation cannot
be solved this way to non-gcc compilers. (The problem was
that I blythely assumed that pointers and ints are the same
size - or I assumed that pointers are no bigger than ints.)
Your solution was (non-standard?, non-ANSII?) to use the
variant record as a type-coercion (terminology?), but it seems
this ain't cricket.
I would turn "Types" into a macro, defined as some 64 bit quantity
on the host computer, and require the implementor to define it as the
right quantity. I am assuming that nothing need be bigger than 64 bits.
Maybe a more experienced C programmer like you can do it better.
I also ran your beta 2 on a Sun where it compiles correctly under gcc.
The few tests that I did were OK.
In a week or so I'll have a short wishlist of some additions/changes
that I would like you to make which are independent of your additions
to Joy and independent of the "Types" problem.
I think we'll be able to put your version on the Joy page soon.
I take it it is OK to mention that you are the author, but I
also need to know whether you want a link to your own page.
When it is all there I should make an announcement on comp.lang.functional
But lets try to leave Joy independent of gcc and independent of unix.
Thanks for all your good work.
- Manfred
John Cowan — 2001-05-10 15:59:45
Manfred von Thun wrote:
> interp.c lines 188,189,190: at end of line
> Informational: extraneous semicolon
Fixed. My error.
> lines 234,234: online manual
> Error: unexpected newline character in string constant
This line number is incorrect (line 234 is a blank line just before
the definition of intern_). Can you give me the right line number?
> lines 18,183 and MANY others ...(Types)...
> Error: In this statement "Types" is a union type which is
> not scalar
>
> utils.c a few lines again: ...(Types)...
> Error: In this statement "Types" ...
ARRRRRRRRRRGH! [Colorful Australian/Rebel epithets deleted]
ISO C does not have what Algol 68 called the uniting coercion: it does not
permit, given a union type containing int and float, a cast from int or
float to that type. This despite the fact that such a cast is always
harmless, and (since C unions are not discriminated) never involves
generating any code, except conceivably to cast a pointer from one type
to another, on hardware with non-uniform pointers.
GCC simply accepts such casts, not even warning about them with the -Wall
switch, unless the -ansi -pedantic switches are also present. I thought
it was a fair bet that other independent C compilers would also accept
the construction. Evidently not.
I will, when I get a chance, rewrite the code not to use the cast.
> The (Types) error is a nuisance, because it means that the
> problem that you pointed out about my implementation cannot
> be solved this way to non-gcc compilers. (The problem was
> that I blythely assumed that pointers and ints are the same
> size - or I assumed that pointers are no bigger than ints.)
And with the introduction of floating point, implemented as double,
we can hardly expect double and long to be the same!
> I would turn "Types" into a macro, defined as some 64 bit quantity
> on the host computer, and require the implementor to define it as the
> right quantity. I am assuming that nothing need be bigger than 64 bits.
> Maybe a more experienced C programmer like you can do it better.
In order to get the desired union object, we can simply have a static
object or two lying about which are set and then referenced through a
macro. No problem, just 74 references to fix.
> I also ran your beta 2 on a Sun where it compiles correctly under gcc.
> The few tests that I did were OK.
I did that too. I have routinely tested on SPARC Solaris, Linux '386,
and Cygnus (Posix for Win32).
> In a week or so I'll have a short wishlist of some additions/changes
> that I would like you to make which are independent of your additions
> to Joy and independent of the "Types" problem.
Excellent!
> I think we'll be able to put your version on the Joy page soon.
> I take it it is OK to mention that you are the author, but I
> also need to know whether you want a link to your own page.
Not necessary, I think.
> But lets try to leave Joy independent of gcc
Yes.
> and independent of unix.
There are no Unix dependencies: we use only the Standard C library.
--
There is / one art || John Cowan <
jcowan@...>
no more / no less ||
http://www.reutershealth.com
to do / all things ||
http://www.ccil.org/~cowan
with art- / lessness \\ -- Piet Hein
Billy Tanksley — 2001-05-10 16:39:42
From: Manfred von Thun [mailto:
phimvt@...]
>I would turn "Types" into a macro, defined as some 64 bit quantity
>on the host computer, and require the implementor to define it as the
>right quantity. I am assuming that nothing need be bigger than 64 bits.
>Maybe a more experienced C programmer like you can do it better.
Check out how ficl does it with its CELL type -- that's almost certainly the
correct solution, especially since ficl has already been ported to Alpha (a
64-bit architecture).
http://ficl.sourceforge.net
> - Manfred
-Billy
Manfred von Thun — 2001-05-15 05:26:34
On Thu, 10 May 2001, John Cowan wrote:
> Manfred von Thun wrote:
> > lines 234,234: online manual
> > Error: unexpected newline character in string constant
>
> This line number is incorrect (line 234 is a blank line just before
> the definition of intern_). Can you give me the right line number?
Sorry, sorry. Should be lines 2334, 2335:
"Formats a list T ...
pushes the result S2."}
> > lines 18,183 and MANY others ...(Types)...
> > Error: In this statement "Types" is a union type which is
> > not scalar
> >
> > utils.c a few lines again: ...(Types)...
> > Error: In this statement "Types" ...
>
> ARRRRRRRRRRGH! [Colorful Australian/Rebel epithets deleted]
I quite agree.
> I will, when I get a chance, rewrite the code not to use the cast.
Good Master.
> > also need to know whether you want a link to your own page.
> Not necessary, I think.
OK, I thought I'd ask early.
- Manfred