Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

[REBOL] Bug in 'use? Re:(12)

From: lmecir:geocities at: 26-Jul-2000 19:38

Hi Elan, you wrote:
> (...) > I conclude from Carl's comment that > bind's intended behavior is to bind the block such that all
words that
> occur in the block behave as they would, if the block had been
defined in
> the context it is being bound to. > > I.e. if print [g-arg f-arg global-word] evaluated in the g
function's
> context were to generate > > This is g's argument. This is f's argument. This is the global
word.
> then > > print bind [g-arg f-arg global-word] g's-context-word > > should generate the same result. If it doesn't, then it is - in
Carl's
> words - a bug. Hierarchic context table inheritance is REBOL's
intended
> behavior. >
I think, that here is the main difference between your "Mental Model Approach" and our approach: We, not having the official description, are writing the description of Rebol behaviour, while you are trying to describe the "Intended Behaviour", that surely differs. Problem with your approach is, that you neither know the Rebol "Intended Behaviour" not being its creator, nor are able to correctly describe the actual behaviour, because you don't even try to do it. Regards Ladislav
> >>> f-arg: "Global f-arg!" > >== "Global f-arg!" > >>> print bind [g-arg f-arg global-word] g's-context-word > >This is g's argument. Global f-arg! This is the global word. > > > >So, how does it work when calling F? When F is created, a new > >context table is created. > > Thank you. I went to pains to demonstrate that. > > >Then the BIND function is called to bind > > Metaphorically speaking? I have never seen the bind function
called during
> the construction of a function. If you source func and function,
you will
> find that neither of these mezzanine functions call bind. They
both use
> make function! ... and I have no access to the code that is
executed when
> make function! is called. > > >the body block to that context table (this means binding each
word
> >in the block and the blocks (any-block!s actually) it contains, > >but only if present in the context table). > >So when F is created > >the block: > > > > [ > > print [g-arg f-arg global-word] > > ] > > > >gets bound to F's context; more precisely, > >the word "f-arg" gets > >bound to F's context, while "print", "g-arg" and "global-word" > >aren't changed (so they're still bound to the global context). > > I think this is a conceptual problem. There is no g-arg defined
in the
> global context. Accordingly "g-arg" was never bound to the
global context.
> Therefore "g-arg" cannot "still" be bound to the global context. > > > > >When F is executed, the function G is created, and thus the
block
> >above gets bound to G's context. Again, only the word "g-arg"
is
> >affected, while "print" and "global-word" are left bound to the > >global context and "f-arg" to F's context. > > Thank you. Note what you are saying here. You are looking at
this from a
> different perspective, an implementation perspective, -
nevertheless - you
> are formulating a mechanism that exactly results in context
inheritance.
> You may dislike the term "context (table) inheritance", but I
think it
> expresses the fact quite well that words used - but not
defined - in an
> embedded function, are interpreted in the context of their
parent function
> - provided they are defined in that function. Or in their
immediate
> parent's parent function ... until the global context is
reached. Your
> implementation view (though speculative, but reasonable)
supports my
> conceptual representation, don't you think? > > > > >The result is what you expect, with "f-arg" bound to F's
context,
> >"g-arg" bound to G's context and "global-word" bound to the
global
> >context, but this is only a (wanted) side effect of REBOL
static
> >binding. > > > > r> Example 2 for Context Hierarchy: > > > >[...] > > > >The same goes here. No hierarchy needed. > > No hierarchy "needed"? Did you not begin by claiming in your
previous email
> >Anyway, I can prove that there is no context hierarchy: > > then continue by saying in this email > > >So, let's prove there's no hierarchy here: > > Now "No hierarchy NEEDED" has become the "same" as proving
there's no
> hierarchy here:
? After describing a speculative process (albeit a