[plt-scheme] Question on Teaching Scheme with DrScheme

On Nov  6, Michael Vanier wrote:
> 
> Why are you against access to dictionaries?  You don't like
> reflection?

[I like reflection enough to have the last 1/5 of my life dedicated to
it...]


> It's an incredibly powerful feature and something I wish scheme had.
> Scheme is supposed to be a dynamic language, right?


On Nov  6, Jerzy Karczmarczuk wrote:
> My positive feelings towards Lisp were triggered by the fact that I
> could analyse the context of my bugs, that I could see a
> conveniently formatted traceback with the inspection of all the
> variables, etc.  Actually, I still believe that if somebody cannot
> debug a program in Smalltalk (or in Python), he *really doesn't
> want* to find his faults, perhaps subconsciously. Scheme nowadays is
> more efficient than Ye Old Lisp of YonderDays, but its
> auto-diagnosis facilities are less convenient.

So I'll try to reply quickly to the Python thing, since it does gets
pretty off-topic (which is why I'm ignoring the rest...).  I think
that the way you get reflection with a Lisp debugger -- in the
implementations that I worked with (which is mainly ACL) works in a
fine way since it is limited to a debugging tool only.  Python seemed
to want to have that for real code too, but started doing some stuff
which I could not classify under any label other than `fishy'.  So
this thing works:

      >>> def foo():
      ...   x = 3
      ...   return locals()
      ...
      >>> foo()
      {'x': 3}

but the dictionary you get is just some loose estimation of local
variables (and even that may change in the future according to the
docs).  Here's one place it shows:

      >>> x=123
      >>> def foo():
      ...   locals()['x'] = 1234
      ...   return (locals()['x'], x)
      ...
      >>> foo()
      (1234, 123)

so when function way compiled somehow, fixing x to reference the
global.  But more than that, it looks like even with local values, the
dictionary is read-only:

      >>> def foo():
      ...   x=1
      ...   locals()['x'] = 1234
      ...   return (locals()['x'], x)
      ...
      >>> foo()
      (1, 1)

Of course that doesn't really matter when you use locals() at the
top-level where it is the same as globals() so it can change things:

      >>> locals()['x'] = 123
      >>> x
      123

So what there is now is basically a read-only way to inspect locals,
read-write for globals (includes locals at the toplevel), and all that
"may change in the future" so you shouldn't really use it.  Of course
coming from a language that had a "for langauge lawyers" comment next
to the reference pointer, it should not matter.

It is a language where you can "from __future__ import foo", so I'm
not really that surprised.  A language where I couldn't see any
substantial differences between modules, objects, and dictionaries
(and all seemed like they have a half-a-page implementations).  A
language that has iterators which are, IMO, harder to explain than
continuations.  A language with a tutorial that teaches how to use
`static variables' which would translate to Scheme like this:

      (define (foo)
        (let ((x '(0)))
          (set-car! x (+ (car x) 1))
          (car x)))

On top of that there is a distinct smell of all those macro-languages
that grew out to be sort-of-real-languages (things like LotusScript).
It looks like this is the reason for the many `special' names, and
things like that __future__.

That's some of what I didn't like about it.  Again, there are some
other good points to it, I would definitely choose this over Perl as
an interface to people who have paren-phobia.

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                  http://www.barzilay.org/                 Maze is Life!