logolib, functional programming
Author Message
logolib, functional programming

Quote:

>  Yehuda, Sabbath Shalom!   I think we have a bonafide solution to the
>  vexation we had a while back.

Edwin, Shavu'a Tov (="good [new] week"),
I think it was George who taught me to save a file directly from MSWLogo to
logolib, *wrapping the name between quotation marks*. I'm about 10,000
miles away
from my computer so I can't verify it - just depending on my deteriorating
memory.
In any case, this problems never occurred to me, because I used to supply to my
students floppies of MSWLogo, together with my full logolib directory.

Quote:
> Well, I'm struggling with all the twists, turns and transitions.  I don't
> feel the script flowing smoothly.  Somehow I'll figure this out and find a
> path from the functional to the step-wise FD 100 approach.  However, if
> anyone has any outlines they've tried, please let me know.

Edwin,

When I taught functional programming Logo, I began with the following example:
Write a procedure to find the max of 2 given numbers. Can you use your above
procedure, unmodified, to find the max of 3 numbers? 4 numbers? Answer: No.
Now let's write a *function* to find the max of 2 given numbers:

to max :a :b
if :a>:b[output :a]
output :b
end

{
This can, incidentally, be written also as:
to max :a :b
output ifelse :a>:b[:a][:b]
end

Quote:
}

Now, to find the max of 3 numbers you can write:
pr max :a max :b :c
or
pr max max :a :b :c

I would then ask, in how many ways you can write an expression to find the
max of
4 given numbers.

Quote:
>From here it will be, I think, easier to approach more aspects of functional

programming.

I hope this helps, Yehuda (Baltimore, MD)

To unsubscribe from this group, send an email to:

LogoForum messages are archived at:
http://www.*-*-*.com/

Your use of Yahoo! Groups is subject to http://www.*-*-*.com/

Fri, 20 Feb 2004 11:26:14 GMT
logolib, functional programming

Quote:

>I think it was George who taught me to save a file directly from MSWLogo to
>logolib, *wrapping the name between quotation marks*. I'm about 10,000

This can't be right -- perhaps you mean between vertical bars, as in
save "|logolib\\foo|
although I don't see how the vertical bars help, since you still have to
double up the backslashes.

Fri, 20 Feb 2004 23:17:24 GMT
logolib, functional programming
Hey, Brian!

Quote:
>This can't be right -- perhaps you mean between vertical bars,
>as in save "|logolib\\foo|
>although I don't see how the vertical bars help, since you still have to
>double up the backslashes.

You don`t need those backslashes, just use slashes instead.
At least on my computer this works (Windooze 98).
For example:
chdir "../ucblogo

btw, I found out how to replace the gotos in eval.c
without cluttering the stack. :-))
So there`s a class Evaluator right now!-)

But I still have no garbage collector,
although I now have understood how to construct one. ~:-/

Cheers!-)
Andreas

Sat, 21 Feb 2004 01:56:50 GMT
logolib, functional programming
See how little I knew.  I didn't realize IF with a third argument acted like
an IFELSE.  Hummm, I think I'd better review all of the Control Commands and
understand Logo more thoroughly.  Let's see ... there's IFTRUE, IFFALSE,
TRUE, CATCH, THROW, ...

Actually, I think I need to seriously study all of Logo.  I had settled with
the self-assurance that my quick reads were sufficient.  Since I haven't
needed them, I just never bothered to really learn them.  Tsk, tsk ... bad
boy!

Not for long,
:-)  edwin

Quote:
-----Original Message-----

Sent: Sunday, September 02, 2001 9:31 AM

Subject: [LogoForum] logolib, functional programming

Edwin,

When I taught functional programming Logo, I began with the following
example:
Write a procedure to find the max of 2 given numbers. Can you use your above
procedure, unmodified, to find the max of 3 numbers? 4 numbers? Answer: No.
Now let's write a *function* to find the max of 2 given numbers:

to max :a :b
if :a>:b[output :a]
output :b
end

{
This can, incidentally, be written also as:
to max :a :b
output ifelse :a>:b[:a][:b]
end
}

To unsubscribe from this group, send an email to:

LogoForum messages are archived at:
http://groups.yahoo.com/group/LogoForum

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

Sat, 21 Feb 2004 12:34:46 GMT
logolib, functional programming
I *thought* I understood Logo, until I started going in-depth to write a new
Logo interpreter... WOW, it's amazing what you find out.

Anyway, back to "IF".
IF acts like IFELSE I think due to historical reasons. doubled up with the
fact that in most languages you can use "IF" in both "IF" and "IFELSE"
forms. Using IF in the IFELSE form is dangerous in LOGO (you might not
always get the IFELSE form) which is why UCBLOGO/MSWLOGO gives a warning if
you use it that way.

Quote:
-----Original Message-----

Sent: Monday, September 03, 2001 12:43 AM

Subject: RE: [LogoForum] logolib, functional programming

See how little I knew.  I didn't realize IF with a third argument acted like
an IFELSE.  Hummm, I think I'd better review all of the Control Commands and
understand Logo more thoroughly.  Let's see ... there's IFTRUE, IFFALSE,
TRUE, CATCH, THROW, ...

Actually, I think I need to seriously study all of Logo.  I had settled with
the self-assurance that my quick reads were sufficient.  Since I haven't
needed them, I just never bothered to really learn them.  Tsk, tsk ... bad
boy!

Not for long,
:-)  edwin

-----Original Message-----

Sent: Sunday, September 02, 2001 9:31 AM

Subject: [LogoForum] logolib, functional programming

Edwin,

When I taught functional programming Logo, I began with the following
example:
Write a procedure to find the max of 2 given numbers. Can you use your above
procedure, unmodified, to find the max of 3 numbers? 4 numbers? Answer: No.
Now let's write a *function* to find the max of 2 given numbers:

to max :a :b
if :a>:b[output :a]
output :b
end

{
This can, incidentally, be written also as:
to max :a :b
output ifelse :a>:b[:a][:b]
end
}

To unsubscribe from this group, send an email to:

LogoForum messages are archived at:
http://groups.yahoo.com/group/LogoForum

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

To unsubscribe from this group, send an email to:

LogoForum messages are archived at:
http://groups.yahoo.com/group/LogoForum

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

Sat, 21 Feb 2004 12:39:07 GMT
logolib, functional programming
All versions of Windows (and DOS since MSDOS v2) allows interchanging of "/"
and "\" in low level API's to access files. The convention of using "\" was
because DOS uses "/" for command line switches.

Andreas, I'm not sure how you solved the evaluator solution, but two that I
considered.
1) big switch statement
2) using member functions.
I used approach (2). The main pump simply "pops" a member function and calls
it. I find it much more maintainable than the code in eval.c.

Quote:
-----Original Message-----

Sent: Monday, September 03, 2001 9:49 PM

Subject: Re: [LogoForum] logolib, functional programming

Hey, Brian!

>This can't be right -- perhaps you mean between vertical bars,
>as in save "|logolib\\foo|
>although I don't see how the vertical bars help, since you still have to
>double up the backslashes.

You don`t need those backslashes, just use slashes instead.
At least on my computer this works (Windooze 98).
For example:
chdir "../ucblogo

btw, I found out how to replace the gotos in eval.c
without cluttering the stack. :-))
So there`s a class Evaluator right now!-)

But I still have no garbage collector,
although I now have understood how to construct one. ~:-/

Cheers!-)
Andreas

To unsubscribe from this group, send an email to:

LogoForum messages are archived at:
http://groups.yahoo.com/group/LogoForum

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

To unsubscribe from this group, send an email to:

LogoForum messages are archived at:
http://groups.yahoo.com/group/LogoForum

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

Sat, 21 Feb 2004 20:03:02 GMT
logolib, functional programming

Quote:

>Andreas, I'm not sure how you solved the evaluator solution, but two that I
>considered.
>1) big switch statement
>2) using member functions.
>I used approach (2). The main pump simply "pops" a member function and calls
>it. I find it much more maintainable than the code in eval.c.

If one of you guys manages to understand the finite state machine
represented by the val_status variable and can clean up the mess it encodes,
that would be terrific -- much more important, imho, than eliminating GOTOs.
Even though I wrote that code, I don't really understand it myself, and
there are situations in which it fails (not by doing the wrong thing, really,
but by giving the wrong error message).  The worst bugaboo is the
XXX didn't output to YYY  in ZZZ
message.  Because you want tail call elimination to be invisible to the
user, it's hard to get XXX, YYY, and ZZZ all correct while still not
growing the stack.  The other message val_status controls is
You don't say what to do with WWW

My current difficulty is
to foo
output run [...an_instruction...   ...an_expression...]
end
I think this is it... the results depend on whether the instruction
uses a primitive or a defined procedure.  I haven't been able to fix
this without making this a non-tail call.

Sun, 22 Feb 2004 04:04:36 GMT
logolib, functional programming
When I was looking at the combination of all the different state variables,
I started pulling my hair out. I totally re-wrote the evaluator and came out
with a much simpler way of tracking the allowed outcomes. I personally think
the evaluator has come out much simpler too. I'll let you know once I'm sure
this stuff works properly (still got a few late nights to go :-).

BTW, on the "OR" subject, I wrote a delayed-evaluating OR as part of the
Tic-Tac-Toe tutorial on http://www.thehunters.org/logo I was wondering about
having two versions of 'OR' but what you said in the other thread makes
sense so at some point I'll have to encorporate it.

Jamie

Quote:
-----Original Message-----
From: Brian Harvey
Sent: Tuesday, September 04, 2001 8:49 PM

Subject: Re: [LogoForum] logolib, functional programming

>Andreas, I'm not sure how you solved the evaluator solution, but two
that I
>considered.
>1) big switch statement
>2) using member functions.
>I used approach (2). The main pump simply "pops" a member function and
calls
>it. I find it much more maintainable than the code in eval.c.

If one of you guys manages to understand the finite state machine
represented by the val_status variable and can clean up the mess it
encodes,
that would be terrific -- much more important, imho, than eliminating
GOTOs.
Even though I wrote that code, I don't really understand it myself, and
there are situations in which it fails (not by doing the wrong thing,
really,
but by giving the wrong error message).  The worst bugaboo is the
XXX didn't output to YYY  in ZZZ
message.  Because you want tail call elimination to be invisible to the
user, it's hard to get XXX, YYY, and ZZZ all correct while still not
growing the stack.  The other message val_status controls is
You don't say what to do with WWW

My current difficulty is
to foo
output run [...an_instruction...   ...an_expression...]
end
I think this is it... the results depend on whether the instruction
uses a primitive or a defined procedure.  I haven't been able to fix
this without making this a non-tail call.

To unsubscribe from this group, send an email to:

LogoForum messages are archived at:
http://groups.yahoo.com/group/LogoForum

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

To unsubscribe from this group, send an email to:

LogoForum messages are archived at:
http://groups.yahoo.com/group/LogoForum

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

Sun, 22 Feb 2004 20:21:00 GMT
logolib, functional programming

Quote:

>When I was looking at the combination of all the different state variables,
>I started pulling my hair out.

Yeah, me too!  :-)  If you can really preserve tail call elimination and
correct error messages with a simpler strategy, I'll be really really happy.

Sun, 22 Feb 2004 23:32:31 GMT
logolib, functional programming

Quote:
>>When I was looking at the combination of all the different state
variables,
>>I started pulling my hair out.

>Yeah, me too!  :-)
>If you can really preserve tail call elimination and
>correct error messages with a simpler strategy,
>I'll be really really happy.

I want to keep my hair as long as nature lets me ;-)
but unfortunately I have not so much time as to fully rewrite UCBLogo.
So I simply replaced the val_status number constants with this

enum Val_status
{
no_value_allowed,  // body of command  0
value_required,  // argument  1
output_ok,  // body of function  2
dont_care,  // function inside catch  3
no_value_in_macro,  // repeat  4
value_maybe_ok_in_macro  // catch  5

Quote:
};

and

enum TailCall
{
tailcall_arg=-1,
in_sequence,  // 0
tailcall_tail,  // 1

Quote:
};

which is at least a good start to allow easier source code reading, I think.

btw, Jamie, what GC do you use in your Logo?
I`m trying to decide if I should try to understand either
mem.c,
the Boehm-Demers-Weiser collector
or the Bartlett collector.
I don`t know which would be the fastest for UCBLogo.
Also clearness of the GC interface is an issue.
And, I don`t want to have to modify much of existing code.

Sat, 28 Feb 2004 13:07:18 GMT
logolib, functional programming
Nice clean solution starts getting hard when I introduce TailCall :-)
Actually this seems to be going well.

My main question/concern here is regards CATCH "Foo [nontail output
tailcall] etc
The tailcall still needs to be caught... is this a matter of merging all
same catches together?

Quote:
-----Original Message-----
From: Brian Harvey
Sent: Wednesday, September 12, 2001 10:31 PM

Subject: Re: [LogoForum] logolib, functional programming

>Do you have any good tail call test cases?

Well, first of all, check that the following are in fact tail-called:

run [nontail output tailcall]
run [nontail tailcall stop]
output run [nontail tailcall]
run [nontail tailcall] stop

where NONTAIL is zero or more procedure calls (including primitive and
user-defined procedures) and TAILCALL is the one that shouldn't grow
the stack.  Also, try replacing RUN in these examples with IF "TRUE
and with CATCH "FOO.

Then comes the check for errors.  The basic situation is

to a
output b
end

to b
end

Then PRINT A should give the message "B didn't output to A" rather
than either "B didn't output to PRINT" or "A didn't output to PRINT."
Try replacing the line OUTPUT B with all the tail-call trials above.

Situation 2 is

to a
b
end

to b
end

Then PRINT A should say "A didn't output to PRINT."

Situation 3:

to a
b
end

to b
output 3
end

PRINT A should now say "You don't say what to do with 3  in A."

Try all of these calling A alone rather than PRINT A and see what
you get.  The general principle is that you should get the same
error message that you'd get if you weren't doing tail call
elimination.

Thu, 04 Mar 2004 12:59:05 GMT
logolib, functional programming

Quote:

>My main question/concern here is regards CATCH "Foo [nontail output
>tailcall] etc
>The tailcall still needs to be caught... is this a matter of merging all
>same catches together?

Oops, maybe you're right -- I guess that one can't be a tail call.
Sorry!

Fri, 05 Mar 2004 00:47:57 GMT

 Page 1 of 1 [ 12 post ]

Relevant Pages