LOGO-L> Re: Logo inside Scheme 
Author Message
 LOGO-L> Re: Logo inside Scheme

Quote:
Brian Harvey writes:

> >I'd agree it is fairly important.  I tried to port the Pascal
> >interpreter from the CSLS examples in UCBLogo, and have ended up
> >getting quite discouraged with the scoping.  OTOH, a big reason why I
> >got discouraged was because I couldn't understand what was going
> >because of that scoping -- dynamic scoping tends to be rather opaque.

> Read the book!  :-)  I think you'd find it less opaque if you could
> learn to enjoy dynamic scope instead of fighting it.  In the case of
> the Pascal compiler, the key point is that in a recursive descent
> compiler, the dynamic scope at compile time matches the lexical scope
> at run time, because a lexical block in the Pascal source program is
> compiled by a Logo procedure call.  So the dynamically scoped variable
> IDLIST always has the right Pascal variables for the current block.
> On entry to a block you see
>    localmake "idlist :idlist
> which saves the outer environment and creates a new inner one that
> initially contains the same variables but will have new ones added.
> On exit from the Pascal block, the Logo procedure returns, and the
> old IDLIST is restored automatically.

Ahh... that makes more sense then.  I don't know how I feel about it,
though.  It's a namespace posing as a stack.  Or a stack posing as a
namespace.  I can't decide which.  You're right -- maybe I just have
to learn to enjoy dynamic scoping.  It feels very Wrong to me now.
But it's the same sort of Wrong I felt when I first saw the aggressive
use of method dispatch on object type in Smalltalk (where Smalltalk
used a message when I would have used an if statement).  I learned to
love Smalltalk for this: merging the internals of the language with
the implementation of a program.  Maybe I can appreciate the same
thing with dynamic scoping.  (but it still feels wrong)

- Show quoted text -

Quote:
> >to while [block :test] [block :body]
> >  if run :test [run :body
> >                while :test :body]
> >end

> This doesn't have the full generality of being able to construct
> a piece of text and run it.  For example:

>     to apply :function :argument
>     output run ifelse wordp :function [list :function "?] [:function]
>     end

>     to ?
>     output :argument
>     end

> This allows both APPLY [FIRST ?] "HELLO and APPLY "FIRST "HELLO

to apply [block :function] :argument
  output (run ifelse symbol? :function [eval :function] [:function]
              :argument)
end

Note: because it's mirroring Scheme, I haven't figured out what to do
about the distinction between symbols and strings, hence the
"symbol?" instead of "wordp".  Also, I have a somewhat different form
of "run" that takes optional extra arguments, which will be inputs to
the procedure given to it.

With this you can do both:

  apply [first ?] "hello"
  apply 'first "hello"

Depending on how you set up the translator (this is configurable), you
could also do:

  apply :first "hello"

[an artifact from the single namespace Scheme uses for procedures and
variables -- even if this artifact was removed, I'd still like a
special form ("procedure first"?) that returned the *actual*
procedure, instead of just the name of the procedure.  It's this need
to refer to procedures by name that is at the root of a lot of these
issues]

Still, it's still possible to do other funny things with dynamic
scoping and the highly-interpreted nature of Logo that the
lexically-scoped/Schemified Logo can't (quite) do.

However, with a little restructuring it's still possible to do
whatever you'd want to do.  Of course, to different degrees this is
true of nearly any language (Real Programmers can write fortran in any
language :)

The question should be: which structuring is better in terms of
aesthetics, functionality, and pedagogy?

In terms of aesthetics, I think lexical scoping is clearly the winner.

For functionality, dynamic scoping is probably better for small
programs, lexical scoping for large programs.  However, if the
environment becomes big enough and is fairly transparent it becomes
unclear where the program ends and the environment begins, and unclear
what constitutes a big program vs. a small program.  I think such a
large, transparent environment has a lot of potential for pedagogy.
It would be more feasible with lexical scoping.

If you have optional dynamic scoping you may have the best
of both worlds.  But such optional-anything-you-want feels a bit
crufty to me.  The language ought to enable, but it also ought to
guide.

For pedagogy in general, I'm not sure... which scoping is easier to
understand, or works as expected even when it's used without complete
understanding?  Where does scope fit into the larger picture anyway?

- Show quoted text -

Quote:
> >Is there a way in Object Logo to write lexically-scoped control
> >procedures, or do you have to use dynamic-scoping to do that?

> I suppose you could think of it as lexical scoping.  Object Logo has
> an INSIDE declaration so that you can lexically nest procedures
> without having them physically inside each other:

> TO FOO.HELPER
> INSIDE "FOO
> ...
> END

> so for control procedures you say

> TO WHILE :CONDITION :ACTION
> INSIDEANY
> ...
> END

> I'm not sure whether this actually recompiled WHILE separately for
> every invocation or not, but clearly you're meant to think of it as
> a funny kind of lexical scope.

That's a macro, really.  It's a nice syntax for a macro, but it's
definately a macro.  Traditional macros (.macro) are much more general
but they also force you to think in terms of meta-programming when
it's not necessary, i.e., you have to think about the macro in terms
of translation (from the given inputs to what should be executed).
The simpler intermediate form is usually enough.

  to while :condition :action
    insideany
    if run :condition [run :action
                       while :condition :action]
  end

is complete equivalent to:

  .macro while :condition :action
    `[if run ,:condition [run ,:action
                          while ,:condition ,:action]]
  end

which might not be quite as nice as:

  .macro while :condition :action
    (list "if :condition (sentence :action "while :condition :action))
  end

But the form that uses "to" is so much easier to read than the last
form that it's clearly a win (IMHO).  Now, there might be some details
about the "to" form that make it a more than just a macro, but I think
the core concept of a macro is still there -- it's a form of inlining
that is done before lexical analysis.

ObjectLogo looks quite interesting: are there any good resources on
it?  A publicly available manual or demo?  I found a web page at
digitool.com, but it was pretty old and lacking any links (even to an
order form).  Has Digitool given up on it?

<------------------------------------------------------------------->

< drawer #419 Earlham College |   http://www.*-*-*.com/ ~bickiia >
< Richmond, IN 47374          |  (765) 973-2824                     >
<------------------------------------------------------------------->
---------------------------------------------------------------





Sun, 20 May 2001 03:00:00 GMT  
 LOGO-L> Re: Logo inside Scheme

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

Quote:
> On entry to a block you see
>    localmake "idlist :idlist
> which saves the outer environment and creates a new inner one that
> initially contains the same variables but will have new ones added.
> On exit from the Pascal block, the Logo procedure returns, and the
> old IDLIST is restored automatically.

Ahh... that makes more sense then.  I don't know how I feel about it,
though.  It's a namespace posing as a stack.  Or a stack posing as a
namespace.  I can't decide which.  You're right -- maybe I just have
to learn to enjoy dynamic scoping.  It feels very Wrong to me now.
----------------------------------------

Eric Naggum posted something on dynamic scoping to comp.lang.lisp.  He
called it a structured approach to global variables---as `if',
`while', `for' and so on give a structured approach to gotos.

Here is part of what he says:

  now, what do we know about global variables?  first, they are readable
  everywhere, so let's find another way to make them readable everywhere:
  make them implicit arguments to all functions!  second, they are writable
  everywhere, too, so make let's let those implicit arguments be pointers
  to the actual values the global variables hold.  can we agree that this
  is equivalent to global variables and that not passing them all along
  with every function call is just an optimization technique?  if yes, I
  have a surprise for you: what if a function could do more than read the
  value of the implicit argument and store a new value into it, such as to
  _create a new object_ to hold a global variable and to which it would
  then pass a pointer downwards to its own callees in place of the implicit
  argument it received?  what would the benefits of this be?  the foremost
  is that the old binding of the global variable would be re-established
  upon exit from the scope that created a new object to point to.  but we
  could also copy the old value into a new place and pass that downwards to
  protect ourselves from evil code that overwrites the value of a global
  variable, producing the well-known hellish experience to track down the
  resulting bugs.  thus, we have curtailed the evil of global variables the
  same way new language constructs curtailed the infamous global labels in
  BASIC.

  so when is global variables an evil thing, then?  when you cannot change
  the bindings and re-establish the old ones at will, as you then fall prey
  to bad code that either just sets the value or forgets to reset the old
  value after temporary changes, but not because these are global variables
  -- it's because it is bad code with hard-to-find bugs.

  anyhow, the morale of this story is quite simple:

        dynamic binding is to global variables as WHILE is to GOTO.

He argues that dynamic variables should be optional however, since
some of the possible effects can be confusing.

--

King Christ, this world is all aleak, / And life preservers there are none,
And waves that only He may walk / Who dared to call Himself a man.
-- e. e. cummings, from Jehovah Buried, Satan Dead



Sun, 20 May 2001 03:00:00 GMT  
 LOGO-L> Re: Logo inside Scheme

Quote:

>  Maybe I can appreciate the same
>thing with dynamic scoping.  (but it still feels wrong)

Well, most people agree with you...  I find uses for both ways.

Quote:
>to apply [block :function] :argument
>  output (run ifelse symbol? :function [eval :function] [:function]
>              :argument)
>end

How strange -- you have a RUN and an EVAL and they don't do the same thing!

I think this is really dramatically changing the way one thinks about
Logo programming.  Mostly this is convincing me that it's good that
Logo's semantics (not just its syntax) are different from Scheme!

Quote:
>For functionality, dynamic scoping is probably better for small
>programs, lexical scoping for large programs.  However, if the
>environment becomes big enough and is fairly transparent it becomes
>unclear where the program ends and the environment begins, and unclear
>what constitutes a big program vs. a small program.  I think such a
>large, transparent environment has a lot of potential for pedagogy.
>It would be more feasible with lexical scoping.

I'm not convinced about that last point.  I find debugging harder to
understand in lexically scoped languages, and it doesn't help much for
there to be a big GUIfied IDE.

Quote:
>ObjectLogo looks quite interesting: are there any good resources on
>it?  A publicly available manual or demo?  I found a web page at
>digitool.com, but it was pretty old and lacking any links (even to an
>order form).  Has Digitool given up on it?

I think it's more that Digitool has given up, period.  But I'm not
sure; I haven't been in touch in a long time.


Wed, 23 May 2001 03:00:00 GMT  
 
 [ 3 post ] 

 Relevant Pages 

1. LOGO-L> Re: Logo inside Scheme

2. LOGO-L> Re: LOGO-L> Re: Logo inside Scheme

3. LOGO-L> Re: logo and scheme

4. LOGO-L> Logo-Scheme

5. LOGO-L> Apple logo/MSW Logo

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

7. Logo inside Scheme

8. LOGO-L> Welcome to logo-l

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

10. LOGO-L> INFO re SIG-LOGO

11. LOGO-L> Logo speed

12. LOGO-L> Logo foundation site

 

 
Powered by phpBB® Forum Software