RE: [stack] Rabbit
Billy Tanksley — 2001-10-02 17:49:51
Manfred von Thun — 2001-10-04 08:01:56
On Tue, 2 Oct 2001, Billy Tanksley wrote:
> Nice. Here's the actual link:
>
> http://groups.yahoo.com/group/concatenative/files/rabbit.html
>
> This is great!
Fully agree. It pleases me when other people write programs in Joy.
To do it full justice, though, I will have to put it into a form that
I can read on my 80 column terminal. Even switching it to "illegible
mode" (126 ? column) does not help because my newsreader (Lynx)
gives me 80 columns no matter what setting the terminal has.
I probably am in the minority here, and most people can read
long lines. I tend not to rely on that, and I also like to
print things on paper.
If I belong to the troglodyte minority you should ignore me.
We will also have to decide whether the new C-function that you
added should be put into the official version of Joy.
But I look forward to studying your program and the demo in detail
when I get around to removing the liberal sprinkling of tabs.
Thank you !
- Manfred
> From: Heiko.Kuhrt@... [mailto:Heiko.Kuhrt@...]
> >If you like it, please let me know what you think
> >about it. Winter comming, I should be able to put
> >some more ideas into it.
>
> >enjoy Joy
> >-Heiko
Manfred von Thun — 2001-10-08 05:10:28
On Thu, 4 Oct 2001, Manfred von Thun wrote:
>
> Thank you !
>
Yes, thank you very much. This is a fine program indeed.
I have now had an opportunity to see it from a more
sophisticated browser, with all the bells and whistles.
It is a good looking web page.
I have also started studing the Joy source.
It is a well designed Joy program, congratulations.
( In case somebody else had the same problem as I, do this:
1) replace every tab by two spaces,
2) before every == leave just one space
The program is very readable then, even from a simple terminal. )
Well done, keep it up.
Mit freundlichem Gruss
- Manfred (* ein Hamburger *)
Heiko.Kuhrt@t-online.de — 2001-10-12 11:33:16
Thank you very mutch for your encouragement.
But for different reasons the further development of my little project
will take some time.
Nevertheless, I will keep you posted as far as I put something usefull
together.
Best Greetings form the western outbacks of Rendsburg
-Heiko
Manfred von Thun — 2001-10-15 09:13:35
I have added a new paper to the Joy page,
"Imperative Thinking in Joy".
It is the latest Pearl (Examples of Programming in Joy):
http://www.latrobe.edu.au/philosophy/phimvt/joy/jp-imper.html
Essentially I wrote 5 programs in an imperative (fantasy-)language
and translated them to Joy. I think Billy will like them.
- Manfred
Ocie Mitchell — 2001-10-15 18:03:16
--- Manfred von Thun <
phimvt@...>
wrote:
> I have added a new paper to the Joy page,
> "Imperative Thinking in Joy".
> It is the latest Pearl (Examples of Programming in
> Joy):
>
>
http://www.latrobe.edu.au/philosophy/phimvt/joy/jp-imper.html
> Essentially I wrote 5 programs in an imperative
> (fantasy-)language
> and translated them to Joy. I think Billy will like
> them.
Interesting reading. It seems that the imperative
nature of joy can be used to perform the
initialization and finalization that in many
functional languages requires a separate function.
I think I may have stumbled upon a bug in the version
of joy I'm using. I was playing around with the unary
operator and tried the following:
1 1 [pop] unary .
1 1
[pop pop] unary .
Segmentation fault (core dumped)
Perhaps I don't completely understand the usage of
"unary", but it seems that the first program should
have removed one of the 1s from the stack. The second
one should probably give some sort of runtime error.
Ocie Mitchell
__________________________________________________
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com
Billy Tanksley — 2001-10-15 18:40:27
From: Manfred von Thun [mailto:
phimvt@...]
>I have added a new paper to the Joy page,
> "Imperative Thinking in Joy".
>It is the latest Pearl (Examples of Programming in Joy):
> http://www.latrobe.edu.au/philosophy/phimvt/joy/jp-imper.html
>Essentially I wrote 5 programs in an imperative (fantasy-)language
>and translated them to Joy. I think Billy will like them.
I do indeed. I believe that this page will do quite a bit to help people
understand how Joy relates to more common-looking languages.
OTOH:
1. This page also doesn't mention that Joy isn't "all about" translation;
just like human languages, you don't know the language yet if you have to
translate. You have to be able to *think* in it.
2. This page would be a great place to discuss word factorization. When you
list some pseudo-source code like this:
factorial ==
"initialise"
[ "body of loop" ]
times
"finalise"
Why not list it as closer to true source code, like this:
HIDE
initialise == ???;
body-of-loop == ???;
finalize == ???
IN
factorial ==
initialise
[ body-of-loop ]
times
finalise
END;
...and then develop from there?
3. And a final comment about my intentions: I wasn't so much talking about
how Joy could be developed in an imperative spirit, or how imperative
programs can easily be translated to Joy (although that IS an interesting
and useful fact). I was talking about the fact that imperative operations,
such as input and output, can be done without affecting the fundamental
methematical properties of the language. In fact, some change of global
state, such as dictionary manipulations, can be done without affecting Joy's
concatenativity.
A concatenative language, unlike an applicative one, can be functional _and_
imperative at the same time -- Forth comes very close to achieving this,
even though it _also_ makes some non-concatenative design choices.
> - Manfred
-Billy
Manfred von Thun — 2001-10-16 01:50:09
On Mon, 15 Oct 2001, Ocie Mitchell wrote:
> --- Manfred von Thun <phimvt@...> wrote:
> http://www.latrobe.edu.au/philosophy/phimvt/joy/jp-imper.html
>
> Interesting reading. It seems that the imperative
> nature of joy can be used to perform the
> initialization and finalization that in many
> functional languages requires a separate function.
Nice thought. It had not occurred to me explicitly before, although
I had been doing that sort of thing for quite some time.
>
> I think I may have stumbled upon a bug in the version
> of joy I'm using. I was playing around with the unary
> operator and tried the following:
>
> 1 1 [pop] unary .
> 1 1
> [pop pop] unary .
> Segmentation fault (core dumped)
Oops. How embarrassing. Thanks. I shall look into it.
- Manfred
Manfred von Thun — 2001-10-16 02:06:58
On Mon, 15 Oct 2001, Billy Tanksley wrote:
> From: Manfred von Thun [mailto:phimvt@...]
>
> >I have added a new paper to the Joy page,
> > "Imperative Thinking in Joy".
> >It is the latest Pearl (Examples of Programming in Joy):
> > http://www.latrobe.edu.au/philosophy/phimvt/joy/jp-imper.html
> >Essentially I wrote 5 programs in an imperative (fantasy-)language
> >and translated them to Joy. I think Billy will like them.
>
> I do indeed. I believe that this page will do quite a bit to help people
> understand how Joy relates to more common-looking languages.
>
> OTOH:
[deletion]
> 2. This page would be a great place to discuss word factorization. When you
> list some pseudo-source code like this:
>
> factorial ==
> "initialise"
> [ "body of loop" ]
> times
> "finalise"
>
> Why not list it as closer to true source code, like this:
>
> HIDE
> initialise == ???;
> body-of-loop == ???;
> finalize == ???
> IN
> factorial ==
> initialise
> [ body-of-loop ]
> times
> finalise
> END;
>
> ...and then develop from there?
That is a great idea. Develop the hidden parts separately
(more or less as I have done, but using the HIDE facility explicitly).
But when that is done: Use the _substitutional_ property of Joy to
eliminate the HIDEs afterwards, to arrive at the final
program as it is in the library.
I'll think about that more. Maybe for future Pearls.
[deletion]
>
> -Billy
I'll come back to the other two OTOHs (a new noun of the language?)
later.
- Manfred
Ocie Mitchell — 2001-10-16 17:03:33
--- Manfred von Thun <
phimvt@...>
wrote:
>
> On Mon, 15 Oct 2001, Ocie Mitchell wrote:
>
> > --- Manfred von Thun <phimvt@...>
> wrote:
>
> >
>
http://www.latrobe.edu.au/philosophy/phimvt/joy/jp-imper.html
> >
> > Interesting reading. It seems that the imperative
> > nature of joy can be used to perform the
> > initialization and finalization that in many
> > functional languages requires a separate function.
> Nice thought. It had not occurred to me explicitly
> before, although
> I had been doing that sort of thing for quite some
> time.
> >
> > I think I may have stumbled upon a bug in the
> version
> > of joy I'm using. I was playing around with the
> unary
> > operator and tried the following:
> >
> > 1 1 [pop] unary .
> > 1 1
> > [pop pop] unary .
> > Segmentation fault (core dumped)
> Oops. How embarrassing. Thanks. I shall look into
> it.
>
I took a look at this last night and I think I have a
fix. The problem is the following line in the N_ARY
function constructor (interp.c):
stk = newnode(stk->op, stk->u, TOP);
This is supposed to take the top item from the stack
and prepend it to the stack that was saved earlier.
The problem is that my example leaves the stack empty
(stk == NULL). My proposed fix is:
if (stk==NULL)
stk = TOP;
else
stk = newnode(stk->op, stk->u, TOP);
I don't trust the formatting of my mail reader, so I'm
enclosing the patch as an attachment.
Ocie
__________________________________________________
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com
[Non-text portions of this message have been removed]
Manfred von Thun — 2001-10-22 02:14:55
I am planning to go through the C-sources soon to fix a few matters:
1. Division by zero. This crashes when one or both of the
parameters are floats.
2. The file operator fremove works, but the way it works does not
agree with the online documentation. One of the two needs to be
negated. Normal C-convention is that success returns 0 (= "false"?),
failure returns a value > 0 (= "true"?). I can see the justification
for this convention. But I'm not sure it should be adopted for Joy,
and John Cowans online documentation suggests that he also thinks
that it should not. Any opinions ?
3. There is a bug in the unary combinator (and quite possibly in other
N-ary combinators). I include Ocie Mitchell's bug report and
proposed fix below.
It would help if members of the group would report on other known bugs
now so that everything can be fixed in one update.
- Manfred
On Tue, 16 Oct 2001, Ocie Mitchell wrote:
> > > I think I may have stumbled upon a bug in the version
> > > of joy I'm using. I was playing around with the unary
> > > operator and tried the following:
> > >
> > > 1 1 [pop] unary .
> > > 1 1
> > > [pop pop] unary .
> > > Segmentation fault (core dumped)
>
> I took a look at this last night and I think I have a
> fix. The problem is the following line in the N_ARY
> function constructor (interp.c):
>
> stk = newnode(stk->op, stk->u, TOP);
>
> This is supposed to take the top item from the stack
> and prepend it to the stack that was saved earlier.
> The problem is that my example leaves the stack empty
> (stk == NULL). My proposed fix is:
>
> if (stk==NULL)
> stk = TOP;
> else
> stk = newnode(stk->op, stk->u, TOP);
Louis Madon — 2001-10-22 03:46:02
> It would help if members of the group would report on other known bugs
> now so that everything can be fixed in one update.
The app4 combinator also has an easily fixed bug. Here is a test case
showing the problem:
1 2 3 4 5 [+] app4
=> 1 3 4 5 7 <-- this is wrong, TOS should be 6 not 7
This can be fixed in 'interp.c', line 1531. It currently reads:
SAVED4->next); /* just W on top */
simply change 'D4' to 'D5'.
Louis.
[Non-text portions of this message have been removed]
Manfred von Thun — 2001-10-23 04:00:14
On Mon, 22 Oct 2001, Louis Madon wrote:
[see below]
Thank you very much, another bug, another fix.
I'll use this opportunity to talk about the names of these
combinators: app2 app3 etc. The idea was that, given two
values on top of the stack, and then a quotation (which
typically but not always computes a unary function),
the app2 combinator "applies" that function to the two
values and replaces them by two results. But Joy has no
application at all, so the names are badly chosen. Instead
I propose to declare them obsolete, and replace them by
new names: unary2 unary3 etc. This is in line with another naming
convention that I have started using in inilib.joy,
where I have dup2, cons2, uncons2, map2. Any opinions ?
> The app4 combinator also has an easily fixed bug. Here is a test case
> showing the problem:
>
> 1 2 3 4 5 [+] app4
>
> => 1 3 4 5 7 <-- this is wrong, TOS should be 6 not 7
>
> This can be fixed in 'interp.c', line 1531. It currently reads:
>
> SAVED4->next); /* just W on top */
>
> simply change 'D4' to 'D5'.
>
> Louis.
Thanks again
- Manfred
Manfred von Thun — 2001-11-01 07:45:49
On Mon, 22 Oct 2001, Manfred von Thun wrote:
> I am planning to go through the C-sources soon to fix a few matters:
...
> It would help if members of the group would report on other known bugs
> now so that everything can be fixed in one update.
Special thanks to Ocie Mitchell and Heiko Kuhrt.
All known easy bugs fixed. See the new "Bugs and Fixes" page
in section 3 of the main Joy page.
- Manfred
Heiko.Kuhrt@t-online.de — 2001-11-01 15:22:27
I missed your first call for c-bugs, sorry for that.
This is what I think should be changed:
(1) As its master, so Joy doesn't like long lines. This is
sometimes leading to cryptic error-messages like
"'functionna' not defined" where 'functionname' is defined
but its call happens to appear somewhere to the end of long lines.
(2) abs returns float when applied to an integer.
Extract from my wish-list:
For all sorts of text-processing it would be nice to have
multi-line-strings.
Beside these minor points joy works as far as I can see
just perfect.
In "Rationale for Joy" you say: "In all aspects Joy is still in its infancy
and cannot compete with the mature languages."
In my opinion you should at least take some of the stress out of this sentence
or delete it at all.
-Heiko
(*===========================================================================*)
run == ["A 2345678 B 2345678 C 2345678 D 2345678 E 2345678 F 2345678 G 2345678 H 23456789"] 999 put put;
run2 == [
"A 2345678 B 2345678 C 2345678 D 2345678 E 2345678 F 2345678 G 2345678 H 23456789"
] 99 put put;
run3 == [
"A 2345678 B 2345678 C 234567
8 D 2345678 E 2345678 F 2345678 G 2345678 H 23456789"
] 9 put put;
ret == -1 abs dup integer put float put;
(*===========================================================================*)
run newline run2 newline run3 newline ret.
(*===========================================================================*)
=>
999 ["A 2345678 B 2345678 C 23456789"]
99 ["A 2345678 B 2345678 C 2345678 D 2345678 E 2345678 F 23456"]
9 ["A 2345678 B 2345678 C 234567" 8 D 2345678 E 2345678 G 2345678 H 23456789 ""]
false true
John Cowan — 2001-11-01 15:57:47
Heiko.Kuhrt@... wrote:
> (2) abs returns float when applied to an integer.
To fix this, change the following line in the abs_ function in interp.c:
FLOAT_U(fabs)
to
if (stk->op == FLOAT_)
{ UNARY(FLOAT_NEWNODE, fabs(stk->u.dbl)); return; }
The FLOAT_U macro accepts integers or floats and forces a float
result, which is not what we want with abs.
> For all sorts of text-processing it would be nice to have
> multi-line-strings.
You can create multi-line strings using the escape "\n" in a string
directly, or with [[string1 "\n" string2 "\n"] "" [concat] fold]
programmatically.
--
Not to perambulate || John Cowan <
jcowan@...>
the corridors ||
http://www.reutershealth.com
during the hours of repose ||
http://www.ccil.org/~cowan
in the boots of ascension. \\ Sign in Austrian ski-resort hotel
Heiko.Kuhrt@t-online.de — 2001-11-01 20:01:27
On Thu, 1 Nov 2001, John Cowan wrote:
> Heiko.Kuhrt@... wrote:
>
>
> > For all sorts of text-processing it would be nice to have
> > multi-line-strings.
>
>
> You can create multi-line strings using the escape "\n" in a string
> directly, or with [[string1 "\n" string2 "\n"] "" [concat] fold]
> programmatically.
Exactly this is what I would like to leave to the system.
-Heiko
John Cowan — 2001-11-02 11:34:04
Heiko.Kuhrt@... scripsit:
> Exactly this is what I would like to leave to the system.
Tell me what you would like to see, specifically.
--
John Cowan
http://www.ccil.org/~cowan cowan@...
Please leave your values | Check your assumptions. In fact,
at the front desk. | check your assumptions at the door.
--sign in Paris hotel | --Miles Vorkosigan
Heiko.Kuhrt@t-online.de — 2001-11-02 12:15:24
from interp.c:
>PRIVATE void times_()
>{
> int i,n;
> TWOPARAMS("times");
> ONEQUOTE("times");
> INTEGER2("times");
> SAVESTACK;
> stk = stk->next->next;
> n = SAVED2->u.num;
> for (i = 1; i <= n; i++)
> exeterm(SAVED1->u.lis);
> POP(dump);
>}
...
>{"times", times_, "[P] N -> ...",
>"Executes P N times."},
it should be: "N [P] -> ..."
-Heiko
Heiko.Kuhrt@t-online.de — 2001-11-02 12:35:47
(* the following is an arbitrary part out of my little rabbit, as it works today: *)
home ==
"Atoms and Definitions of JOY"simple-logo
"October 2001" headline
"Abstract"subtitle
["This document is containing a brief description of all Atoms, "
"defined by the JOY-System and of all visible definitions, defined in the "
"following Libraries: "
"stdlib, inilib, agglib, seqlib, typelib, numlib, tutlib and matrlib."
br br
"This document is very incomplete. "
"This is true for the description of a lot of "
"definitions, but also for the way to put things into classes. "
"For further improvement I'm subject to your advice. "
] blockquote
;
(*====================*)
(* this is what would be nice *)
home ==
"Atoms and Definitions of JOY"simple-logo
"October 2001" headline
"Abstract"subtitle
[
"This document is containing a brief description of all Atoms,
defined by the JOY-System and of all visible definitions, defined in the
following Libraries:
stdlib, inilib, agglib, seqlib, typelib, numlib, tutlib and matrlib."
br br
"This document is very incomplete.
This is true for the description of a lot of
definitions, but also for the way to put things into classes.
For further improvement I'm subject to your advice. "
] blockquote
;
(*==================*)
scheme does it as above, Python has a more complex way, but it ends up
at the same result.
In this special case it would not matter if the resulting string is containing
some "\n" and "\t". In most other cases the newlines would be useful.
best regards
-Heiko
Reuben Thomas — 2001-11-02 21:33:39
> Special thanks to Ocie Mitchell and Heiko Kuhrt.
> All known easy bugs fixed. See the new "Bugs and Fixes" page
> in section 3 of the main Joy page.
First, I take it that thanks to followups to this message, a couple
more small fixes have been made. Secondly, I couldn't find where I
could actually download the newest version. In particular, John
Cowan's joy.tar.gz (or at least one of the links thereto on the Joy
pages; confusingly there is more than one) isn't up to date, and the
"minimal files" list is still dated 18-June-01.
Where should I look?
Also, it would be nice if joy.tar.gz could have a version number
(needn't mean anything in particular, just be incremented each time
the archive is updated) and not unpack into the current directory, but
into joy-x.yy/ (or whatever).
--
http://sc3d.org/rrt/ | Si hoc legere scis nimium eruditionis habes (Anon)
Manfred von Thun — 2001-11-03 05:06:29
On Fri, 2 Nov 2001, Reuben Thomas wrote:
> First, I take it that thanks to followups to this message, a couple
> more small fixes have been made. Secondly, I couldn't find where I
> could actually download the newest version. In particular, John
> Cowan's joy.tar.gz (or at least one of the links thereto on the Joy
> pages; confusingly there is more than one) isn't up to date, and the
> "minimal files" list is still dated 18-June-01.
>
> Where should I look?
My apologies, my description on the ---NEW--- part was unclear,
and some of my dates are out of date.
To update: just get the new version of interp.c (there is
a link from "minimal files" j1src.html) and recompile.
Also, it is probably a good idea to get all the new libraries,
from joylibs.tar.gz
Sorry about that
- Manfred
Reuben Thomas — 2001-11-03 10:59:37
> To update: just get the new version of interp.c (there is
> a link from "minimal files" j1src.html) and recompile.
Thanks very much. It's pretty easy to update the main archive too, so
maybe you could do that each time a file is updated. You could also
have an archive of the minimal sources, because I guess the rest of
the complete archive (the garbage collector &c.) is unlikely to change
much. If the minimal archive could be arranged in the same directory
structure so you can just unpack it on top of the big archive and
recompile, that would be excellent.
--
http://sc3d.org/rrt/ | Analogy is a midwife, identity a murderer
Manfred von Thun — 2001-11-07 07:09:19
On Sat, 3 Nov 2001, Reuben Thomas wrote:
> > To update: just get the new version of interp.c (there is
> > a link from "minimal files" j1src.html) and recompile.
>
> Thanks very much. It's pretty easy to update the main archive too, so
> maybe you could do that each time a file is updated. You could also
> have an archive of the minimal sources, because I guess the rest of
> the complete archive (the garbage collector &c.) is unlikely to change
> much. If the minimal archive could be arranged in the same directory
> structure so you can just unpack it on top of the big archive and
> recompile, that would be excellent.
Yes, all that was highly overdue.
Well, this old dog has learnt a few new tricks about
sh tar gzip make Makefile etc.
Updating all four(!) *.tar.gz is now (almost) automatic after any
significant change.
There is also a new joydir.txt (section 1), sorted by access, that is
simultaneously updated. I think it will be useful.
I'm sorry I have caused confusion.
-Manfred
Manfred von Thun — 2001-11-07 07:47:09
On Fri, 2 Nov 2001, John Cowan wrote:
> Heiko.Kuhrt@... scripsit:
...apropos string literals extending over several input lines...
> > Exactly this is what I would like to leave to the system.
>
> Tell me what you would like to see, specifically.
When I was a novice programmer in Pascal, I used to get annoyed
about the restriction that strings could not extend over one line.
Later I got used to it, and it caused no real problems.
I also started programming in Prolog, which did allow strings
to extend over one line, and I used that a fair bit. But
there were occasions when I left out the closing quote,
and that resulted in incomprehensible behaviour from the
system. I cannot remember the details, but it was excruciating.
If one were to allow strings to extend over one line in Joy,
but one forgets (or accidentally deletes) the closing quote,
then each or all of the following might happen:
1. There is another string in the current input file,
and its opening quote is taken for the missing closing
quote. The content of that strings is then scanned with
normally disastrous results.
2. There is no other string in the current input file,
so the stack of input files is popped and the previous
input file is read up to the first opening quote -
see above.
3. After the pop of the stack of input files there is no
opening quote, and a further pop occurs, up to the point
where input is back to the initial inputfile (normally
the keyboard). If it is the keyboard, then it will
put anything typed into the string and wait for a quote -
see above. If it is not the keyboard but a file, it will
have to exit for lack of input.
One could allow strings to extend over one line, but with a
restriction that the closing quote MUST occur within the same
file. That would stop behaviours 2. and 3. There should also
be a warning message for the first newline in the string.
Or maybe that should be the default, and such a warning
could be stopped by another(!) flag, if one is brave.
So, as far as the user is concerned, allowing strings to
extend over several lines might be useful even if it can
introduce strange behaviour.
But the implementation (in file scan.c) is not entirely
straightforward, because Joy will not know in advance
how long the string will be, and how much to malloc.
I have some ideas about this, they involve doubling
the malloced size when needed and strcpy what has been
stored so far. It would not be pretty.
It would be interesting to know how other languages handle
the user interface and the implementation.
This will have to do for the moment.
-Manfred
Heiko.Kuhrt@t-online.de — 2001-11-08 16:03:14
On Wed, 7 Nov 2001, Manfred von Thun wrote:
>
> On Fri, 2 Nov 2001, John Cowan wrote:
>
> > Heiko.Kuhrt@... scripsit:
>
> ...apropos string literals extending over several input lines...
>
> > > Exactly this is what I would like to leave to the system.
> >
> > Tell me what you would like to see, specifically.
>
> When I was a novice programmer in Pascal, I used to get annoyed
> about the restriction that strings could not extend over one line.
> Later I got used to it, and it caused no real problems.
>
By accident I had a look into globals.h and found
#define INPLINEMAX 80
I changed to #define INPLINEMAX 255 and am happy!
-Heiko
Manfred von Thun — 2001-11-09 00:43:56
On Thu, 8 Nov 2001
Heiko.Kuhrt@... wrote:
>
> By accident I had a look into globals.h and found
>
> #define INPLINEMAX 80
>
> I changed to #define INPLINEMAX 255 and am happy!
^^^^^ Good
I thought you meant something much more substantial.
It is a reasonable change. I'll put it in the next release.
But it is such a small modification that I won't update just yet.
-Manfred
Manfred von Thun — 2001-11-23 09:10:58
I have added a new Joy library for "lazy" lists, and also
a test file with output from that. See the main Joy page.
- Manfred
Jack Waugh — 2001-11-26 14:28:09
Cool. Your representation works as follows (as I abstract from the
basic functions you provide):
- The empty list is represented by the empty list.
- A nonempty list is represented by a two-element list,
where the first element is the first element of the
list represented, and the second element of the
representation is a program to push the representation
of the rest of the lazy list.
Your representation exhibits less complexity than mine (
http://groups.yahoo.com/group/concatenative/message/774
). My representation kept a "state" from which it computed
each list element.
From the test output, it appears that Take doesn't yield a
lazy list.
Manfred von Thun — 2001-11-28 03:32:30
On Mon, 26 Nov 2001, Jack Waugh wrote:
> Cool.
Yup. Real red hot cool, to coin a phrase.
> Your representation works as follows (as I abstract from the
> basic functions you provide):
>
> - The empty list is represented by the empty list.
>
> - A nonempty list is represented by a two-element list,
> where the first element is the first element of the
> list represented, and the second element of the
> representation is a program to push the representation
> of the rest of the lazy list.
Yes, that is about right.
> Your representation exhibits less complexity than mine
> (http://groups.yahoo.com/group/concatenative/message/774).
Less complex, yes, I think so.
I tried several times to understand your version, but I
never saw through it well enough to be able to write it
as a Joy program. Did you ever get it to run?
> My representation kept a "state" from which it computed
> each list element.
My version was based on what I think is a pretty standard
way of implementing it: Abelson & Sussman's _Structure and
Interpretation of Computer Programs_. What you called
your state seems to be the lambda abstraction in Scheme,
and the quotation in my version in Joy.
> From the test output, it appears that Take doesn't yield a
> lazy list.
Correct. That was the simplest way. Whether that is the best
way is open for discussion.
My version does not allow what might be called "mixed lists",
partly evaluated and partly lazy, such as [ 5 6 7 8... ].
Probably it would not be too hard to do this modification.
You might still write a Joy library and a demo based on your
representation, and I would be glad to see it.
- Manfred