# Joy Primitives

## ehz4 <ehz4@yahoo.com> — 2003-01-17 15:05:14

    I was wondering if there is a list of Joy primitives somewhere.  Preferably as part of a language description similar to Schemes' R5.

    Thanks,

    Edwin Zacharias

## Nick Forde — 2003-01-17 17:13:42

    "ehz4 <ehz4@...>" <ehz4@...> writes:

      > I was wondering if there is a list of Joy primitives somewhere.

     > Preferably as part of a language description similar to Schemes'

     > R5.

     As far as I'm aware there isn't yet a comprehensive language reference

    available, however you can find a list of most Joy primitives at:

    http://groups.yahoo.com/group/concatenative/files/rabbit/joy-funs-doc.html

    This excellent reference document was generated by Heiko Kuhrt using

    his Rabbit xhtml library written in Joy.

    Regards,

    Nick.

## Heiko.Kuhrt@t-online.de — 2003-01-18 23:57:11

    On Fri, Jan 17, 2003 at 05:13:42PM +0000, Nick Forde wrote:

     > "ehz4 <ehz4@...>" <ehz4@...> writes:

    >  > I was wondering if there is a list of Joy primitives somewhere.

    >  > Preferably as part of a language description similar to Schemes'

    >  > R5.

    >

    > As far as I'm aware there isn't yet a comprehensive language reference

    > available, however you can find a list of most Joy primitives at:

    >

    > http://groups.yahoo.com/group/concatenative/files/rabbit/joy-funs-doc.html

    >

    > This excellent reference document was generated by Heiko Kuhrt using

    > his Rabbit xhtml library written in Joy.

    >

    > Regards,

    >

    > Nick.

     Thank you very mutch, Nick!

    I'm currently working on it again. A preview is available at

     http://groups.yahoo.com/group/concatenative/files/rabbit/joy-funs-doc.pdf

    The thing still needs some more work. All sorts of comments or bug reports

    are very welcome and would be helpful for me.

    An update of the html version will have to wait, but I think I can get

    pdf, ps and dvi ready within the next weeks.

    -Heiko

## Nick Forde — 2003-01-19 10:39:47

    Heiko,

    Are you generating the pdf directly using Joy? It looks good so far.

    It would be nice if the Joy language reference manual was generated by

    Joy itself. It would also be great to get use a single data source for

    both the interpreter online help and printed documentation. Perhaps

    Rabbit could be used to generate some C code for the interpreter help?

    Nick.

    Heiko.Kuhrt@... writes:

      > I'm currently working on it again. A preview is available at

     >

     >  http://groups.yahoo.com/group/concatenative/files/rabbit/joy-funs-doc.pdf

     >

     > The thing still needs some more work. All sorts of comments or bug reports

     > are very welcome and would be helpful for me.

     >

     > An update of the html version will have to wait, but I think I can get

     > pdf, ps and dvi ready within the next weeks.

     >

     > -Heiko

## Manfred von Thun — 2003-01-20 06:09:16

    On Sun, 19 Jan 2003, Nick Forde wrote:

     > Heiko,

    >

    > Are you generating the pdf directly using Joy? It looks good so far.

    > It would be nice if the Joy language reference manual was generated by

    > Joy itself. It would also be great to get use a single data source for

    > both the interpreter online help and printed documentation.

     Yes, the fewer independent files there are to update manually

    desto better.

    Today I looked at the Joy paper "The current implementation"

    which used to have a link to a file containing just the output

    from the "manual." command. The link was broken. I fixed it, and

    also put a link to that file on the main Joy page just after

    that paper. So this contains the online manual for all the

    (RAW) Joy primitives.

    I also added, at the same place, a link to a file containing the

    output from the "help." command when all libraries are loaded.

    Both files will now always be updated by the command file

    update-tars.sh which I run whenever there is a not-too-trivial

    change.

    For both files output is plain text, not HTML, but my

    web browser (lynx) does not mind that. Is it a problem with

    other browsers? At least for the "manual." command there is

    also a variant which produces .tex output, and it should be

    easy to add one that produces .html output.

    [..]

    I have to rush off.

      - Manfred

## Heiko.Kuhrt@t-online.de — 2003-01-20 09:34:23

    On Sun, Jan 19, 2003 at 10:39:47AM +0000, Nick Forde wrote:

     > Heiko,

    >

    > Are you generating the pdf directly using Joy? It looks good so far.

    > It would be nice if the Joy language reference manual was generated by

    > Joy itself. It would also be great to get use a single data source for

    > both the interpreter online help and printed documentation. Perhaps

    > Rabbit could be used to generate some C code for the interpreter help?

    >

    > Nick.

     My Joy Program Rabbit is generating html and latex output. There is no

    input into the program but it evaluates to one string and that string is

    written to file. The output format depends on what files are loaded.

    Using the external programs latex, dvips and dvipdf I generate ps- and pdf-

    from tex-files.

    In other words: yes, the docs are made by a program written in Joy and

    the same source is used for html, ps and pdf output.

    At the moment the html output comes without table of contents and there

    are a few other problems, too.

    C code as a third output format of Rabbit should not be too complicated.

    Picking out the atoms defined in the C source is simple, because information

    about where things are defined is already part of the Joy source.

    As soon as I find time to do I will generate a C source code file as a

    suggestion. Or you tell me how the C code should look like and I fit my part

    in.

    The C file could be something like:

    -----------

    ????? I don't know anything about C, what file head is necessary?

    {"rotated",             rotated_,       "X Y Z W  ->  Z Y X W",

    "As if defined by:   rotated  ==  [rotate] dip"},

    {"pop",			pop_,		" X  ->",

    "Removes X from top of the stack."},

    ????? And a file foot?

    -----------

## Heiko.Kuhrt@t-online.de — 2003-01-20 10:19:47

    On Mon, Jan 20, 2003 at 05:09:16PM +1100, Manfred von Thun wrote:

     >

    > For both files output is plain text, not HTML, but my

    > web browser (lynx) does not mind that. Is it a problem with

                                              ^^^^^^^^^^^^^^^^^^^^

     > other browsers? At least for the "manual." command there is

       ^^^^^^^^^^^^^^^

     > also a variant which produces .tex output, and it should be

    > easy to add one that produces .html output.

    >

    >   - Manfred

     Well, not exactly a problem. It is just the feeling to be back in

    the seventies. (And with my Netscape it once was a problem in deed

    because the browser didn't insert line breaks.)

    Besides, in my opinion there should be one reference doc for all

    basic Joy definitions/atoms independent from the source they where

    defined in.

    Heiko

## Manfred von Thun — 2003-01-21 02:47:04

    On Mon, 20 Jan 2003 Heiko.Kuhrt@... wrote:

     > On Mon, Jan 20, 2003 at 05:09:16PM +1100, Manfred von Thun wrote:

    > >

    > > For both files output is plain text, not HTML, but my

    > > web browser (lynx) does not mind that. Is it a problem with

    >                                          ^^^^^^^^^^^^^^^^^^^^

    > > other browsers? At least for the "manual." command there is

    >   ^^^^^^^^^^^^^^^

    > > also a variant which produces .tex output, and it should be

    > > easy to add one that produces .html output.

    > >

    > >   - Manfred

    >

    > Well, not exactly a problem. It is just the feeling to be back in

    > the seventies. (And with my Netscape it once was a problem in deed

    > because the browser didn't insert line breaks.)

     I looked at the two text files using I*** E*** from M*** as a browser,

    and indeed they looked terrible:

      1. the text file from the  manual.  command, which contains just

         the inline documentation of the primitives (RAW Joy), has some

         lines that are just too long.

      2. the text file from the  help.  command, which contains just

         the names of primitives and the names of all defined functions

         when all libraries are loaded, consists of just one huge long

         line.

    So at least for these two text files there should be appropriate

    line breaks inserted by the Joy interpreter. This will also make

    the output look better when the two commands are used interactively.

    For 1., the  manual.  command, this could be done by inserting

    \n in all the too-long documentation strings inside the source file

    interp.c . Heiko: will such additional newlines interfere with Rabbit ?

    Since this is a tedious job, I'll wait with this until I hear from you.

    For 2., the  help.  command, the best looking output would result

    from taking the string length of each name and determining whether

    the name will still fit into the output line - if not, insert a

    newline first. Heiko: I take it that this will not have any

    implications for Rabbit ? (I propose to start on this as soon

    as I have finished marking some supplementary exams.)

    There is also the possibility of having several variants for

    the  manual.  command and the  help.  command.

    Run Joy, type the  _help. command (with the leading underscore).

    It will show you a few hidden "treasures" (?) such as

    the  __latexmanual.  command, which is like the  manual.  command

    but with lots of Latex flags. I have not used it for years, but

    it still works.

    And finally, if text files really look so bad in most browsers,

    it should be easy to insert

          <HTML> <PRE>   at the beginning of the output files, and

          </PRE> </HTML> at the end of the ouput files.

    I'm sure that can be done from the  update-tars.sh  file that

    produces the two output files. Either Joy or sh could do the

    two insertions.

     > Besides, in my opinion there should be one reference doc for all

    > basic Joy definitions/atoms independent from the source they where

                                                        ^^^^^^

     > defined in.

     By "source" do you mean

        1. which interpreter, like the current (only) one written in C

           as opposed to future ones which might be written in some

           other language (Java, Oberon, Lisp, Scheme, ...),

        2. whether they are primitives as opposed to defined in a

           library, or in which library.

    I certainly agree with your preference for a single doc.

      - Manfred

## Heiko.Kuhrt@t-online.de — 2003-01-21 12:21:04

    Hello Manfred, hello joyers,

    I would like to take the opportunity to say a few words about my Rabbit:

    When I started with Joy I had among others two problems:

    (1) I didn't know what to do with Joy.

    (2) I missed a handy documentation of these very all words defined in Joy.

        (The other papers like the tutorial I printed out and took my

        time to read, that was OK with me.)

    So I decided it would be a good idea, to write an html generator in Joy

    and with that generator a quick reference manual for Joy.

    Of course I would like if other people could take benefit from my

    work as I took benefit from yours.

    Well, I think I failed as Rabbit currently generates a 119 pages paper.

    That is not a quick reference.

    On the other hand when I'm working with Joy I'm using this reference

    and I find it pretty handy and easy to use.

    In my opinion it is worth some more development.

    And that is what I would like to do within the next months:

    (1) Come up with a version optimized for printing, that means

        pdf and ps format, maybe dvi and tex too what is no more work

        for me.

    (2) Revision of the content:

        (a) Documentation of external libraries.

        (b) Revision of existing content.

        (c) Catch up with changes of the Joy system.

    (3) Revision of the html version:

        (a) Integration with the print versions.

        (b) Revision of the html set up.

    (4) Integration of Rabbit and Joy interpreter docs, if desired:

        As a first guess I think the interpreter should make a Joy

        file containing the docs of the primitives, Rabbit loads that

        file, zips examples in and goes on.

    Currently I'm at stage (2b).

    I have the feeling the above is not too mutch work, but I don't

    have too mutch time to work on Joy, too. So, it's going to take

    a while.

    If I finished the above, in my very humble opinion the next step

    would be to ask if it is possible to make Rabbit the official

    documentation of Joy.

    That step would mean a further improvement of Rabbit and therefore

    a discussion in this mailing list. And it would mean that someone

    with more brain and theoretical background than me has to do a cross

    correction:

    () Content and appearance have to hold scientific strength.

    () Other programmers should be able to fit in their docs easily.

    () Other programmers should easily be able to do further development on

       Rabbit.

    () ...

    All that would be a lot of work and at the moment it is music of the

    future. Nevertheless, I have the feeling its a good idea to do a

    pre-discussion now. (What we just do.)

     >   - Manfred

     Best regards and herzliche Gruesse

    -Heiko

    (PS: A few days ago the Ostsee was down to 0 Deg. Celsius. I feared a strong

    winter. But that seems to be history by now.)

## Heiko.Kuhrt@t-online.de — 2003-01-21 12:14:46

    On Tue, Jan 21, 2003 at 01:47:04PM +1100, Manfred von Thun wrote:

     >

    >...

    >

    > For 1., the  manual.  command, this could be done by inserting

    > \n in all the too-long documentation strings inside the source file

    > interp.c . Heiko: will such additional newlines interfere with Rabbit ?

    > Since this is a tedious job, I'll wait with this until I hear from you.

    >

     No, there would be no interference with Rabbit. I just copied the specific

    parts out of interp.c, changed C to Joy by hand and made my own additions.

    For new updates I have to compare your interp.c file with my fundes.joy

    by hand, too. This is not difficult nor does it take too long but it is

    errortraechtig.

    But at some time it will be a hart job, because this has to be done for

    all libs, too.

     > For 2., the  help.  command, the best looking output would result

    > from taking the string length of each name and determining whether

    > the name will still fit into the output line - if not, insert a

    > newline first. Heiko: I take it that this will not have any

    > implications for Rabbit ? (I propose to start on this as soon

    > as I have finished marking some supplementary exams.)

    >

     True, there are no implications.

     > There is also the possibility of having several variants for

    > the  manual.  command and the  help.  command.

    > Run Joy, type the  _help. command (with the leading underscore).

    > It will show you a few hidden "treasures" (?) such as

    > the  __latexmanual.  command, which is like the  manual.  command

    > but with lots of Latex flags. I have not used it for years, but

    > it still works.

    >

     When I was new to Joy (what I still am) I never ever heard about latex,

    so __latexmanual was of no meaning to me. Last year I had to typeset

    a book, ended up with latex and got fascinated.

    I just tried out __latex_manual. I had to insert file head and foot and

    define two \newcommands: BX and JX. The output was OK, but

    !!! lots of lines are too long so that they are going

    !!! far over the right side of the paper. These parts

    !!! of the lines are not printed at all.

    To change that the interpreter should just not add the

    {\small\verb# ... #} command.

     > And finally, if text files really look so bad in most browsers,

    > it should be easy to insert

    >       <HTML> <PRE>   at the beginning of the output files, and

    >       </PRE> </HTML> at the end of the output files.

    > I'm sure that can be done from the  update-tars.sh  file that

    > produces the two output files. Either Joy or sh could do the

    > two insertions.

    >

     Hmmm, if I understand you right this doesn't change anything.

    I just inserted <html><pre>   </pre></html> in online-man.txt (the

    output of the _manual command), changed the file name to

    online-man.html and got exactly the same result from my browser.

    I think Mozilla switches to pre at text files by automatic.

    I think inserting the \n in the output of the manual command and

    a txt-file-extension, not html-extension  (as is) will do.

     > By "source" do you mean

    >     1. which interpreter, like the current (only) one written in C

    >        as opposed to future ones which might be written in some

    >        other language (Java, Oberon, Lisp, Scheme, ...),

    >     2. whether they are primitives as opposed to defined in a

    >        library, or in which library.

    > I certainly agree with your preference for a single doc.

    >

     By source I mean interp.c, inilib, agglib and so on as that are the

    places where Joy words are defined.

    But you are right, of course, it would be a great benefit if other

    implementations of Joy could use the same documentation.

     >   - Manfred

     Best regards and herzliche Gruesse

    -Heiko

## Manfred von Thun — 2003-01-24 01:02:44

    On Fri, 17 Jan 2003, ehz4 <ehz4@...> wrote:

     > I was wondering if there is a list of Joy primitives somewhere.

    > Preferably as part of a language description similar to Schemes' R5.

     I'm only now catching up with email, sorry about the delay.

    You may or may not have seen the new (and currently not yet nice

    looking) output from teh "manual." command:

    On the Joy page, Part 2 "Papers", Section 9 "The current ..",

    there is a link to "online manual".

      - Manfred

## Manfred von Thun — 2003-01-24 01:58:08

    On Tue, 21 Jan 2003 Heiko.Kuhrt@... wrote:

    [..]

    > No, there would be no interference with Rabbit. I just copied the specific

    > parts out of interp.c, changed C to Joy by hand and made my own additions.

    > For new updates I have to compare your interp.c file with my fundes.joy

    > by hand, too. This is not difficult nor does it take too long but it is

    > errortraechtig.

    Ja, Wahrheitstraechtig (Sorry folks - Krauts talking funny).

    See my comment below.

    [..]

    > > There is also the possibility of having several variants for

    > > the  manual.  command and the  help.  command.

    > > Run Joy, type the  _help. command (with the leading underscore).

    > > It will show you a few hidden "treasures" (?) such as

    > > the  __latexmanual.  command, which is like the  manual.  command

    > > but with lots of Latex flags. I have not used it for years, but

    > > it still works.

    > I just tried out __latex_manual. I had to insert file head and foot and

    > define two \newcommands: BX and JX.

    Yes, once upon a time they were indexing commands from when

    all the Joy papers were a latex book.

    >                                       The output was OK, but

    > !!! lots of lines are too long so that they are going

    > !!! far over the right side of the paper. These parts

    > !!! of the lines are not printed at all.

    > To change that the interpreter should just not add the

    > {\small\verb# ... #} command.

    >

    >

    > > And finally, if text files really look so bad in most browsers,

    > > it should be easy to insert

    > >       <HTML> <PRE>   at the beginning of the output files, and

    > >       </PRE> </HTML> at the end of the output files.

    > > I'm sure that can be done from the  update-tars.sh  file that

    > > produces the two output files. Either Joy or sh could do the

    > > two insertions.

    > >

    > Hmmm, if I understand you right this doesn't change anything.

    > I just inserted <html><pre>   </pre></html> in online-man.txt (the

    > output of the _manual command), changed the file name to

    > online-man.html and got exactly the same result from my browser.

    > I think Mozilla switches to pre at text files by automatic.

    > I think inserting the \n in the output of the manual command and

    > a txt-file-extension, not html-extension  (as is) will do.

    The upshot of all this seems to be: there should be several

    variants of the manual command:

      manual                        - for interactive use

      __latexstyle-manual           - with some changes, as you suggest

      __htmlstyle-manual            - just different flags

      __Joystyle-manual             - Joy format, suitable for rabbit

    The long documentation strings should also have appropriate \n

    inserted in the C-source.

    But I'll work on the output from the help command first, because

    that is the worst offender currently.

    [..]

    > By source I mean interp.c, inilib, agglib and so on as that are the

    > places where Joy words are defined.

    One problem will be with those functions that have very long bodies,

    as for example in the Lisp-in-Joy interpreter. Currently these

    libraries are formatted by hand, and fairly readable, in part because

    comments are still there. But output from commands like

        [ foo ]  helpdetail

    will give a (long) line without formatting. You'd get the same

    long unformatted line, without comments, from manual-like extension

    which gives primitives and currently defined functions. Must think

    about that.

    Melbourne forcast for tomorrow: 40 degrees Celsius.

      - Manfred

## Manfred von Thun — 2003-01-24 05:48:35

    On Fri, 24 Jan 2003, Manfred von Thun wrote:

    [..]

    > But I'll work on the output from the help command first, because

    > that is the worst offender currently.

    Done. See main Joy page, Part 3 "Papers", Section 9 "The current",

    the link to allhelp.html  -  try that in your browsers.

    In interp.c I changed the help command, which now adds \n

    as appropriate. I also changed update-tars.sh to insert the

    <HTML><PRE> and </PRE></HTML> at the front and end.

    So it is now an ordinary html file.

    [..]

      - Manfred

## Nick Forde — 2003-01-24 19:20:54

    Manfred,

    Manfred von Thun writes:

      > > I just tried out __latex_manual. I had to insert file head and foot and

     > > define two \newcommands: BX and JX.

     >

     > Yes, once upon a time they were indexing commands from when

     > all the Joy papers were a latex book.

     I had noticed your HTML papers had some Latex ghosts remaining. Do you

    still have the Latex source? I for one would appreciate PDF or PS

    versions of the Joy papers for printing.

    On a related note I've formatted your bibtex bibliography to be a bit

    more web friendly:

    http://www.system-7.freeserve.co.uk/joy/joybib/

    I've made a few small updates to your .bib file including adding URLs

    to your papers and Thomson's latests edition of "The Craft of

    Functional Programming".

    I haven't put the above in the concatenative group's file area because

    I couldn't upload multiple files through the web interface. Can anyone

    tell me whether this is possible? Is there FTP access to the group's

    file area?

    Regards,

    Nick.

## phimvt@lurac.latrobe.edu.au — 2003-01-28 02:04:45

    On Fri, 24 Jan 2003, Nick Forde wrote:

    [..]

    > I had noticed your HTML papers had some Latex ghosts remaining. Do you

    > still have the Latex source?

    Yes, I still have the sources somewhere. If you really want them,

    I'll dig them out for you and send them email. But they are well

    and truly out of date, and I can't even remember for which version of

    Latex they were written. In fact, I have not used Tex/Latex for

    over five years, I think, and consequently have forgotten all details.

    So I won't be able to help out, but I'll send whatever you want.

    [..]

    > On a related note I've formatted your bibtex bibliography to be a bit

    > more web friendly:

    >

    > http://www.system-7.freeserve.co.uk/joy/joybib/

    >

    > I've made a few small updates to your .bib file including adding URLs

    > to your papers and Thomson's latests edition of "The Craft of

    > Functional Programming".

    That's great. So far I have had only a superficial look at those

    pages, but they look good. Thanks.

    I'll now be working on the far-too-long lines from the manual

    command. Next, updating documentation. In the meantime maybe the

    discussion on modules will continue. I hear that python has a

    good module system - is it worth looking at in detail?

    Melbourne weather update: last saturday 44.1 degrees in some

    suburbs, hottest since 1939.

      - Manfred

## phimvt@lurac.latrobe.edu.au — 2003-02-03 05:02:29

    On Tue, 28 Jan 2003 phimvt@... wrote:

     > On Fri, 24 Jan 2003, Nick Forde wrote:

    >

    > > I had noticed your HTML papers had some Latex ghosts remaining. Do you

    > > still have the Latex source?

    >

    > Yes, I still have the sources somewhere. If you really want them,

    > I'll dig them out for you and send them email.

     Do you want them ?

     > > On a related note I've formatted your bibtex bibliography to be a bit

    > > more web friendly:

    > >

    > > http://www.system-7.freeserve.co.uk/joy/joybib/

     I take it that this is an invitation for me to "snarf" it ?

    [..]

     > I'll now be working on the far-too-long lines from the manual

    > command.

     That is done now. There are two versions, both as HTML pages:

      1. Essentially as it comes out of the "manual" command

         which is all the output that can come from the

         "helpdetail" command. Line breaks as inserted by hand.

      2. A special purpose version, just for HTML browsers

         using <DL> <DT> <DD> ... </DL> for each item.

    Both appear on the main Joy page, section 2. See what you think.

    I'll also be happy to modify the Latex version if whoever

    wants it lets me know exactly what flags they want inserted.

    And finally, if it helps, I can write a version which writes

    the manual as a Joy list of lists of three strings:

       [  ...

          ...

          [ "swap" "X Y  -->  Y X" "interchanges the top..."]

          ...

       ]

    But only if there is a real demand.

      - Manfred

## Nick Forde — 2003-02-03 11:00:16

    phimvt@... writes:

      >

     > On Tue, 28 Jan 2003 phimvt@... wrote:

     >

     > > On Fri, 24 Jan 2003, Nick Forde wrote:

     > >

     > > > I had noticed your HTML papers had some Latex ghosts remaining. Do you

     > > > still have the Latex source?

     > >

     > > Yes, I still have the sources somewhere. If you really want them,

     > > I'll dig them out for you and send them email.

     >

     > Do you want them ?

     If they're still in sync. with the web pages then, yes please.

      > > > On a related note I've formatted your bibtex bibliography to be a bit

     > > > more web friendly:

     > > >

     > > > http://www.system-7.freeserve.co.uk/joy/joybib/

     >

     > I take it that this is an invitation for me to "snarf" it ?

     Yes. It is built using a tool called bibtex2html

    (http://www-sop.inria.fr/epidaure/personnel/malandain/codes/bibtex2html.html).

    As the generated pages are split across multiple HTML files you'll

    have to run a recursive download using something like wget. If it is

    more convenient I can send you a tarkit.

      > [..]

     >

     > > I'll now be working on the far-too-long lines from the manual

     > > command.

     >

     > That is done now. There are two versions, both as HTML pages:

     >   1. Essentially as it comes out of the "manual" command

     >      which is all the output that can come from the

     >      "helpdetail" command. Line breaks as inserted by hand.

     >   2. A special purpose version, just for HTML browsers

     >      using <DL> <DT> <DD> ... </DL> for each item.

     Great.

      > Both appear on the main Joy page, section 2. See what you think.

     > I'll also be happy to modify the Latex version if whoever

     > wants it lets me know exactly what flags they want inserted.

     > And finally, if it helps, I can write a version which writes

     > the manual as a Joy list of lists of three strings:

     >    [  ...

     >       ...

     >       [ "swap" "X Y  -->  Y X" "interchanges the top..."]

     >       ...

     >    ]

     > But only if there is a real demand.

     Why not implement a primitive to return a list directly. A few simple

    Joy translators could then be used to create the HTML, Latex, text,

    Rabbit, or whatever from this.

    Nick.

## phimvt@lurac.latrobe.edu.au — 2003-02-17 05:27:51

    On Mon, 3 Feb 2003, Nick Forde wrote:

     > phimvt@... writes:

    >  >

    >  > On Tue, 28 Jan 2003 phimvt@... wrote:

    >  >

    >  > > On Fri, 24 Jan 2003, Nick Forde wrote:

    >  > >

    >  > > > I had noticed your HTML papers had some Latex ghosts remaining. Do you

    >  > > > still have the Latex source?

    >  > >

    >  > > Yes, I still have the sources somewhere. If you really want them,

    >  > > I'll dig them out for you and send them email.

    >  >

    >  > Do you want them ?

    >

    > If they're still in sync. with the web pages then, yes please.

     Unfortunately, yes, more or less. That is because apart from the

    "Tutorial" which I updated just a week ago, all the HTML/Latex papers

    are hopelessly out of date. I am in the process of rewriting as many

    as I can, with the "Implementation" j09imp.html paper next. So I'll

    start sending by email those which don't age so quickly: the "Math

    Foundation" perhaps first.

    [.. a propos versions of the online manual ..]

     >

    > Why not implement a primitive to return a list directly. A few simple

    > Joy translators could then be used to create the HTML, Latex, text,

    > Rabbit, or whatever from this.

     What a very sensible idea. Done. Only the file interp.c

    needed an additional operator. See the "_help" command for

    the less common things, it is "__manual_list". Try any of these:

        __manual_list   size.                             (* ==>  224 *)

        __manual_list   [first]  map.

        __manual_list   [put '\n put] step.

        __manual_list   [ [put] step ]  step.              etc.

    About the documentation for the command line arguments: There

    is no urgency at all. In fact it might be best if I write the

    first two parts for "running Joy", and when I have done that you

    can add your part in the same style at your leisure.

      - Manfred

## Nick Forde — 2003-02-17 14:50:15

    phimvt@... writes:

      > [.. a propos versions of the online manual ..]

     > >

     > > Why not implement a primitive to return a list directly. A few simple

     > > Joy translators could then be used to create the HTML, Latex, text,

     > > Rabbit, or whatever from this.

     >

     > What a very sensible idea. Done. Only the file interp.c

     > needed an additional operator. See the "_help" command for

     > the less common things, it is "__manual_list". Try any of these:

     >     __manual_list   size.                             (* ==>  224 *)

     >     __manual_list   [first]  map.

     >     __manual_list   [put '\n put] step.

     >     __manual_list   [ [put] step ]  step.              etc.

     Manfred,

    One problem with your implementation is that it's compiler/platform

    specific. I'd re-write to be:

    PRIVATE void manual_list_()

    {

    	Node *tmp;

    	Node *n = NULL;

    	int i = 0;

        while( optable[i].name ) {

    		tmp = STRING_NEWNODE( optable[i].messg2, NULL );

    		tmp = STRING_NEWNODE( optable[i].messg1, tmp );

    		tmp = STRING_NEWNODE( optable[i].name, tmp );

    		n = LIST_NEWNODE( tmp, n );

    		i++;

        }

        stk = LIST_NEWNODE(n, stk);

    }

    Ahh, the perils of mixing C macros and global variables :-)

    I've tested this on Linux, Solaris and HP-UX. I couldn't think why I'd

    care about the list order in the above hence you'll have to update

    this if you want to build from back to front of optable.

    I like the flexibility this gives and it helps keep the interpreter

    lightweight. Here's an alternative "undefs" implementation that pushes

    a list rather than printing to stdout.

    {"undefs",		undefs_,	"->",

    "Pushes a list of all undefined symbols in the current symbol table."},

    ...

    PRIVATE void undefs_(void)

    {

        Entry *i = symtabindex;

    	Node* n = 0;

        while (i != symtab) {

            if (((--i)->name[0] != 0) &&

    			(i->name[0] != '_') &&

    			(i->u.body == NULL)) {

    			n = STRING_NEWNODE( i->name, n );

    		}

    	}

    	stk = LIST_NEWNODE(n, stk);

    }

      > About the documentation for the command line arguments: There

     > is no urgency at all. In fact it might be best if I write the

     > first two parts for "running Joy", and when I have done that you

     > can add your part in the same style at your leisure.

     Sounds good to me.

    Regards,

    Nick.

## phimvt@lurac.latrobe.edu.au — 2003-02-19 02:26:45

    On Mon, 17 Feb 2003, Nick Forde wrote:

    [.. apropos a new function in interp.c which pushes a list

        of lists (one for each operator) of the three text strings

        of the manual command. I include the source here: ]

    PRIVATE void manual_list_()

    {

        int i = -1;

        Node *n = NULL;

        while (optable[++i].name) ; /* find end */

        --i; /* overshot */

        while (i)

          { n = LIST_NEWNODE(

    		STRING_NEWNODE(optable[i].name,

    		    STRING_NEWNODE(optable[i].messg1,

    			STRING_NEWNODE(optable[i].messg2, NULL) ) ),

    	    n );

    	--i; }

        stk = LIST_NEWNODE(n,stk);

    }

    > Manfred,

    >

    > One problem with your implementation is that it's compiler/platform

    > specific.

    In reply to this I had already constructed in my mind a proof

    that you are wrong: "The calls to ..NEWNODE all have parameters

    which need to be pushed onto the runtime stack before execution

    of ..NEWCODE begins. So the last call is completed first, and

    hence that node will be the end of the list as required ..etc etc ."

    But I think I now understand what you are saying: As the ..NEWNODE

    macros expand, the first parameter becomes a comma expression

    in which the first expression writes a global. But supposedly

    expressions can be evaluated in any order, hence the values

    of the global u when read by the second expression are not

    necessarily the ones the first expression was supposed to have

    written. Am I on the right track ?

    >          I'd re-write to be:

    >

    > PRIVATE void manual_list_()

    > {

    > 	Node *tmp;

    > 	Node *n = NULL;

    > 	int i = 0;

    >     while( optable[i].name ) {

    > 		tmp = STRING_NEWNODE( optable[i].messg2, NULL );

    > 		tmp = STRING_NEWNODE( optable[i].messg1, tmp );

    > 		tmp = STRING_NEWNODE( optable[i].name, tmp );

    > 		n = LIST_NEWNODE( tmp, n );

    > 		i++;

    >     }

    >     stk = LIST_NEWNODE(n, stk);

    > }

    And your solution uses a sequence of statements which must

    be executed in the order they are written. I get it.

    I'll use your solution instead.

    [...]

    Thanks

      - Manfred

## phimvt@lurac.latrobe.edu.au — 2003-02-19 04:58:27

    On Mon, 17 Feb 2003, Nick Forde wrote:

     >  > [.. a propos versions of the online manual ..]

     [..]

     > I've tested this on Linux, Solaris and HP-UX. I couldn't think why I'd

    > care about the list order in the above hence you'll have to update

    > this if you want to build from back to front of optable.

    >

    > I like the flexibility this gives and it helps keep the interpreter

    > lightweight. Here's an alternative "undefs" implementation that pushes

    > a list rather than printing to stdout.

     [..]

    OK, done both. Thanks.

      - Manfred

## John Cowan — 2003-02-19 12:14:49

    phimvt@... scripsit:

     > But I think I now understand what you are saying: As the ..NEWNODE

    > macros expand, the first parameter becomes a comma expression

    > in which the first expression writes a global. But supposedly

    > expressions can be evaluated in any order, hence the values

    > of the global u when read by the second expression are not

    > necessarily the ones the first expression was supposed to have

    > written. Am I on the right track ?

     In fact, if this is really a comma expression, it *is* guaranteed

    that the left operand is evaluated before the right operand.

    What is not guaranteed, however, is the order of execution of

    arguments to a function!

     > And your solution uses a sequence of statements which must

    > be executed in the order they are written. I get it.

    > I'll use your solution instead.

     This is surely easier to prove correct.

    --

    John Cowan           http://www.ccil.org/~cowan              cowan@...

    To say that Bilbo's breath was taken away is no description at all.  There

    are no words left to express his staggerment, since Men changed the language

    that they learned of elves in the days when all the world was wonderful.

            --_The Hobbit_