LOGO-L> predicate writing 
Author Message
 LOGO-L> predicate writing

I've been trying to rewrite some of the predicates that are included as
primitive procedures in MSWLogo. This is what I've written for memberp:

to ismember :letter :word
    if :word = " [output "false]
    if :letter = first :word [output "true]
    ismember :letter butfirst :word
end

when I type:
print ismember "u "house
the complaint is "You don't say what to do with true

when I type:
print ismember "u "garden
the complaint is "You don't say what to do with false

Can anyone tell me why?

---------------------------------------------------------------





Sun, 28 Apr 2002 03:00:00 GMT  
 LOGO-L> predicate writing
Paul:

Thank you - yes, that works.
(I could find lots of examples predicate procedures, but none that used
recursion.)

Simone

Quote:


> > I've been trying to rewrite some of the predicates that are included as
> > primitive procedures in MSWLogo. This is what I've written for memberp:

> > to ismember :letter :word
> >     if :word = " [output "false]
> >     if :letter = first :word [output "true]
> >     ismember :letter butfirst :word
> > end

> > when I type:
> > print ismember "u "house
> > the complaint is "You don't say what to do with true

> > when I type:
> > print ismember "u "garden
> > the complaint is "You don't say what to do with false

> > Can anyone tell me why?

> Because, in the third case -- the recursive one -- you don't output
> anything;

> Try this:

> to ismember :letter :word
>     if :word = " [output "false]
>     if :letter = first :word [output "true]
>     output ismember :letter butfirst :word
> end

> Hope that helps.

---------------------------------------------------------------





Sun, 28 Apr 2002 03:00:00 GMT  
 LOGO-L> predicate writing
You need to change the line 'ismember :letter butfirst :word' to

'output ismember :letter butfirst :word'

Remember 'ismember' returns a value so you need to do something with
that value when you call ismember.  

If from the commander I did: 'ismember "u "u'  you would expect  the
error 'You don't say what to do with true' because I haven't done
anything with the return value from 'ismember'. It's the same from
within 'ismember'.  

Anytime a reporter is called something needs to be done with its return
value.

Quote:

> I've been trying to rewrite some of the predicates that are included as
> primitive procedures in MSWLogo. This is what I've written for memberp:

> to ismember :letter :word
>     if :word = " [output "false]
>     if :letter = first :word [output "true]
>     ismember :letter butfirst :word
> end

> when I type:
> print ismember "u "house
> the complaint is "You don't say what to do with true

> when I type:
> print ismember "u "garden
> the complaint is "You don't say what to do with false

> Can anyone tell me why?

> ---------------------------------------------------------------




--
Frank Caggiano

http://www.atlantic.net/~caggiano/
ICQ# 20694472
---------------------------------------------------------------





Sun, 28 Apr 2002 03:00:00 GMT  
 LOGO-L> predicate writing
Looks like, I'm bit late, but here is my duplicate explaination.
Some of you might be interested in the small note below.

Interesting symptom you created from a bug.

You are not passing the result back up to the top level call.
So only the call that determines true or false is outputing
up to the next level. But from that point back up it's not
being passed up.

to ismember :letter :word
    if :word = " [output "false]
    if :letter = first :word [output "true]
    output ismember :letter butfirst :word
end

Note that this is an advantage of typed languages. Where you would
declare that this function always outputs something and that all
code paths will output. In others words that code in C/C++ would
generate a compile time error.

P.S. Your bug had me stumped for a bit.

Quote:

> I've been trying to rewrite some of the predicates that are included as
> primitive procedures in MSWLogo. This is what I've written for memberp:

> to ismember :letter :word
>     if :word = " [output "false]
>     if :letter = first :word [output "true]
>     ismember :letter butfirst :word
> end

> when I type:
> print ismember "u "house
> the complaint is "You don't say what to do with true

> when I type:
> print ismember "u "garden
> the complaint is "You don't say what to do with false

> Can anyone tell me why?

> ---------------------------------------------------------------




--
===============================================================
George Mills

http://www.softronix.com
The www page contains some very powerful educational software.
Our single most important investment is our kids.
---------------------------------------------------------------





Sun, 28 Apr 2002 03:00:00 GMT  
 LOGO-L> predicate writing
As many have pointed out Simone needs to add "output" to the recursive call.

This message reminded me of LOGO language design discussions I recall from
the 1970s. Those members of the LOGO project at MIT who programmed in LISP
thought that in "child engineering" LISP to produce LOGO a few mistakes had
been made. Among them were

1. That every procedure doesn't output implicitly. The worst consequence
(beside confusions like Simone's) is that "run" might or might not output
depending upon what procedure it was running. It also makes it more
difficult to write a LOGO interpreter in LOGO.

2. The emphasis on "sentence" rather than "list" and "append". It smacks of
trying to be a little bit intelligent - i.e. dumb.

3. There was something about how numbers and types worked but I'm not that
up-to-date on LOGO anymore and can't remember the issue now.

My question over 20 years later is what is the consensus of the LOGO
community? Do people wish these things had been designed differently? But it
is too late to change? Are there other issues? The syntax?

Best,

-ken kahn (www.toontalk.com)


Quote:
> I've been trying to rewrite some of the predicates that are included as
> primitive procedures in MSWLogo. This is what I've written for memberp:

> to ismember :letter :word
>     if :word = " [output "false]
>     if :letter = first :word [output "true]
>     ismember :letter butfirst :word
> end

> when I type:
> print ismember "u "house
> the complaint is "You don't say what to do with true

> when I type:
> print ismember "u "garden
> the complaint is "You don't say what to do with false

> Can anyone tell me why?



Mon, 29 Apr 2002 03:00:00 GMT  
 LOGO-L> predicate writing

Quote:

>My question over 20 years later is what is the consensus of the LOGO
>community? Do people wish these things had been designed differently? But it
>is too late to change? Are there other issues? The syntax?

I don't know if there's a consensus.  But my own feeling is that there are
important issues, and that the ones you listed aren't my ones.

Quote:
>1. That every procedure doesn't output implicitly. The worst consequence
>(beside confusions like Simone's) is that "run" might or might not output
>depending upon what procedure it was running. It also makes it more
>difficult to write a LOGO interpreter in LOGO.

It's true that this makes the implementor's life a lot harder, especially
if you want both tail call elimination and correct error messages -- it's
really hard to get "X didn't output to Y" right if there are tail calls
involved.  On the other hand, my Scheme students often get confused by
procedures that combine output with effect, because an "extra" value
is printed, especially if the value tries to be something useful.  For
example:

    > (begin (print 3) (print 4))
    3
    4
    4

"Huh?  What's that extra 4 doing there?"  It's the value that (print 4)
returned, after printing 4.

Quote:
>2. The emphasis on "sentence" rather than "list" and "append". It smacks of
>trying to be a little bit intelligent - i.e. dumb.

Oh, no, SENTENCE is my favorite Logo feature.  It makes so many things so easy.
It would be bad if we didn't *also* have FPUT, but I use SENTENCE much more
often than FPUT or LIST.  (Logo doesn't have APPEND because SENTENCE is a more
general version of APPEND; that is, if given legal APPEND arguments, SENTENCE
will append them.)

Quote:
>3. There was something about how numbers and types worked but I'm not that
>up-to-date on LOGO anymore and can't remember the issue now.

Do you mean that you don't have to declare types of variables?  That's true
in all versions of Lisp.

Here's my list of design issues:

1.  No first class procedures -- no LAMBDA.  This is a clear weakness of Logo.
We can usually work around it because in a dynamically scoped language you
can use the text of a procedure as equivalent to the procedure itself, but
the notation gets messy.

2.  Dynamic vs. lexical scope.  I still think Logo made the right choice
here, for its purposes, but we still have arguments about it.

3.  Separate procedure namespace.  This is related to #1, but a little
different.  Basically, we pay a heavy syntactic price for being able to
use LIST and WORD as formal parameters, namely all those colons.  I'm not
sure what's the right thing.

4.  Tokenization.  I hate having to say "2 + 3" instead of "2+3" in current
LCSI products.  It's really annoying.  But the available alternatives aren't
perfect either.  Berkeley Logo really tries hard to "do the right thing"
about this, but the rules are awfully complicated if you really try to
understand them.

5.  Special forms.  We were just discussing this -- someone wanted to
duplicate in MSWLogo the behavior of PC Logo's ERASE, EDIT, etc., and you
can't, because we don't provide special forms.  There are arguments on
both sides of this one; having special forms means that absolute beginners
don't get caught on missing quotation marks, but also that you can't
easily extend the power of the language in workspace management by using
lists of procedure names as a kind of package facility, as in EDIT :MYPROCS.



Mon, 29 Apr 2002 03:00:00 GMT  
 LOGO-L> predicate writing

----------

Quote:


>>My question over 20 years later is what is the consensus of the LOGO
>>community? Do people wish these things had been designed differently? But it
>>is too late to change? Are there other issues? The syntax?

> I don't know if there's a consensus.  But my own feeling is that there are
> important issues, and that the ones you listed aren't my ones.

I found this list rather interesting. I agree with everything, but the
tokenization issue was the one that clicked the most; I also wish <= and >=
were included in Logo.

The two issues that have plagued us the most in HyperLogo (the scripting
language in HyperStudio), though are:

1. The syntax for creating words is pretty clumsy for normal text usage.
Something like

   Print "Now\ is\ the\ time\ for\ all\ good\ strings\ to\ print.

just doesn't roll right off of the fingers, if you know what I mean. :)
After numerous complaints, we were forced to extend Logo slightly, allowing
single quotes to form a more traditional string:

   Print 'Now is the time for all good strings to print.'

This causes it's own problems, but the change has been wildly popular.

2. Another problem is the one-line nature of commands.  The line

   While not EmptyP :stuff [Process First :stuff  Make "stuff ButFirst
:stuff]

is pretty simple Logo, yet even this is tough for many people to digest.
Many Logo statements are far longer.  People have taken to typing this as

   While not EmptyP :stuff [
      Process First :stuff
      Make "stuff ButFirst :stuff
      ]

and putting in all sorts of statements about how you really have to put it
all on one line.  We're seriously considering a change in an upcoming
version, possibly an optional one, that follows the old LISP rules and
allows you to type a script this way.  The backwards compatibility issue
with statements like

   While not EmptyP :stuff [Process First :stuff  Make "stuff ButFirst
:stuff

would be handled by "fixing" these scripts automatically as they are
imported into the new version of HyperLogo.

Both of these changes are decidedly un-Logo-like, but they are also both
very popular ideas with HyperLogo scripters--even those who have a
traditional Logo background.  I'd love to hear what people around here think
of the ideas.

Mike Westerfield



Tue, 30 Apr 2002 03:00:00 GMT  
 
 [ 8 post ] 

 Relevant Pages 

1. LOGO-L> Re: LOGO language design - Was: predicate writing

2. LOGO-L> Re: LOGO language design - Was: predicate writing

3. LOGO-L> Apple logo/MSW Logo

4. LOGO-L> Reseach Machines Logo (RM LOGO)

5. How to write predicate for ancestor

6. How to write predicate for ancestor

7. Producing a newline character with the write predicate

8. WTD: 'ls -lR '->HTML code

9. Predicates that create new predicates.

10. >'term' predicate

11. LOGO-L> Welcome to logo-l

12. LOGO-L> Re: Dynamic scope in Logo

 

 
Powered by phpBB® Forum Software