# 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