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
> reasonable one) that brings about a behavior, which can be
described - with
> precision - as a context table hierarchy, you have lowered your
attack from
> "I can prove that there is no context hierarchy" to "no
hierarchy needed"?
>
> Perhaps having thought through a process through which REBOL's
hierarchical
> context behavior may be implemented, your opposition to this
concept has
> become weaker, from proving "there's no hierarchy" to avoiding
the
> hierarchy use of the word hierarchy, "no hierarchy needed"?
>
> Your speculation regarding the binding of words during the
function's
> construction is only reasonable, because we know already, that
the
> construction will eventually have to lead to a behavior that is
consistent
> with the observable hierarchic behavior that REBOL displays,
when it
> resolves words in embedded functions.
>
> >
> > r> is based on the assumption that "embedded" objects are
created
> > r> in the context of their "parent" objects and inherit the
> > r> parent object's context. This is not the case - as your
> >
> >Using your reasoning above, I could prove exactly the opposite.
> >Look:
>
> Here I stand corrected by Carl's email. Apparently, the behavior
you
> demonstrate here is a bug, and not REBOL's intended behavior.
Accordingly,
> I should say, that context table inheritance is also effective
for objects,
> but it is not implemented correctly.
>
> >
> >>> a: 1 b: 1 c: 1
> >== 1
> >>> obj1: make object! [
> >[ a: 2
> >[ obj2: make object! [
> >[ b: 2
> >[ obj3: make object! [
> >[ c: 2
> >[ print [a b c]
> >[ ]
> >[ ]
> >[ ]
> >2 2 2
> >
> >So, how did this happen? Context hierarchy for objects? I think
> >not. :-)
>
> Why would this have anything to do with context hierarchies for
objects?
> The resulting object is:
>
> >> probe obj1
> make object! [
> a: 2
> obj2:
> make object! [
> b: 2
> obj3:
> make object! [
> c: 2
> ]
> ]
> ]
>
> Note that print [a b c] does not occur in the object.
>
> >
> > r> In summary, functions are evaluated in a context hierarchy,
> > r> objects are not. Recall that I was discussing the behavior
of
> >
> >I'm sorry, but this is wrong, as you can see above.
>
> How does your example above prove anything with respect to
context table
> hierarchies and objects? The expression print [a b c] is
evaluated at the
> time the objects are being constructed and does not survive the
> construction process. Therefore the construction process of
objects
> determines the context in which print [a b c] is evaluated, and
not the
> context of the resulting objects.
>
> >There's
> >absolutely no difference between a function's context and an
> >object's context.
>
>
> Actually there is! Observe:
>
> >> obj1: make object! [
> [ a: 1
> [ obj2: make object! [
> [ b: a + 1
> [ f: func [x] [ print a + x ]
> [ ]
> [ ]
>
> >> obj1/obj2/b
> == 2
> >> obj1/obj2/f 1
> 2
> >> obj1/a: 100
> == 100
> >> obj1/obj2/b
> == 2
> >> obj1/obj2/f 1
> 101
>
> >
> > r> Perhaps my mental model of context tables and the context
> > r> table hierarchy, multiple context tables that are effective
> > r> during recursive function calls, and the stack in which the
> > r> context tables that are currently defined for a function
are
> > r> stored, while it is recursively being evaluated, is a good
> > r> model to understand recursive function calls?
> >
> >It is accurate enough,
>
> Thank you!
>
> >except for the hierarchy.
>
> This objection should by now be layed to rest! It's a bug.
>
> >The only point
> >against a stack of contexts instead of a stack of values is
that
> >that would require a new binding of the function body for each
> >recursion,
> >which I think it's unlikely.
>
> You think it's "unlikely", because you are speculating about how
things are
> IMPLEMENTED in the REBOL interpreter.
>
> This is not my issue. I'm not trying to outguess the REBOL
interpreter
> architecture. My only concern is in finding a useful
representation for how
> the language works. And with respect to that, I think that it
does not make
> a difference if the interpreter indeed saves and stores context
tables and
> does/or does not bind its body at each recursion.
>
> Pushing and popping context tables could be as cheap and pushing
and
> popping a context pointer that is declared as:
>
> struct CONTEXT_TABLE {
> char * words [];
> void * values [];
> } * context;
>
>
> >Of course, if you think in
> >terms of dinamic binding this makes no sense, so we should find
an
> >an agreement on that first. :)
>
> Since you raise this as an issue, go ahead ;-).
>
>
> >
> > r>> Ladislav suggested that only tha values are remembered,
while
> > r>> the context table is reused. So the function has still
only
> > r>> one context table in any time, but keeps a stack of
values.
> >
> > r> Gabriele, it's obvious that more things are being
remembered
> > r> than just values!
> >
> > r> 1. The association of words with values is being
remembered!
> > r> 2. The fact that the association of these words with these
> > r> values is effective for this particular function is being
> > r> remembered.
> >
> >Remembering the values and their order is enough; anyway, what
I'm
> >saying is that the same context table is reused, but its
contents
> >are saved and then restored. Again, this would make no sense if
> >REBOL did the word lookup at runtime, but it doesn't --- it
does
> >the lookup at bind time.
>
> "it does the lookup at bind time." I'm not sure what you mean by
that.
>
> >
> >Hmm... let's rewind time a bit, and let's run REBOL 2.0:
> >
> >REBOL 2.0.4.1.1
> >Copyright (C) 1998-1999 REBOL Technologies
> >REBOL is a Trademark of REBOL Technologies
> >All rights reserved.
> >
> >loading...
> >Finger protocol loaded
> >Daytime protocol loaded
> >SMTP protocol loaded
> >POP protocol loaded
> >HTTP protocol loaded
> >FTP protocol loaded
> >Script: "REBOL Extended Definitions" (22-May-1999/0:10:40)
> >Script: "User Preferences" (15-May-1999/12:58:54)
> >>> obj: make object! [x: 1]
> >>> word: in obj 'x
> >== x
> >>> get word
> >== 1
> >>> probe obj
> >
> >make object! [
> > x: 1
> >]
> >>> first obj
> >== [self x]
> >>> change next first obj 'a
> >== []
> >>> probe obj
> >
> >make object! [
> > a: 1
> >]
> >>> get word
> >== 1
> >>> word
> >== x
> >
> >So, how is that?
>
> The context was extended. That explains how x remains bound to
1.
>
> >
> > r>> Only the value column is stored in a stack and
reinitialized,
> > r>> as happens when the function is called the first time.
> >
> > r> Ths is an implementation issue and does not touch on the
> >
> >I agree here. But we're speculating about the implementation,
> >aren't we? :-)
>
> No. I'm providing a fragment for a conceptual understanding of
REBOL.
>
> >
> >(P.S.: if you reply to this message, but don't get a reply from
> >me, it's probably because I didn't get you message. I got only
6
> >messages from the list today. I still ahve to figure out why
and
> >where I'm losing messages; in the meantime, if you want you can
> >resend your replys to me directly if you don't see answers from
me
> >in the list.)
>
> I'm cc'ing you the message, just in case ... :-).
>
>
>
> ;- Elan [ : - ) ]
> author of REBOL: THE OFFICIAL GUIDE
> REBOL Press: The Official Source for REBOL Books
> http://www.REBOLpress.com
> visit me at http://www.TechScribe.com
>
>
>
