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