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

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