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_