Re: Me no understand scoping

[Maciek Godek]

Hello Andy!

>> [Neil]
>>> 1. IMO this could be really beautifully done in GOOPS, by defining
>>> custom metaclasses and slot types.
>>
>> I've been considering that, and I'm still having doubts.
>> The main reason is that there's no documented way
>> of accessing GOOPS objects from C (except from using
>> scm_c_eval_string etc.), or at least I couldn't find any
>> documentation for that.
>
> You can use scm_slot_ref et al. See goops.h.

I took a glimpse. The one thing that stinks to me is an
immanent inefficiency which comes from the fact that
the slots are looked up by their names and therefore
aren't accessed directly. (I wrote a follow-up to Neil's
post in this thread with an efficient solution)

>> Besides (which is the matter of personal taste), I don't
>> like the idea of using generics and trashing the global
>> namespace with them. (I mean, the sole idea of generics
>> is fine, but I wouldn't want to be forced to use them)
> [...]
>> I'm really trying to get close
>> to the classical OOP notation: object.method() -- and
>> it's probably why I explore the potential of using these
>> "poor man's objects"
>
> I wrote about this notational issue a while back on my blog,
> http://wingolog.org/; I'm offline at the moment, so unfortunately I
> don't have a link. Search for "slot-ref". I think with-accessors is an
> elegant solution to this problem.

I've been looking for such thing for a month or so, it's brilliant
(or at least on a good way to be -- I have to examine it in more
detail). BTW I'm placing the link here for the others:
http://wingolog.org/archives/2008/04/22/object-closure-and-the-negative-specification

>> But the point is that I saw that there is a 'make-hash-table' function
>> available in lisp -- and this lead me to the conclusion that it's probably
>> because the scopes/closures/environments implicitly use hash
>> tables to store their bindings (and the same mechanism was given
>> explicitly to the programmer).
>
> This is false. Consider the closure:
>
>  (let ((val 0))
>    (lambda ()
>      (set! val (1+ val))
>      val))
>
> Lexical scoping + closures was one of the fundamental ideas of scheme.
> You can analyze this code /lexically/ to determine that we only need to
> allocate storage for one variable. Wherever you see `val' in the body of
> the lambda, you know /lexically/ that you are referring to a location
> that is one step out in the stack frame, and the 0th location in that
> frame, the frame created by `let'. So there is no need to store the
> name, "val", at all!
[...]
> Do you see now why local-eval can't possibly work in the presence of
> efficient compilation? Scheme does not give you the particular kind of
> dynamism that you want. There is no hash table lurking inside a closure.

Yeah, you've convinced me. I was stupid and irresponsible but now I can
see clearly why local-eval shouldn't be abused.

> On the other hand, modules do have hash tables, and modules are
> evaluation environments; and they have been treated in some literature
> as closures. Perhaps consider using modules as your first-class objects?

Thanks a lot, I think it was the second thing I've been looking for.
I'll read some more on that.

>> And so I never stopped to believe that (define x 5) is more or
>> less equivalent to (hash-set! global-scope 'x 5).
>
> At the top level it is; but s/global-scope/the current module/.
> But internal defines are completely different.

I've heard that in current implementation of guile they are only
different in that they are not storing data in hash-tables but in
assoc lists :) (That's what Ludovic says)

Thanks a lot
M.