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

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

From: giesse:writeme at: 26-Jul-2000 19:23

Hello [rebol--techscribe--com]! On 26-Lug-00, you wrote: r> I've set up a mailing list on my Web server for the book (for r> bug fixes and clarifications and ongoing discussions). Good. I think I'll subscribe eventually. :-) Anyway, I'm quite sure it'll be very difficult to find bugs in your book. :-) r> After reading your email carefully, my impression is that our r> main discrepancy has to do with perspective. I view REBOL as a r> programming language, and I think about REBOL in terms of r> concepts, principles that lend themselves to describe how r> REBOL acts as a language. r> In contrast, you apparently think about REBOL as an r> interpreter implementation. You tend to speculate about how r> the REBOL interpreter is likely to implement some language r> feature. This is likely to be right. OTOH, the presence or not of a hierarchy of contexts might make some differences if you're using BIND in your script; also, the fact that the binding is static makes it possible to mix words from different contexts in the same block and run that block "outside" of those contexts. This is rarely done currently only because of the (in)famous GC bug. r> Carl commented on a similar example you provided while binding r> a block to an embedded object, and declared the bind behavior r> you demonstrated to be a bug. He didn't clarify, and I will r> rely on his response Yup, and this really confuses me. If you think about it, the current behaviour makes sense, and the model proposed by me, Ladislav and Brian greatly simplifys the runtime environment of the interpreter as opposed to a dynamic lookup and a hierarchy of contexts. [...] r> Hierarchic context table inheritance r> is REBOL's intended behavior. But well, it never worked this way since 2.0. It really seems very strange to me that Carl didn't notice before; I really hope he'll clarify on this. r>>>> f-arg: "Global f-arg!" r>> == "Global f-arg!" r>>>> print bind [g-arg f-arg global-word] g's-context-word r>> This is g's argument. Global f-arg! This is the global word. r>> r>> So, how does it work when calling F? When F is created, a new r>> context table is created. r> Thank you. I went to pains to demonstrate that. I never meant to negate this. I'm sorry if I seemed to. You know, I'd still need some English lessons. :-) r>> Then the BIND function is called to bind r> Metaphorically speaking? I have never seen the bind function r> called during the construction of a function. If you source r> func and function, you will find that neither of these r> mezzanine functions call bind. They both use make function! r> ... and I have no access to the code that is executed when r> make function! is called. I mean that MAKE FUNCTION! internally calls the same C routine called by the native BIND function. r> I think this is a conceptual problem. There is no g-arg r> defined in the global context. Accordingly "g-arg" was never r> bound to the global context. Therefore "g-arg" cannot "still" r> be bound to the global context. This is wrong. Look:
>> f: func [f-arg] [
[ g: func [g-arg] [ [ print [g-arg f-arg global-word] [ ] [ g "This is g's argument." [ ]
>> print mold first system/words
[end! ... f f-arg g g-arg global-word] ; snipped for brevity There's a global g-arg, and its value is:
>> type? get/any 'g-arg
== unset! r>> When F is executed, the function G is created, and thus the r>> block above gets bound to G's context. Again, only the word r>> "g-arg" is affected, while "print" and "global-word" are left r>> bound to the global context and "f-arg" to F's context. r> Thank you. Note what you are saying here. You are looking at r> this from a different perspective, an implementation r> perspective, - nevertheless - you are formulating a mechanism r> that exactly results in context inheritance. Indeed, what I said before is that "context inheritance" is just a side effect in the current implementation, not the result of a memory structure that can be identified as a "Context Hierarchy". You're absolutely right that mine is an implementation perspective, but there's a huge difference between a model based on dynamic word lookups and a model based on static word bindings. r> Your r> implementation view (though speculative, but reasonable) r> supports my conceptual representation, don't you think? Yes. But you get different results when you're using BIND manually. r> Now "No hierarchy NEEDED" has become the "same" as proving r> "there's no hierarchy here:"? After describing a speculative r> process (albeit a reasonable one) that brings about a r> behavior, which can be described - with precision - as a r> context table hierarchy, you have lowered your attack from "I r> can prove that there is no context hierarchy" to "no hierarchy r> needed"? Oh, don't be so picky. :-) I cannot know what REBOL actually does, I'm just proposing the most reasonable model. And that model does not need any context hierarchy to fully explain REBOL --- the hierarchy you see is a side effect. It's just that I don't think they're using a model that is so much complicated to look like it didn't use a hierarchy while it's using it. r> Perhaps having thought through a process through which REBOL's r> hierarchical context behavior may be implemented, your r> opposition to this concept has become weaker, from proving r> "there's no hierarchy" to avoiding the hierarchy use of the r> word hierarchy, "no hierarchy needed"? I think the current implementation has no hierarchy. (Probably this is a bug as Carl said, I don't know.) That is, the C structure that represents a context table has no pointer back to a parent context table. Instead, what you SEE as a context hierarchy is the SIDE EFFECT of binding the same block multiple times. I hope I've been clearer this time. :) [...] r> Note that print [a b c] does not occur in the object. But putting that in the object would have produced the same results. As in:
>> a: 1 b: 1 c: 1
== 1
>> obj1: make object! [
[ a: 2 [ obj2: make object! [ [ b: 2 [ obj3: make object! [ [ c: 2 [ code: [print [a b c]] [ ] [ ] [ ]
>> do obj1/obj2/obj3/code
2 2 2 r> How does your example above prove anything with respect to r> context table hierarchies and objects? The expression print [a r> b c] is evaluated at the time the objects are being r> constructed and does not survive the construction process. r> Therefore the construction process of objects determines the r> context in which print [a b c] is evaluated, and not the r> context of the resulting objects. I hope the example above is clearer. r>> There's r>> absolutely no difference between a function's context and an r>> object's context. r> Actually there is! Observe: r>>> obj1: make object! [ r> [ a: 1 r> [ obj2: make object! [ r> [ b: a + 1 r> [ f: func [x] [ print a + x ] r> [ ] r> [ ] r>>> obj1/obj2/b r> == 2 r>>> obj1/obj2/f 1 r> 2 r>>> obj1/a: 100 r> == 100 r>>> obj1/obj2/b r> == 2 r>>> obj1/obj2/f 1 r> 101 I'm sorry, I can't see any difference in the contexts here. It's just that B is an integer! while F is a function!. r>> It is accurate enough, r> Thank you! r>> except for the hierarchy. r> This objection should by now be layed to rest! It's a bug. Hmm. r> This is not my issue. I'm not trying to outguess the REBOL r> interpreter architecture. My only concern is in finding a r> useful representation for how the language works. And with r> respect to that, I think that it does not make a difference if r> the interpreter indeed saves and stores context tables and r> does/or does not bind its body at each recursion. That's ok for me. r>> Of course, if you think in terms of dinamic binding this r>> makes no sense, so we should find an an agreement on that r>> first. :) r> Since you raise this as an issue, go ahead ;-). Oh, I think binding is static. Do you agree? ;^) r> "it does the lookup at bind time." I'm not sure what you mean r> by that. The BIND function does word lookup in context. The DO function probably doesn't even know about contexts --- it just evaluates the values the words were boud to. [REBOL 2.0] r>>>> obj: make object! [x: 1] r>>>> word: in obj 'x r>> == x r>>>> get word r>> == 1 r>>>> probe obj r>> r>> make object! [ r>> x: 1 r>> ] r>>>> first obj r>> == [self x] r>>>> change next first obj 'a r>> == [] r>>>> probe obj r>> r>> make object! [ r>> a: 1 r>> ] r>>>> get word r>> == 1 r>>>> word r>> == x r>> r>> So, how is that? r> The context was extended. That explains how x remains bound to r> 1. I think I don't understand completely what you mean here. You mean that the context was extended to contain BOTH the words 'a and 'x? If this was the case, if we bind the word 'x to the object's context, do you expect to get 1 again? r> I'm cc'ing you the message, just in case ... :-). Thanks. But now things get worse for me: I got the message from the ml but didn't get the CC from you. So this means the problem's on my side, and I could have lost other private messages too (I considered this unlikely because I don't see the same problem with other mailing lists, but perhaps I've lost messages from them too without noticing...). I've got to track this down. Regards, Gabriele. -- Gabriele Santilli <[giesse--writeme--com]> - Amigan - REBOL programmer Amiga Group Italia sez. L'Aquila -- http://www.amyresource.it/AGI/