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

object funnies

 [1/38] from: gchiu::compkarori::co::nz at: 18-Oct-2001 11:07


I've been puzzling over this one. I have a game object like this: gomoku: make object! [ cellsize: 20 do-preview: does [ uses the value of cellsize ] resize-board: does [ cellsize: new_computed_value ... ] ] When I call the function 'resize-board, it changes the cellsize value correctly - printing it to console to confirm that it has changed, but when I call the 'do-preview function directly after this, it still shows the original value. There are no other functions that change the value of 'cellsize. Ideas? Have I corrupted the interpreter somewhere that might be doing this? -- Graham Chiu

 [2/38] from: arolls:idatam:au at: 18-Oct-2001 13:18


How does do-preview work? Is there a layout in it? Perhaps there is a different value for cellsize in another context. Better show us the code. Anton.

 [3/38] from: al:bri:xtra at: 18-Oct-2001 16:44


Graeme wrote:
> I have a game object like this:
I think your other code might be corrupted somewhere. Possibly a speelling err0r or something like that. :-) Andrew Martin ICQ: 26227169 http://valley.150m.com/

 [4/38] from: gchiu:compkarori at: 18-Oct-2001 18:06


On Thu, 18 Oct 2001 16:44:27 +1300 "Andrew Martin" <[Al--Bri--xtra--co--nz]> wrote:
> Graeme wrote: > > I have a game object like this: > > I think your other code might be corrupted somewhere. > Possibly a speelling > err0r or something like that. >
Except it worked fine befour I turwned it ntwo an oject.
> :-) > > Andrew Martin > ICQ: 26227169 http://valley.150m.com/ > -><- >
-- Graham Chiu

 [5/38] from: al:bri:xtra at: 18-Oct-2001 17:48


Let's see the code! I know from practical experience how blind I am! :-) Andrew Martin ICQ: 26227169 http://valley.150m.com/

 [6/38] from: gchiu:compkarori at: 18-Oct-2001 19:28


On Thu, 18 Oct 2001 13:18:30 +1000 Anton Rolls <[arolls--idatam--com--au]> wrote:
> Perhaps there is a different value for cellsize > in another context. > Better show us the code.
Hi Anton/Andrew I guess this is the most likely answer, but I can't see it. The working program with the resizeable game board is at sites/compkarori/gorim2.r ( http://www.compkarori.co.nz/reb/gorim2.r ) which saves the file http://www.compkarori.co.nz/reb/gomoku4.r to the local drive as %gomoku3.r and executes it In gorim2.r, there is no code left that alters the value of 'cellsize. 'cellsize is defined initially as 20 in gomoku4.r It is only redefined in the function 'resize-board ( in gomoku4.r ) which is executed on receiving a resize event This is just the first part of the function as it is quite long resize-board: func [ size [pair!] /local x ] [ bk/size: size cellsize: to-integer ( size/y - 60 ) / 20 ; print [ "new cellsize: " cellsize ] init-variables ...... ] and this is the first part of 'do-preview do-preview: func [ act pos /local x y tmp tmp2 tmp3 topedge result ] [ cellsize: gridsize/x ;!! have to do this as somehow keeping the old value of cellsize print [ "Cellsize: " cellsize ] ..... ] It works correctly with the assignment I make in the first line of the function, but it bothers me that I have to do it. If you want to see it, just uncomment the two print statements, run gorim2.r, and then when you're logged on to the chat server, click on the "send" option on the menu. That brings up a board. As you move the mouse over the board, it will start printing. Resize, and it will print the new cellsize, but without the reassignment, the cellsize remains the same ... -- Graham Chiu

 [7/38] from: allenk:powerup:au at: 18-Oct-2001 16:35


A script from Jeff may help track it down. Cheers, Allen K REBOL [ Title: "Check-leaks" Purpose: "Check a script for word leaks" Usage: { DO this before you do anything else in your script. After a little while (after things have evaluated), call check-word-leaks which will print out words that have leaked out to the global context and write out a file called %word-leaks.txt } Author: "Jeff Kreis" Email: [jeff--rebol--com] data: 16-Feb-2001 ] check-word-leaks: func [ /local some-leaks ][ some-leaks: copy [] foreach word possible-leaks [ if all [not find global-leaks word value? word] [append some-leaks probe word] ] if not empty? some-leaks [ append global-leaks some-leaks ] write/append %word-leaks.txt mold some-leaks ] get-block-sets: func [ blk [block!] /local flat flat2 sets-on nests sets ][ append flat: copy [] blk flat2: copy [] sets: copy [] sets-on: 0 until [ nests: false forall flat [ if sets-on > 0 [sets-on: sets-on - 1] if flat/1 = 'set [sets-on: 2] if all [lit-word? flat/1 sets-on > 0][ append sets to-word flat/1 ] if set-word? flat/1 [append sets to-word flat/1] if block? flat/1 [ nests: true append flat2 flat/1 if sets-on > 0 [ append sets flat/1] ] ] flat: head flat2 flat2: copy [] not nests ] sets ] wordize: func [blk [block!] /local res][ res: copy [] foreach item blk [if any-word? item [append res to-word item]] res ] global-leaks: copy [] possible-leaks: copy [] x-fnctn-x: :function! function!: make x-fnctn-x [a][ reduce ['x-fnctn-x a] ] make': :make make: make' x-fnctn-x [type spec /local err][ if object! = type [ return make-watch object! spec ] if all [ block? type 2 = length? type type/1 = 'x-fnctn-x ][ ;print ["Making function:" mold second type mold spec] return make-watch/fun second type spec ] if object? type [ return make-watch type spec ] if set-word! <> type [ return make' type spec ] to-set-word spec ] make-watch: make' x-fnctn-x [ type spec /fun /local end res leaks poss locs ][ poss: copy [] append poss get-block-sets spec foreach word poss [ if not value? word [ append possible-leaks word ] ] possible-leaks: unique possible-leaks possible-leaks res: either fun [ make' x-fnctn-x type spec ][ make' type spec ] :res ]

 [8/38] from: gchiu:compkarori at: 19-Oct-2001 0:02


On Thu, 18 Oct 2001 16:35:35 +1000 "Allen Kamp" <[allenk--powerup--com--au]> wrote:
> A script from Jeff may help track it down. > > Cheers, > > Allen K
Thanks Allen, but it hasn't of yet. -- Graham Chiu

 [9/38] from: gchiu:compkarori at: 19-Oct-2001 13:57


Still trying to puzzle this one out .... test: make object! [ test1: 1 fun: does [ test2: 2 test3: 3 test1: test2 + test3 ] ] Reading the core docs, I sort of expected that the instance variables test1, test2 and test3 are encapsulated within the object test. But it seems that test2 and test3 are available in the global context, but test1 is not. -- Graham Chiu

 [10/38] from: allenk:powerup:au at: 19-Oct-2001 11:20


----- Original Message ----- From: "Graham Chiu" <[gchiu--compkarori--co--nz]> To: <[rebol-list--rebol--com]> Sent: Friday, October 19, 2001 10:57 AM Subject: [REBOL] Re: object funnies
> Still trying to puzzle this one out .... > test: make object! [
<<quoted lines omitted: 10>>
> But it seems that test2 and test3 are available in the > global context, but test1 is not.
Yep, that is correct. If you want them local to the object include them in its context. test: make object! [ test1: 1 test2: test3: none fun: does [ test2: 2 test3: 3 test1: test2 + test3 ] ] Cheers, Allen K

 [11/38] from: lmecir:mbox:vol:cz at: 19-Oct-2001 3:26


Hi, you can find the description of MAKE OBJECT! in http://www.sweb.cz/LMecir/contexts.html Essentially, the MAKE searches the SPEC block (but not its subblocks) for set-words. That is why MAKE didn't find test2: and test3: in your example.

 [12/38] from: al:bri:xtra at: 19-Oct-2001 14:29


Graham wrote:
> test: make object! [ > test1: 1
<<quoted lines omitted: 4>>
> ] > ]
Only 'test1 and 'fun are "inside" the object. 'test2 and 'test2 are outside the object. To get what I think you want, you'll need: test: make object! [ test1: 1 test2: test2: none fun: does [ test2: 2 test3: 3 test1: test2 + test2 ] ] I hope that helps! Andrew Martin ICQ: 26227169 http://valley.150m.com/

 [13/38] from: al:bri:xtra at: 19-Oct-2001 15:42


Ladislav wrote:
> Essentially, the MAKE searches the SPEC block (but not its subblocks) for
set-words. That is why MAKE didn't find test2: and test3: in your example. I wonder if it would be a smart idea to make a scanner function that looks inside nested blocks for a object! spec and adds any set-word! to the start of the object's block, so that Graham's:
> test: make object! [ > test1: 1
<<quoted lines omitted: 3>>
> test1: test2 + test3 > ]
is written as: test: make-object [ test1: 1 fun: does [ test2: 2 test3: 3 test1: test2 + test3 ] ] which comes out as: test: make object! [ test1: 1 test2: test3: none fun: does [ test2: 2 test3: 3 test1: test2 + test3 ] ] What do people think? Andrew Martin ICQ: 26227169 http://valley.150m.com/

 [14/38] from: gchiu:compkarori at: 19-Oct-2001 17:21


On Fri, 19 Oct 2001 15:42:15 +1300 "Andrew Martin" <[Al--Bri--xtra--co--nz]> wrote:
> Ladislav wrote: > > Essentially, the MAKE searches the SPEC block (but not
<<quoted lines omitted: 6>>
> set-word! to the start > of the object's block, so that Graham's:
I'm actually left wondering why RT chose to implement it in this way. It's not intuitive, and nor is it discussed in the online core docs. -- Graham Chiu

 [15/38] from: greggirwin:mindspring at: 19-Oct-2001 0:06


Hi Andrew, << I wonder if it would be a smart idea to make a scanner function that looks inside nested blocks for a object! spec and adds any set-word! to the start of the object's block...>> I think it could be very helpful, even if the scanner was just a Lint-like tool. It could scan an object and give you a report of the words defined in the object and those that will be defined in the global context. With Graham's example, you would have to ask them if they intended the words to be defined for the object, or if they wanted them to be local to the function. I can see people coming from other languages and making this scoping error very easily (myself included). --Gregg

 [16/38] from: chrismorency:videotron:ca at: 19-Oct-2001 2:18


Hi Graham, Maybe because although you would like to encapsulate some variables in an object, you still want it to be able to define global words through its methods. Hence what is not declared as local is global. I've looked at your code, have you noticed you call the initialise functions twice, and one as such (if I understand your indenting) : o: make object! [ init-vars: func [][ ... ] do-something: func [][ init-vars reduce [ something ] ] init-vars ] now the last init-vars will be called upon the creation of the object... maybe that's what you're trying to achieve... but maybe it's something you have overlooked... Finally, it's not unusual to take something procedural and making object-oriented. However I personnally don't think it should be as easy as adding make object! [ ... ]. If you want to make your code oop'ed, redesign it all for this. I strongly suggest you to use self to refer to the properties or methods within the object, this help understand the code... But more on the subject of objects pretty soon... Best, Chris

 [17/38] from: joel:neely:fedex at: 19-Oct-2001 7:36


Hi, Andrew, Andrew Martin wrote:
> I wonder if it would be a smart idea to make a scanner function > that looks inside nested blocks for a object! spec and adds any > set-word! to the start of the object's block... >
It sounds like an interesting group experiment, but see below... I'd personally prefer an object checker that simply takes an object and identifies those cases when out-of-context words are set. The proliferation of cases where we have multiple ways to do the same (or worse, slightly different) things makes me just a bit paranoid for a couple of reasons: 1) The more we hide (from newbies or ourselves) the areas in which RDIOT (REBOL Does Its Own Thing), the more we increase the likelihood that its unique behaviors will take even more time to figure out when they do emerge. 2) The more we have proliferations of slight variations (if you'll pardon the alliteration ;-) the more details and exceptions we have to remember to get our code right. I'm not sure that the marginal value added by make function! [][][] vs. function [][][] vs. func [ ][] vs. does [] (just to give one example, I'm sure everyone can immediately think of other cases) is really all that much compared to the value of tidying up some of the needless inconsistencies. Frankly, this all reminds me of a statement I heard years ago: "FORTH is not a programming language; FORTH is a programming language construction kit!" Perhaps there's a reason why radically extensible programming languages have never made it to the mainstream (especially when used in the most radically-extensible style) -- it becomes all too easy for the code for each application to become in effect its own private language. In the long term this poses risks to the safety and stability of maintenance efforts. To be fair, I recall the "shoebox" quotation in which Carl described REBOL as a language for "programming in the small". If we expect to use REBOL only for relatively short, throw-away scripts, then this isn't an issue. If that's NOT how someone wants to use REBOL, then there seem to be a few choices that have to be made: 1) Excercise self-discipline and avoid radical use of extensibility, so that any REBOL programmer (including the original author after at least one nap or long coffee break ;-) can pick up a piece of code and understand it quickly and maintain it safely. 2) Have some widely-used means of creating re-usable units of code (components/modules/packages/...), whether delivered by RT or created by the community, so that semi-standard extensions can be widely (and consistently and conveniently) deployed and used. 3) Have more docs and examples of the cases where RDIOT and how the conceptual model of REBOL differs from more "familiar" languages. (I'm working on some ideas here and hope to provide some results in the near future.) I'm not suggesting that REBOL "should" look more like any particular other language, but simply making a practical observation -- most of the high-skill/high-performance programmers of my acquaintance are quite comfortable with multiple languages and the use of multiple languages as specialized tools within a single task. They tend not to be willing to: 1) devote themselves to a single language for everything, nor to 2) spend lots of time experimenting and trying things out and running into dead ends and solving syntactic or semantic puzzles just to develop proficiency in a new language (at least not unless there's some REALLY big payoff). This brings me full-circle to your suggestion above and my first response. The open-source community thrives on competitive evolution of ideas. People try things out and, over time, the more useful, reusable, learnable, (etc.) ideas tend to become the norm within that subculture. In such a context, your suggestion regarding a variation on the process of object-making would get debated, tried out, praised, criticized, etc... until the community converged on a way to address the issue in a consistent way. We don't seem to have such a mechanism here. For example, we've been intermittently talking about MAP for almost a year and a half on this list (at least, that's how far back escribe can find references). Several of us have (re)invented variations on that theme, yet once the discussion dies down, it's forgotten. We have no way to get this into any forum where we understand its progress (or lack thereof) into the language or a "standard library". The same could be said of many other specific proposals/discussions. Soooo... In the absence of such mechanisms, I tend to be fairly conservative and minimalist in terms of what I have time and attention span to think about or experiment with. PLEASE let me emphasize that I'm not being negative or critical of your suggestion, but just trying to raise what I perceive as some practical limitations to our ability to experiment with REBOL... Thanks for listening to the rant! ;-) -jn- -- ; sub REBOL {}; sub head ($) {@_[0]} REBOL [] # despam: func [e] [replace replace/all e ":" "." "#" "@"] ; sub despam {my ($e) = @_; $e =~ tr/:#/.@/; return "\n$e"} print head reverse despam "moc:xedef#yleen:leoj" ;

 [18/38] from: jelinem1:nationwide at: 19-Oct-2001 8:26


This behavior is not intuitive? Surely you jest. Let me repeat just so I really understand: you expected test2 and test3 to be locally defined within the object's context? WHY did you expect that? That would be INCONSISTENT with the rest of REBOL. I find the workings of REBOL to be straight-forward and simple (the bugs are a different topic). If you want a language which behaves more like C++ and Java, write a REBOL dialect. - Michael Jelinek Graham Chiu <[gchiu--compkarori--co--nz]> Sent by: [rebol-bounce--rebol--com] 10/19/01 12:21 PM Please respond to rebol-list T To: [rebol-list--rebol--com] cc: bcc: Subject: [REBOL] Re: object funnies On Fri, 19 Oct 2001 15:42:15 +1300 "Andrew Martin" <[Al--Bri--xtra--co--nz]> wrote:
> Ladislav wrote: > > Essentially, the MAKE searches the SPEC block (but not
<<quoted lines omitted: 6>>
> set-word! to the start > of the object's block, so that Graham's:
I'm actually left wondering why RT chose to implement it in this way. It's not intuitive, and nor is it discussed in the online core docs. -- Graham Chiu

 [19/38] from: rgaither:triad:rr at: 19-Oct-2001 10:38


>This behavior is not intuitive? Surely you jest. Let me repeat just so I >really understand: you expected test2 and test3 to be locally defined >within the object's context? WHY did you expect that? That would be >INCONSISTENT with the rest of REBOL. I find the workings of REBOL to be >straight-forward and simple (the bugs are a different topic).
I've got to go with Graham on this one. Much as I like REBOL I find this departure from the typical "Scope" behavior of other languages counter intuitive - consistent as it may be within REBOL, which is another topic! :-) I wouldn't expect test2 and test3 to be in the object's context but I would expect them to be inside the function's context, inside the object's context. Not exposed at a global level just because they are inside a function. Just my .02, Rod.
>If you want a language which behaves more like C++ and Java, write a REBOL >dialect.
<<quoted lines omitted: 34>>
>[rebol-request--rebol--com] with "unsubscribe" in the >subject, without the quotes.
Rod Gaither Oak Ridge, NC - USA [rgaither--triad--rr--com]

 [20/38] from: jelinem1:nationwide at: 19-Oct-2001 11:08


Then which way is "better" depends on who the intended audience is for REBOL: is it for those people who are twisted by over-exposure to languages with an affinity for local scoping, or for those who do not necessarily have much programming background and are not familiar with these implicit rules? - Michael (Don't be offended by the twisted reference; I'm just throwing back what I've caught from exposure to BASIC). Rod Gaither <[rgaither--triad--rr--com]> Sent by: [rebol-bounce--rebol--com] 10/19/01 09:38 AM Please respond to rebol-list T To: [rebol-list--rebol--com] cc: bcc: Subject: [REBOL] Re: object funnies
>This behavior is not intuitive? Surely you jest. Let me repeat just so I >really understand: you expected test2 and test3 to be locally defined >within the object's context? WHY did you expect that? That would be >INCONSISTENT with the rest of REBOL. I find the workings of REBOL to be >straight-forward and simple (the bugs are a different topic).
I've got to go with Graham on this one. Much as I like REBOL I find this departure from the typical "Scope" behavior of other languages counter intuitive - consistent as it may be within REBOL, which is another topic! :-) I wouldn't expect test2 and test3 to be in the object's context but I would expect them to be inside the function's context, inside the object's context. Not exposed at a global level just because they are inside a function. Just my .02, Rod.
>If you want a language which behaves more like C++ and Java, write a
REBOL
>dialect. >- Michael Jelinek
<<quoted lines omitted: 33>>
>[rebol-request--rebol--com] with "unsubscribe" in the >subject, without the quotes.
Rod Gaither Oak Ridge, NC - USA [rgaither--triad--rr--com]

 [21/38] from: rgaither:triad:rr at: 19-Oct-2001 13:51


Hi Michael,
>Then which way is "better" depends on who the intended audience is for >REBOL: is it for those people who are twisted by over-exposure to >languages with an affinity for local scoping, or for those who do not
I am in that twisted camp. :-) I should warn you that I am not a "scripting" programmer and I do have years of exposure to several "old" languages. Perhaps my perspective for REBOL is thus warped beyond repair. I would however like a language to gently help me "improve" my programming by providing default behaviors that aim towards robustness and reusability rather than towards chaos and mayhem. I am open to some examples that show a design value because of this default behavior. I can only think of the problems such uncontrolled references can lead to.
>necessarily have much programming background and are not familiar with >these implicit rules?
Perhaps, but even that audience is going to struggle scaling up projects if they don't learn something about encapsulation and defined interfaces. Areas that this default function context behavior doesn't help with.
>- Michael > >(Don't be offended by the twisted reference; I'm just throwing back what >I've caught from exposure to BASIC).
None taken, just a lively discussion. As for a BASIC reference you would be in big trouble if that was your base of judgement of other "old" languages! :-) Thanks, Rod.
>Rod Gaither <[rgaither--triad--rr--com]> >Sent by: [rebol-bounce--rebol--com]
<<quoted lines omitted: 93>>
>[rebol-request--rebol--com] with "unsubscribe" in the >subject, without the quotes.
Rod Gaither Oak Ridge, NC - USA [rgaither--triad--rr--com]

 [22/38] from: greggirwin:mindspring at: 19-Oct-2001 12:12


Hi Joel, Great post. I couldn't agree more. << 2) Have some widely-used means of creating re-usable units of code (components/modules/packages/...), whether delivered by RT or created by the community, so that semi-standard extensions can be widely (and consistently and conveniently) deployed and used.
<snip>
We don't seem to have such a mechanism here.
<snip>
We have no way to get this into any forum where we understand its progress (or lack thereof) into the language or a "standard library". The same could be said of many other specific proposals/discussions.
>>
Chris Morency and I have chatted briefly about putting together a library and I've been working on some tools to facilitate its use. The design is based around the idea of encapsulating related functions inside objects and having tools that let you interactively browse those objects. The basic idea is simple, but how best to organize it so it is managable and also easily extendable hasn't been tackled yet (and doesn't have to be set in stone any time soon). Another key piece, which you alluded to, is dependability. If we have a number of library objects, we need to protect the words they define. I haven't tried using protect on words in a context, but that's what I think we need to do. Using protect on the context doesn't do the trick. Lots of other ideas and details are floating around in my head but that's the kernel. All comments and suggestions are welcome. --Gregg

 [23/38] from: gchiu:compkarori at: 20-Oct-2001 7:54


> Then which way is "better" depends on who the intended > audience is for > REBOL: is it for those people who are twisted by > over-exposure to > languages with an affinity for local scoping, or for
Michael, I don't have a problem with Rebol being different as long as these differences are clearly stated. When I last looked, this was not explained in the online core docs. Rebol, whether intentionally or not, borrows from forth, and in that language, in so much as I remember, variables, functions etc defined within a different vocabulary are kept distinct from the main dictionary, and are only available by switching contexts. -- Graham Chiu

 [24/38] from: jelinem1:nationwide at: 19-Oct-2001 14:39


> As for a BASIC reference you would be in big trouble if that was your
base of judgement of other "old" languages! :-) LOL. Agreed. I like to think I judge each different language on its own merit, and having been exposed to several very different languages (more than I am actually fluent with) I tend not to assume behaviors from one language to the next. Thus I am not bothered by the default behavior of using the global context because that seems to be the REBOL way. I can also understand and even agree with your more professional point of view of creating larger projects and the software engineering principles involved. But, changing this behavior of REBOL may be opening up a can of worms. If variables are scoped locally by default, now I need a way to specify that I want my variable to be visible outside the context - like extern in C. We now have it the other way around. And what about persistent local variables? That also seems to fall in this same topic. Wouldn't we need the introduction of additional syntax to specify these things? (uuuhhgg, syntax) Scaling REBOL to cleanly handle these necessary SE issues would be a challenge, I think. IMO REBOL was not targetted for this, based on the current functionality of the language. I've always thought of REBOL as a language to "Keep simple tasks simple." This implies small tasks and programs, where these deeper programming issues do not surface. - Michael Rod Gaither <[rgaither--triad--rr--com]> Sent by: [rebol-bounce--rebol--com] 10/19/01 12:51 PM Please respond to rebol-list T To: [rebol-list--rebol--com] cc: bcc: Subject: [REBOL] Re: object funnies Hi Michael,
>Then which way is "better" depends on who the intended audience is for >REBOL: is it for those people who are twisted by over-exposure to >languages with an affinity for local scoping, or for those who do not
I am in that twisted camp. :-) I should warn you that I am not a "scripting" programmer and I do have years of exposure to several "old" languages. Perhaps my perspective for REBOL is thus warped beyond repair. I would however like a language to gently help me "improve" my programming by providing default behaviors that aim towards robustness and reusability rather than towards chaos and mayhem. I am open to some examples that show a design value because of this default behavior. I can only think of the problems such uncontrolled references can lead to.
>necessarily have much programming background and are not familiar with >these implicit rules?
Perhaps, but even that audience is going to struggle scaling up projects if they don't learn something about encapsulation and defined interfaces. Areas that this default function context behavior doesn't help with.
>- Michael > >(Don't be offended by the twisted reference; I'm just throwing back what >I've caught from exposure to BASIC).
None taken, just a lively discussion. As for a BASIC reference you would be in big trouble if that was your base of judgement of other "old" languages! :-) Thanks, Rod.
>Rod Gaither <[rgaither--triad--rr--com]> >Sent by: [rebol-bounce--rebol--com]
<<quoted lines omitted: 93>>
>[rebol-request--rebol--com] with "unsubscribe" in the >subject, without the quotes.
Rod Gaither Oak Ridge, NC - USA [rgaither--triad--rr--com]

 [25/38] from: joel:neely:fedex at: 19-Oct-2001 15:06


Hi, again, Rod and Graham, Rod Gaither wrote:
> Much as I like REBOL I find this departure from > the typical "Scope" behavior of other languages
<<quoted lines omitted: 3>>
> >the online core docs. > >
There are lots of different ways in REBOL to create contexts (and please forgive me if I insult your intelligence... ;-) The thing that REBOL does is let us manipulate context/"scope" relationships in ways that are not as convenient (or in some cases possible) in other languages. Consider this example: factory: make object! [ population: 0 artifact: make object! [ myself: none x: 42 clone-me: func [xx] [ population: population + 1 make myself [x: xx] ] ] artifact/myself: artifact census: func [] [print ["There are" population "artifacts."]] ] ur-artifact: factory/artifact When CLONE-ME inside of ARTIFACT refers to POPULATION it is really intended for it to be a word named POPULATION that belongs to a distinct context (that of FACTORY), not automagically creating a new one within the context of ARTIFACT itself. Thus we can do
>> tom: ur-artifact/clone-me 17 >> dick: tom/clone-me 357 >> harry: dick/clone-me 999 >> factory/census
There are 3 artifacts. Since the definition of an OBJECT! can take place within a variety of other constructs that also create contexts, it would be limiting to have *every* set-word within the object (regardless of nesting) interpreted as pertaining to the object's context. Of course, this throws us back into the Fundamental Equation of Legitimate Empowerment: capability = responsibility otherwise known as TANSTAAFL !-} -jn- -- This sentence contradicts itself -- no actually it doesn't. -- Doug Hofstadter joel<dot>neely<at>fedex<dot>com

 [26/38] from: rgaither:triad:rr at: 19-Oct-2001 16:50


I most heartily agree with the points below. I was not advocating a change as necessary but rather defending the observation that the behavior wasn't intuitive. Something rather hard to quantify I admit. I have the problem of wanting to use the language for much larger tasks than you are suggesting and thus "have" to deal with these issues. This can be done, and even done well - or I wouldn't still be working with REBOL - but it requires more effort than I would like at spots and a shift in how a problem is approached that makes for slow going some times. Thanks, Rod.
>> As for a BASIC reference you would be in big trouble if that was your >base of judgement of other "old" languages! :-)
<<quoted lines omitted: 18>>
>programs, where these deeper programming issues do not surface. >- Michael
Rod Gaither Oak Ridge, NC - USA [rgaither--triad--rr--com]

 [27/38] from: ingo:2b1 at: 20-Oct-2001 10:55


Hi all, (I tried to sort my thoughts first, but didn't succeed, so you'll have to live with what you'll now get ;-) I think there are two reasons Rebol defaults to use words global: - it's easier to implement - it's more consistent And now some random thoughts ... AFAIK those languages defaulting to local contexts need their variables to be declared in the respective contexts, am I right here? For Rebol, where words don't have to be declared it gets a little bit complicated ... f: func [a][ v: a ] ; 'v should default to local, right? f: func [a][ print a ] ; but sure you'll want the global 'print ? Hhhhmmmm, OK, set-words default to local, get-words to global context. Now something a little more weird f: func [a][ print a p: :print print: func [b][p ["-->" b] print a ] Should the first print use the global word? Or is print local to the function, so it is undefined in the first line? (Having said that, I really like default to local, and I've once sent a proposal to feedback about a "reversed-logic" func: f: func[a /global g][ ... ] with 'g being global, all other words being local by default. But AFAIK it is not possible to add words to a context once it's created, so we just _can't_ catch every word in the local context, yet ...
>> ha
** Script Error: ha has no value ** Near: ha
>> c: context [f: func[w][do compose [(to-set-word w) 2] ]] >> c/f "ha"
== 2
>> ha
== 2 ) Well, as I said, just some random thoughts, and I'd be glad if you can prove me wrong ... kind regards, Ingo

 [28/38] from: g:santilli:tiscalinet:it at: 20-Oct-2001 15:02


Hello Ingo! On 20-Ott-01, you wrote: IH> (Having said that, I really like default to local, and I've IH> once sent a proposal to feedback about a "reversed-logic" IH> func: IH> f: func[a /global g][ ... ] use [apply] [ ; apply a function recursively apply: func [block [any-block!] code [function!]] [ foreach value :block [ either any-block? :value [ apply :value :code ] [ code :value ] ] ] ; you might find this useful, too... recurse: func ['word [word!] block [block!] code [block!]] [ code: func reduce [word] code apply block :code ] my-func: func [spec [block!] code [block!] /local globals locals] [ either globals: find spec /global [ spec: copy/part spec globals globals: copy next globals ] [ globals: [] ] locals: make block! length? code recurse value code [ if any-word? :value [ append locals to-word :value ] ] foreach value spec [ if any-word? :value [ append globals to-word :value ] ] locals: exclude locals globals insert insert tail spec /local locals func spec code ] ]
>> f: my-func [a b /global + print set] [ [ c: a + b
[ print [a b c] [ set [e f g] [5 6 7] [ print [e f g] [ ]
>> source f
f: func [a b /local c e f g][ c: a + b print [a b c] set [e f g] [5 6 7] print [e f g] ]
>> f 3 4
3 4 7 5 6 7 IH> But AFAIK it is not possible to add words to a context once IH> it's created, so we just _can't_ catch every word in the IH> local context, yet ... Really? :-) Anyway, I don't like it this way. I find it more difficult to remember to enumarate the global words... (I hate PHP for this...) Regards, Gabriele. -- Gabriele Santilli <[giesse--writeme--com]> - Amigan - REBOL programmer Amiga Group Italia sez. L'Aquila -- http://www.amyresource.it/AGI/

 [29/38] from: ingo:2b1 at: 20-Oct-2001 19:31


Hi Allen, to find words that spilled out into the global context I just do ... query/clear system/words ; do your script query system/words Seems easier to me. kind regards, Ingo Once upon a time Allen Kamp spoketh thus:

 [30/38] from: ingo:2b1 at: 20-Oct-2001 19:16


Hi Gabriele, Once upon a time Gabriele Santilli spoketh thus:
> Hello Ingo! > > On 20-Ott-01, you wrote: > > IH> (Having said that, I really like default to local, and I've > IH> once sent a proposal to feedback about a "reversed-logic" > IH> func:
On retrospect, I forgot to add that it would be a pain to use in a language where "variables" don't have to be declared, e.g. Rebol. < stripped some brilliant Rebol code, sorry >
> Really? :-)
I _said_ prove me wrong, din't I? anway ...
>> f: my-func[w /global do compose to-set-word][do compose [(to-set-word w) 2]] >> source f
f: my-func [w /local][do compose [(to-set-word w) 2]]
>> f "ho"
== 2
>> ho
== 2 It didn't catch 'ho, did it? ;-)
> Anyway, I don't like it this way. I find it more difficult to > remember to enumarate the global words... (I hate PHP for this...)
All in all, you're right here. kind regards, Ingo

 [31/38] from: allenk:powerup:au at: 21-Oct-2001 8:08


----- Original Message ----- From: "Ingo Hohmann" <[ingo--2b1--de]> To: <[rebol-list--rebol--com]> Sent: Sunday, October 21, 2001 3:31 AM Subject: [REBOL] Re: object funnies
> Hi Allen, > to find words that spilled out into the global context I
<<quoted lines omitted: 3>>
> query system/words > Seems easier to me.
Good point Ingo. I forgot about that recent change to query when I posted the script. Thanks, Allen K

 [32/38] from: lmecir:mbox:vol:cz at: 21-Oct-2001 0:37


Hi, I will try to insert my thoughts to Ingo's notes.
> ... there are two reasons Rebol defaults to use words global: > > - it's easier to implement > - it's more consistent
I would like to be more specific: 1) any language I know of has got symbols that are global by default without being declared as global. Those are the symbols that are called reserved words. Example: WHILE, UNTIL, IF 2) Rebol doesn't have any reserved word, but it surely is desirable to have the above symbols accessible easily (ergonomical reasons) 3) That is why the above global words should be usable without need for declarations, etc. 4) OTOH, there is a need to have local words too. How can it be done in Rebol? The first possibility is to use USE. Disadvantages: the "leaks" can occur easily and that surely isn't ergonomical. 5) The above has been recognized by Carl, because he didn't use the method for object specs. The user doesn't have to provide a list of the words he wants to define locally, because any local word must be set to refer to a meaningful value. That is why the implicit definition of all locally set words as local is natural and can spare a lot of programmer's work. Unfortunately, this method isn't used generally, which means that "leaks" are still probable, like in the case x: 1 o: make object! [ a: 1 either x = 1 [ b: 1 ] [ c: 1 ] ] , where I would prefer 'b and 'c to be local to their respective blocks, which would prevent any leaks. Neither the current behaviour nor the behaviour I proposed would do what the user wanted, but the detection of the bug is easier in the latter case, I think. The behaviour the user (probably) wanted can be achieved as follows: x: 1 o: make object! compose [ a: 1 ( either x = 1 [ first [b:] ] [ first [c:] ] ) 1 ]
> And now some random thoughts ... > > AFAIK those languages defaulting to local contexts need their > variables to be declared in the respective contexts, am I right > here? For Rebol, where words don't have to be declared it gets a > little bit complicated ... > > f: func [a][ v: a ] ; 'v should default to local, right?
I think, that the safest and the most useful practice for 'v would be to default to local in this case
> f: func [a][ print a ] ; but sure you'll want the global 'print ? > Hhhhmmmm, OK, set-words default to local, get-words to global context.
<<quoted lines omitted: 7>>
> Should the first print use the global word? Or is print local to the > function, so it is undefined in the first line?
If 'print should be local (see print:), then it should be local throughout the whole block, which is the safest and simplest rule. Having said the above, what if the user wrote something like: x: 1 o: make object! [ a: 1 b: 1 either x = 1 [ a: a + 1 ] [ a: a + 2 ] ] This would result in an error, because in the either block, the word 'a would have been local. For the cases where a user really wants to change 'a while having the "set-word defaults to local" rule, there would have to be a different kind of word, a change-word, which would allow to write something like: x: 1 o: make object! [ a: 1 b: 1 either x = 1 [ a:: a + 1 ] [ a:: a + 2 ] ] For the rules to be safe, similarly as CHANGE and INSERT for blocks, trying to change an unset word should be considered an error, and trying to set a word previously set (like in [a: 1 a: a + 1]) should be considered an error too. If these rules were used consequentially, I think, that safety would win.

 [33/38] from: gchiu:compkarori at: 21-Oct-2001 17:18


Hi Chris,
> Maybe because although you would like to encapsulate some > variables in an > object, you still want it to be able to define global > words through its > methods. Hence what is not declared as local is global.
Yes, but no, I don't want any globals.
> I've looked at your code, have you noticed you call the > initialise functions
<<quoted lines omitted: 13>>
> it's something you > have overlooked...
No that's correct. Init-variables sets the value of all the variables which are dependent upon the value of cellsize. When the board is resized, it is called again - in the resize-board function which you call 'do-something.
> Finally, it's not unusual to take something procedural > and making > object-oriented. However I personnally don't think it > should be as easy as > adding make object! [ ... ]. If you want to make your > code oop'ed, redesign
Haha. From what I read, it was just a matter of wrapping my procedural code into a separate context :)
> it all for this. I strongly suggest you to use self to > refer to the > properties or methods within the object, this help > understand the code... >
Yes, I agree.
> But more on the subject of objects pretty soon... >
And I shall look forward to your How-to on objects :) -- Graham Chiu

 [34/38] from: g:santilli:tiscalinet:it at: 21-Oct-2001 12:01


Hello Ingo! On 20-Ott-01, you wrote: IH> It didn't catch 'ho, did it? ;-) That's coming from outside! ;-) And if you really want that to be catched too, just write a DO-LOCALLY function which returns an object with the used words. :-) Regards, Gabriele. -- Gabriele Santilli <[giesse--writeme--com]> - Amigan - REBOL programmer Amiga Group Italia sez. L'Aquila -- http://www.amyresource.it/AGI/

 [35/38] from: ingo:2b1 at: 21-Oct-2001 22:04


Hi Gabriele, Once upon a time Gabriele Santilli spoketh thus:
> Hello Ingo! > > On 20-Ott-01, you wrote: > > IH> It didn't catch 'ho, did it? ;-) > > That's coming from outside! ;-) > > And if you really want that to be catched too, just write a > DO-LOCALLY function which returns an object with the used words.
But that's what I meant, you can't write a 'func that is sure to catch _all_ words into the local context. So you still would have to pay attention on what you are doing inside the 'func. Better have default to global, at least you know that you'll have to be carefull not to spill words into the global context. kind regards, Ingo

 [36/38] from: lmecir:mbox:vol:cz at: 22-Oct-2001 12:30


Hi Ingo, I reserve my right to respectfully disagree. The fact is, that the variants discussed weren't the only possibilities, because you omitted some interesting (at least for me) choices. ...skip...

 [37/38] from: ingo:2b1 at: 23-Oct-2001 13:06


Hi Ladislav, if you disagree, that's fine with me (wether respectfully or not), but I'd like to ask you to what choices you refer, though I may not possibly understand what you are telling me, as the deeper mysteries of Rebol, to me, are just that. kind regards, Ingo Once upon a time Ladislav Mecir spoketh thus:

 [38/38] from: lmecir:mbox:vol:cz at: 23-Oct-2001 23:30


Hi Ingo, ...
> I'd like to ask you to what choices you refer,
...
> > > Better have default to global, at least you know that you'll have > > > to be carefull not to spill words into the global context.
... My preferences are: 1) (Default to global) words 'if and 'true shall not be local in: [if true [true]] and in similar situations 2) (Default to local) we need local words sometimes. The most convenient Rebol method for local word definition is as follows: make object! [a: 1] We do not need to specify what shall be local in this case, do we? Moreover, this proves, that the "default to global" rule has got exceptions. 3) I think, that a suitable mix of these two may be the best solution, which may work even without the need to have USE or /LOCAL

Notes
  • Quoted lines have been omitted from some messages.
    View the message alone to see the lines that have been omitted