variable scopes and recursive func
[1/21] from: sags::apollo::lv at: 10-Apr-2005 21:36
Hi, Rebolers!
I am new in rebol scopes. So it seems, that it cause problems in
my recursive directory reading function.
Could somebody give me a bit more description about variable
scopes in following case:
readChaptDir2: func [ thisDir ] [
rez: copy thisDir
repeat aFile read thisDir [
either #"/" = last aFile [
repend rez [ "<br>dir:" join thisDir aFile ]
repend rez readChaptDir2 join thisDir aFile
][
repend rez [ <br> aFile ]
]
]
return rez
]
Looking forward,
Janeks
[2/21] from: mokkel:gmx at: 10-Apr-2005 22:44
Hi,
if you change the repeat line to
repeat aFile read thisDir copy/deep [
it will work, as repeat modifies the block to be repeated. See also at
http://www.rebol.com/docs/words/wrepeat.html
the user comment from Ladislav.
Didn't know this myself - until now. :-)
Michael
On Sun, 10 Apr 2005 21:36:25 +0300, <[sags--apollo--lv]> wrote:
[3/21] from: sags::apollo::lv at: 10-Apr-2005 23:13
Thanks!
I noted this (copy/deep), but now it is working without errors,
but not corectly:
First line is wrong - first directory of base dir is added,
and then just files of base dir.
brgds
Janeks
On 10 Apr 2005 at 22:44, Michael Berg wrote:
[4/21] from: mokkel:gmx at: 10-Apr-2005 23:43
:-) Sorry, I maybe posted it too fast. I'm still searching for the the why.
I think that's one of the bad parts of Rebol. This dynamic binding might
be powerful, but it causes a lot of trouble as well. For instance besides
your note, I don't get right now why it for instance without copy/deep
brings up an error when it encounters an empty directory, und with
copy/deep it runs. (at least without the error message)
Nevertheless it works with copy deep if you add in the argument section a
/local rez
. I think you forgot to make rez local to the function as it
is by standard global and gets everytime deleted. :-)
Michael
On Sun, 10 Apr 2005 23:13:14 +0300, <[sags--apollo--lv]> wrote:
[5/21] from: mokkel::gmx::de at: 11-Apr-2005 1:03
Ok, last time - I hope. :-)
If I'm right the reason why the error came up at the first empty directory
and if there has been none, then only the first subtree is traversed,
because of the recursive rebinding of the word 'aFile to the repeat block.
While recursing down the first branch of the directory tree the block gets
all the time bound to a new version of 'aFile. Upon returning back from
the recursion the function one level up doesn't find any more the 'aFile
from before the recursive call and thus the test doesn't work or even
fails. Fails when 'aFile has been bound to no value in the recursion when
the directory was empty or to the last value of the file in the deepest
directory, which just gets added as often as during the walk up in the
tree some files (no directories) are encountered, because always the
second block of 'either gets executed.
:-)
Just a question to somebody who might know: One of the reasons why the
binding mechanisms of Rebol are necessary is to make the keywordlessness
possible, else something like 'repeat wouldn't be possible, right ???
But nevertheless I think these binding issues should be one of the first
things to be explained to a newcomer. It is an important property of Rebol
and should be treated like this. If there are chances to encounter these
things in normal life they have to be explained appropriately already on
the beginning and not on some articles (Ladislavs Bindology) or some
sidenote in the documentation that a function changes it's body argument.
Without deeper glue of Rebol it's hardly to get the reason and just simply
using hints like using copy/deep on a block in some circumstances is hard
to remember and hard to explain. Thus if Rebol is like this it should be
put on the frontplate. ????!!!!
Michael
On Sun, 10 Apr 2005 23:43:04 +0300, Michael Berg <[mokkel--gmx--de]> wrote:
[6/21] from: vincent_ecuyer::yahoo::com at: 11-Apr-2005 0:09
Hi Janeks,
> readChaptDir2: func [ thisDir ] [
> rez: copy thisDir
'rez is a %filename here ('copy don't change the datatype,)
so result string is a very long %filename !
> repend rez [ "<br>dir:" join thisDir aFile ]
'rez is already initialized with the full dir name,
you don't need to add it.
instead of using copy/deep, you can replace 'repeat by 'foreach,
so your function becomes:
readChaptDir2: func [ thisDir /local rez ] [
rez: to-string thisDir
foreach aFile read thisDir [
either #"/" = last aFile [
repend rez "<br>dir:"
repend rez readChaptDir2 join thisDir aFile
][
repend rez [ <br> aFile ]
]
]
return rez
]
--Vincent
__________________________________________________________________
Découvrez le nouveau Yahoo! Mail : 250 Mo d'espace de stockage pour vos mails !
Créez votre Yahoo! Mail sur http://fr.mail.yahoo.com/
[7/21] from: tom::conlin::gmail::com at: 10-Apr-2005 21:52
I too recomend 'foreach because it seems more clear as well.
might also want to look at
either dir? aFile[... ][... ]
On Apr 10, 2005 3:09 PM, Vincent Ecuyer <[vincent_ecuyer--yahoo--com]> wrote:
> Hi Janeks,
> > readChaptDir2: func [ thisDir ] [
<<quoted lines omitted: 25>>
> To unsubscribe from the list, just send an email to
> lists at rebol.com with unsubscribe as the subject.
--
... nice weather eh
[8/21] from: antonr::lexicon::net at: 11-Apr-2005 22:07
I don't recommend using DIR?.
If you look at the source of DIR? you can see it
accesses the filesystem each time it is called,
so this is much slower than checking for a final slash.
The code would also have to be:
either dir? join thisDir aFile [...
because the current dir has not been set to thisDir.
Anton.
---
Tom Conlin wrote:
[9/21] from: sags::apollo::lv at: 11-Apr-2005 23:55
Thanks, Michael!
Those bindings is unlear for me yet.
But at least those variable scopes stays more clearer.
Now the function is working with "repeat" and sorting list in a
proper way.
Now the problem is how to add depth counter:
readChaptDir2: func [ thisDir depth
/local rez curDepth
] [
curDepth: depth - 1
rez: copy thisDir
repeat aFile sort read thisDir copy/deep [
either #"/" = last aFile [
repend rez [ "<br>dir:" join thisDir aFile
curDepth ]
repend rez readChaptDir2 join thisDir aFile
curDepth
][
repend rez [ <br> aFile ]
]
]
return rez
]
brgds
Janeks
On 11 Apr 2005 at 1:03, Michael Berg wrote:
[10/21] from: mokkel:gmx at: 12-Apr-2005 1:05
Hi Janeks,
why don't you simply use just the depth parameter to the function and if
you recurse down the directory tree add always one to the depth value.
Then you can do in the function whatever you like with the depth parameter
and you don't need a local parameter.
It's anyway not clear to me how your output is supposed to look exactly.
What about this version, which works but still gives some kind of
senseless output ?
readChaptDir2: func [ thisDir depth
/local rez bl
] [
rez: copy thisDir
bl: sort read thisDir ;separate to be able to see what happends
probe bl ;just for debugging
repeat aFile bl copy/deep [
print aFile ;just for debugging
either #"/" = last aFile [
repend rez [ "<br>dir:" join thisDir aFile depth + 1 ]
repend rez readChaptDir2 join thisDir aFile (depth + 1
][
repend rez [ <br> aFile ]
]
]
return rez
]
readChaptDir2 %somedir/ 0
Michael
On Mon, 11 Apr 2005 23:55:54 +0300, <[sags--apollo--lv]> wrote:
[11/21] from: sags:apollo:lv at: 12-Apr-2005 21:25
Hi, Michael!
What I want to get is negative depth counter and control to do
not iterate deeper than depth parameter.
And I actualy did the same like in your example.
All that rez variable is just for debugging and studying purposes
yet ;-)
What is my problem - that in rez output I can't see the depth
variable from line:
repend rez [ "<br>dir:" join thisDir aFile depth + 1 ]
f.ex.:
dir:/c/www/sitex/02setup/Test2/5/c/www/sitex/02setup/Test2/
003.art
dirinfo.txt
dir:/c/www/sitex/02setup/Test2/test3/6/c/www/sitex/02setup/Test2/test3/
003.art
dirinfo.txt
At the end of line dir:... should be a number!
It is why I started to play with curDepth...
Janeks
On 12 Apr 2005 at 1:05, Michael Berg wrote:
[12/21] from: berniegs::prodigy::net at: 12-Apr-2005 13:38
Hi,
I agree with you Michael. The subject of Rebol scopes, contexts,
and bindings for me is the single most unclear and confusing
aspect of Rebol. Using Rebol requires that a programmer become
familiar with several new and innovative features that can be
quite confusing, even, or maybe especially, for programmers with
a lot of experience using other languages.
For example, Rebol's parsing is one of these powerful, but
unfamiliar features to those of us steeped in regular
expressions. But
I've found that with a lot of practice and with the steadily
improving documentation on the subject, that I can get more
parsing challenges mastered that I could at first. But with
Rebol's context and binding concepts, I'm afraid that I'm no
farther along in my understanding than I was when I first
started several years ago. I just can't find any documentation
on this important Rebol feature that takes into account the fact
that I've never encountered anything like it in any of the
dozens of languages that I've worked with before. And now, with
important new features like Rebol/Services coming out that
depend heavily on an understanding of contexts, I'm afraid that
I'm going to be completely left behind in such areas. I think
that it's important that RT try to make a significant effort
to clarify bindings and contexts for those of us (and I don't
believe that I'm alone here) who just don't get it yet.
I hope that I'm coming across as being constructive here. I
really don't mean to sound too critical. I'm just trying to
point out that these issues aren't as clear to some of us as
some others might think, and that some further attention in the
form of documentation and maybe some in-depth tutorials would be
of great benefit to the Rebol community.
Regards,
Bernie Schneider
The individual has always had to struggle to keep from being
overwhelmed
by the tribe. To be your own man is a hard business. If you try
it, you will
be lonely often and sometimes frightened. But no price is too
high to pay
for the privilege of owning yourself.
-- Friedrich Nietzsche --
----- Original Message -----
From: "Michael Berg" <[mokkel--gmx--de]>
To: <[rebolist--rebol--com]>
Sent: Sunday, April 10, 2005 6:03 PM
Subject: [REBOL] Re: variable scopes and recursive func
================== SNIP ===================
> Just a question to somebody who might know: One of the reasons
why the
> binding mechanisms of Rebol are necessary is to make the
keywordlessness
> possible, else something like 'repeat wouldn't be possible,
right ???
> But nevertheless I think these binding issues should be one of
the first
> things to be explained to a newcomer. It is an important
property of Rebol
> and should be treated like this. If there are chances to
encounter these
> things in normal life they have to be explained appropriately
already on
> the beginning and not on some articles (Ladislavs Bindology)
or some
> sidenote in the documentation that a function changes it's
body argument.
> Without deeper glue of Rebol it's hardly to get the reason and
just simply
> using hints like using copy/deep on a block in some
circumstances is hard
> to remember and hard to explain. Thus if Rebol is like this it
should be
> put on the frontplate. ????!!!!
>
================ SNIP =======================
[13/21] from: greggirwin:mindspring at: 12-Apr-2005 13:20
Hi Janeks,
sal> What is my problem - that in rez output I can't see the depth
sal> variable from line:
Look at your two REPEND lines. :)
More on this thread in a bit...
-- Gregg
[14/21] from: sags:apollo:lv at: 12-Apr-2005 23:06
> dir:/c/www/sitex/02setup/Test2/5/c/www/sitex/02setup/Test2/
^
Sorry, depth counter is working !
Janeks
On 12 Apr 2005 at 21:25, [rebolist--rebol--com] wrote:
> Hi, Michael!
>
> What I want to get is negative depth counter and control to do
> not iterate deeper than depth parameter.
> And I actualy did the same like in your example.
> All that rez variable is just for debugging and studying
purposes yet
> ;-) What is my problem - that in rez output I can't see the
depth
> variable from line:
> repend rez [ "<br>dir:" join thisDir aFile depth + 1 ]
> f.ex.:
> dir:/c/www/sitex/02setup/Test2/5/c/www/sitex/02setup/Test2/
> 003.art
> dirinfo.txt
>
dir:/c/www/sitex/02setup/Test2/test3/6/c/www/sitex/02setup/Test2/
test3
> / 003.art dirinfo.txt
> At the end of line dir:... should be a number!
<<quoted lines omitted: 5>>
> >
> > why don't you simply use just the depth parameter to the
function
> > and if you recurse down the directory tree add always one to
the
> > depth value. Then you can do in the function whatever you
like with
> > the depth parameter and you don't need a local parameter.
It's
> > anyway not clear to me how your output is supposed to look
exactly.
> >
> > What about this version, which works but still gives some
kind of
> > senseless output ?
> >
<<quoted lines omitted: 3>>
> > rez: copy thisDir
> > bl: sort read thisDir ;separate to be able to see what
happends
> > probe bl ;just for debugging repeat aFile bl copy/deep [
> > print aFile ;just for debugging
<<quoted lines omitted: 23>>
> > >
> > > Now the function is working with "repeat" and sorting list
in a
> > > proper way. Now the problem is how to add depth counter:
> > >
<<quoted lines omitted: 6>>
> > > either #"/" = last aFile [
> > > repend rez [ "<br>dir:" join thisDir
aFile
> > > curDepth ]
> > > repend rez readChaptDir2 join thisDir
aFile
> > > curDepth
> > > ][
<<quoted lines omitted: 15>>
> > >>
> > >> If I'm right the reason why the error came up at the first
empty
> > >> directory and if there has been none, then only the first
> > >> subtree is traversed, because of the recursive rebinding
of the
> > >> word 'aFile to the repeat block. While recursing down the
first
> > >> branch of the directory tree the block gets all the time
bound
> > >> to a new version of 'aFile. Upon returning back from the
> > >> recursion the function one level up doesn't find any more
the
> > >> 'aFile
> > >> from before the recursive call and thus the test doesn't
work or
> > >> even
> > >>
> > >> fails. Fails when 'aFile has been bound to no value in the
> > >> recursion when the directory was empty or to the last
value of
> > >> the file in the deepest directory, which just gets added
as
> > >> often as during the walk up in the tree some files (no
> > >> directories) are encountered, because always the second
block of
> > >> 'either gets executed.
> > >>
> > >> :-)
> > >>
> > >> Just a question to somebody who might know: One of the
reasons
> > >> why the
> > >> binding mechanisms of Rebol are necessary is to make the
> > >> keywordlessness possible, else something like 'repeat
wouldn't
> > >> be possible, right ??? But nevertheless I think these
binding
> > >> issues should be one of the first things to be explained
to a
> > >> newcomer. It is an important property of Rebol and should
be
> > >> treated like this. If there are chances to encounter these
> > >> things in normal life they have to be explained
appropriately
> > >> already on the beginning and not on some articles
(Ladislavs
> > >> Bindology) or some sidenote in the documentation that a
function
> > >> changes it's body argument. Without deeper glue of Rebol
it's
> > >> hardly to get the reason and just simply using hints like
using
> > >> copy/deep on a block in some circumstances is hard to
remember
> > >> and hard to explain. Thus if Rebol is like this it should
be put
> > >> on the frontplate. ????!!!!
> > >>
> > >> Michael
> > >>
> > >> On Sun, 10 Apr 2005 23:43:04 +0300, Michael Berg
<[mokkel--gmx--de]>
> > >> wrote:
> > >>
> > >> >
> > >> > :-) Sorry, I maybe posted it too fast. I'm still
searching for
> > >> > the the why.
> > >> >
> > >> > I think that's one of the bad parts of Rebol. This
dynamic
> > >> > binding might be powerful, but it causes a lot of
trouble as
> > >> > well. For instance besides your note, I don't get right
now why
> > >> > it for instance without copy/deep brings up an error
when it
> > >> > encounters an empty directory, und with copy/deep it
runs. (at
> > >> > least without the error message)
> > >> >
> > >> > Nevertheless it works with copy deep if you add in the
argument
> > >> > section a "/local rez". I think you forgot to make rez
local to
> > >> > the function as it is by standard global and gets
everytime
> > >> > deleted. :-)
> > >> >
> > >> > Michael
> > >> >
> > >> > On Sun, 10 Apr 2005 23:13:14 +0300, <[sags--apollo--lv]>
wrote:
> > >> >
> > >> >>
> > >> >> Thanks!
> > >> >> I noted this (copy/deep), but now it is working without
> > >> >> errors, but not corectly: First line is wrong - first
> > >> >> directory of base dir is added, and then just files of
base
> > >> >> dir.
> > >> >>
<<quoted lines omitted: 11>>
> > >> >>>
> > >> >>> it will work, as repeat modifies the block to be
repeated.
> > >> >>> See also at
http://www.rebol.com/docs/words/wrepeat.html the
> > >> >>> user comment from Ladislav.
> > >> >>>
<<quoted lines omitted: 5>>
> > >> >>>
> > >> >>> On Sun, 10 Apr 2005 21:36:25 +0300, <[sags--apollo--lv]>
wrote:
> > >> >>>
> > >> >>> >
> > >> >>> > Hi, Rebolers!
> > >> >>> >
> > >> >>> > I am new in rebol scopes. So it seems, that it cause
> > >> >>> > problems in my recursive directory reading function.
Could
> > >> >>> > somebody give me a bit more description about
variable
> > >> >>> > scopes in following case:
> > >> >>> >
<<quoted lines omitted: 3>>
> > >> >>> > either #"/" = last aFile [
> > >> >>> > repend rez [ "<br>dir:" join
thisDir aFile ]
> > >> >>> > repend rez readChaptDir2 join
thisDir aFile
> > >> >>> > ][
> > >> >>> > repend rez [ <br> aFile ]
<<quoted lines omitted: 37>>
> >
> >
------- End of forwarded message -------
[15/21] from: sags:apollo:lv at: 12-Apr-2005 23:08
Me should find a glases!
;-)
Janeks
On 12 Apr 2005 at 13:20, Gregg Irwin wrote:
[16/21] from: greggirwin::mindspring::com at: 12-Apr-2005 14:31
First, it's great to see some new faces here! The lack of responses
from the "regulars" is due to a lot of traffic shifting to AltME
worlds, IOS servers, and some people testing GoogleGroups as an
alternative to the ML (which has had issues for a while, but seems to
be recuperating a bit as of late).
"Using Rebol requires that a programmer become familiar with
several new and innovative features that can be quite confusing"
I'll respectfully disagree with Bernie about that. A lot of people,
myself included, have used REBOL very effectively without knowing that
any of those advanced features even exist. It *can* be confusing if
you happen to be unfortunate enough to do things that bring it into
play. For a lot of people, they're never even aware of it, much less
caring about how it might work. That's part of the design (IMO).
The ones who get hit with it, like Janeks, tend to be programmers who
are used to other languages, as Bernie said. We kind of expect things
to work like they do elsewhere and it makes it hard to visualize
what's going on. The problem for those of us that want to understand
how all these things really work lies in letting go of old notions, or
trying to equate how REBOL works to how other languages work (e.g. to
understand binding, we might be tempted to try and write a little
interpreter that works like REBOL does; we're just sick that way :).
Ladislav's articles offer the most in-depth binding info out there; no
contest. All his articles are well worth reading:
http://www.fm.vslib.cz/~ladislav/rebol/
You can nearly always, in normal use, think of context in terms of
scoping rules in other languages. The big things that can trip you up
are the "hidden context" that functions have (which is why local
series values persist between calls), and passing around blocks that
are evaluated in different contexts.
The case of using REPEAT with a recursive function isn't so much a
context/binding issue, in my mind, as an issue of REPEAT's behavior.
More in-depth info on binding would be helpful to some people, but I
would guess most REBOLers really don't need to know anything about it;
the rest of us can ignore it most of the time too. :)
If you have specific examples that could be used to explain binding,
or that are problematic, that would be good to know.
BS> And now, with important new features like Rebol/Services coming
BS> out that depend heavily on an understanding of contexts, I'm
BS> afraid that I'm going to be completely left behind in such areas.
Assuming you don't get tricky, I don't think you'll really need to
understand much about contexts, except to think of them as namespaces.
I wouldn't worry. LNS is intended to be used by people who don't care
about networking protocols or binding.
BS> For example, Rebol's parsing is one of these powerful, but
BS> unfamiliar features to those of us steeped in regular
BS> expressions...
Yup. Studying BNF and things that use it is the biggest help IMO.
BS> I hope that I'm coming across as being constructive here.
Absolutely. Great post.
-- Gregg
[17/21] from: mokkel:gmx at: 12-Apr-2005 23:33
Hi Bernie,
I'm not even sure whether the binding and context stuff is so
incomprehensible. I somehow just have the feeling that its hard because:
1) it's not treated properly and explained well enough from RT side (most
probably not to confuse beginners)
2) the bindings are not very visible, one has to have quite some
understanding of the Rebol evaluation model and when it binds what, in
order to get it
1) could be resolved to a certain extend by more tutorials, on the other
side I think Rebols way of being makes the dynamic binding necessary. I
don't think it's just to put some more power to the people. E.g. that's
why I was asking/thinking that 'repeat wouldn't be possible without the
dynamic binding. If it would be a build in keyword the interpreter could
use special semantics for it and the binding of the repeat-word could be
hidden better. But as it's just another function and could be equally done
yourself one has to have the possibility to bind a word like repeat-word
to the repeat-block and thus change it.
An interesting question is why for simplicity reasons some things aren't
used by default. E.g. always copy the repeat-block before use. Always use
closures for the functions. This way for a normal person or newcomer some
unexpected effects could be removed. This might a bit contradict the Rebol
philosophy, but as Carl once told in one of the blocks, the default
functions look like this so it's easier for people to lern Rebol as it has
a certain functional style which people know.
I'm also not so sure whether it is that easy to just put the bindology to
the advanced Rebol section, as it happens every now and then that it also
occurs in simple problems as well.
2) I don't know how the visibility could be improved. Most probably it's
just like that. :-) E.g. I was a few days ago checking out once again
Ladislavs closure function 'cfunc, because I forgot a little how it works
and was for some time puzzled by the last line before the return:
result: default [make function! spec result] 'error [throw error]
--> change second :result [do make function!]
There is this funny thing that when result: .... is evaluated one has
already a function like
result: func [x] [do make function! [some stuff...]
So what does the last line really do. Just exchanges the three words 'do
'make 'function! again. Now I know that it's just to enable one to use
these words as parameters to the function one wants to define, as the
exchanged words are not anymore bound to the result-function, but to the
constructing function(This is demonstrated there in an example in the
cfunc.r file). What I wanna say is that the binding fun isn't visible
exept one knows how something is going to be evaluated and bound to what
when.
Just to illustrate this funny thing.
f: func [a b c] [print [a b c]]
a: 5
b: 6
change second second :f [a b]
f 1 2 3
output-> 5 6 3
So I would like to know what reasons speak against making some of these
things by default behave more like other lexically scoped languages. (as
said above always use closures, copy/deep blocks when they get modified)
If the reason is just speed, there could be two versions, one for the
average person which doesn't yet have the full glue or simply doesn't care
and one which might be faster but one has to know the inner workings.
Ok was a bit long mail. Sorry for the readers. :-)
Michael
On Tue, 12 Apr 2005 13:38:01 -0400, Bernie Schneider
<[berniegs--prodigy--net]> wrote:
[18/21] from: mokkel:gmx at: 12-Apr-2005 23:52
Hello Gregg,
as I just was posting some other opinion, I just would like to express,
that you very much could be right. :-) Maybe it's really just an
none-issue to know more about binding. I just have the feeling that if one
knows about the possible quirks that might occur one starts to think too
much about it. And actually in the 'repeat example of Janecks Ladislavs
hint from the Rebol-dictionary would have helped without deeper knowledge,
one only shouldn't start to search for the why. :-)
Michael
[19/21] from: sags:apollo:lv at: 12-Apr-2005 23:53
Thanks, Rebolers!
Finaly I got what I wanted:
readChaptDir2: func [ thisDir depth
/local rez
] [
rez: copy ""
repeat aFile sort read thisDir copy/deep [
if depth > 0 [
either #"/" = last aFile [
repend rez [ "<br>Dir:" join thisDir aFile ]
repend rez readChaptDir2 join thisDir aFile (depth - 1)
][
repend rez [ "<br>file:" join thisDir aFile ]
]
]
]
return rez
]
I'll try to study those binding and scoping things.
I have feeling that there is a power and worth to do it.
brgds
Janeks
[20/21] from: berniegs:prodigy at: 12-Apr-2005 17:11
Hi,
BS> "Using Rebol requires that a programmer become familiar with
several new and innovative features that can be quite
confusing"
GI> "I'll respectfully disagree with Bernie about that. A lot of
people,
myself included, have used REBOL very effectively without
knowing that
any of those advanced features even exist. It *can* be confusing
if
you happen to be unfortunate enough to do things that bring it
into
play. For a lot of people, they're never even aware of it, much
less
caring about how it might work. That's part of the design
(IMO)."
Yes, that's true Gregg. I didn't mean to imply that Rebol can't
be used effectively while ignoring some of its more advanced
features. In fact I've been doing just that, while at the same
time learning more and more about those features, e.g., parsing.
It's just that I've learned from 30+ years of hard experience
that once in a while, I can get into trouble when using some
feature of a language that I didn't think I needed to fully
understand. It doesn't happen very often, but it can be very
frustrating when it does.
GI> "Ladislav's articles offer the most in-depth binding info
out there; no contest. All his articles are well worth reading"
Again true. I've read Ladislav's articles, and I'm very
impressed with the amount of work he has put into them. It's not
his fault of course, but I just have trouble getting my brain
around Rebol's "different" scoping rules. I'll get it
eventually, and in the meantime, I'm able to do some pretty neat
things with Rebol. I just keep wondering when I'll accidentally
step on a land mine because I wasn't careful enough.
Regards,
Bernie Schneider
The individual has always had to struggle to keep from being
overwhelmed
by the tribe. To be your own man is a hard business. If you try
it, you will
be lonely often and sometimes frightened. But no price is too
high to pay
for the privilege of owning yourself.
[21/21] from: greggirwin::mindspring::com at: 12-Apr-2005 15:52
MB> I just have the feeling that if one knows about the possible
MB> quirks that might occur one starts to think too much about it.
MB> ...[the] hint from the Rebol-dictionary would have helped without
MB> deeper knowledge, one only shouldn't start to search for the why.
BS> It's just that I've learned from 30+ years of hard experience
BS> that once in a while, I can get into trouble when using some
BS> feature of a language that I didn't think I needed to fully
BS> understand. It doesn't happen very often, but it can be very
BS> frustrating when it does.
I agree; with both of you. :)
For the most part, we can just ignore it and be happy that REBOL does
what we want it to do, but there are those times...and when they
arrive, we need to understand what is happening.
Thinking in different terms is the hard part. For me, the big hurdles
are:
1) Everything is just data (that may be evaluated at some point).
2) "Definitional Scoping", that is, being aware of where something
is defined with regards to context.
3) Everything is data. There is no "code".
4) Remembering that just because you see x someplace and x just a
short "distance" away doesn't mean they're in the same context.
5) Oh yeah, everything is data.
If you can remember that everything is data, I think it makes it
easier to get into the mindset of thinking about context, where things
are defined (because that usually implies some kind of context), etc.
REBOL makes me write (and read) code in a manner *very* different from
other languages.
-- Gregg
Notes
- Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted