[REBOL] How to form a rule? Re:(4)
[EMAIL PROTECTED] wrote:
> Hi Petr,
>
> I'm also interested in a good challenge - and I happen to be looking for an
> opportunity to practive parse rules.
>
> If you have the time, could you release (on or off list) a more detailed
> specification for what you are trying to do? If parse can't handle it well,
> I'd like to know that that is the case and what the limitation is in your
> case.
>
Well, my abilities to create some parse rules are very limited :-) I am not
sure I would dare to create some recursive rule :-)
But OK, nothing secret here. My intention was to create some search-engine for
our Czech Amiga News site. First version was very primitive, but worked. I used
find/any, but was not satisfied with the result, as t*t would scan the string
for the next occurance in the particular news article. Too much matches was
returned then. So I thought of some mechanism, trying to limit * to word. For
e.g. standalone " * " would skip one word. I think it doesn't work either, it
was just one of my deeper experience with parser.
build-rule: func [str][
str: trim str
while [all [not empty? str (((first str) = #"?") or ((first str) =
#"*"))]][remove str]
; remove all initial "?" or "*"
if empty? str [return none]
if (last str) = #"*" [append str " "]
; ad space if last char is "*" to match the word
s: copy ""
non-wild: complement charset " ?*"
parse/all str [
mark:
(append s {[any [thru "}
append s rejoin [pick mark 1 {" }]
mark: skip mark 1)
:mark
some [copy txt some non-wild (append s join {"} [txt {" }])
|
some [#"?" (append s "skip ")] |
mark:
some [#"*" (append s {thru "}
append s pick mark 2
append s {" }
mark: skip mark 2)
:mark] |
some [#" " (append s {" " })]
]
to end (append s "] to end]")
]
return load s
]
rule: build-rule "*som?, mo?? *; to fi?d"
You can change the func to generate whatever you want. As I said - the problem
is with finding some "s", trying to apply the rule, and if not matched, trying
to find another occurance of "s".
But as I said - should not be a problem to let build-rule to return block,
containing two series - first one, being first char of requested string (in our
example "s", the second one, the entire rest of rule. Then let searchengine to
skip thru "s" and try to apply the rule
rules: build-rule "*som?, mo?? *; to fi?d"
first-char: first rule
rule: second rule
while [tmp: find str first-char][parse tmp ruleand some other code here]
-pekr-
>
> TIA,
>
> Elan >> [: - )]
>
[REBOL] Handy Timer Functions Re:(3)
Larry wrote: > tic5: func [/local t] [ > t: now/time > toc5: func [] [print ["elapsed time:" now/time - t]] > ] This might be slightly more accurate/faster: tic6: func [/local t] [ toc6: func [] [print ["elapsed time:" now/time - t]] t: now/time ] I've just swapped the two lines. Andrew Martin [EMAIL PROTECTED] http://members.xoom.com/AndrewMartin/ Online @ 33,600 Baud! -><-
[REBOL] learning to code... Re:
t wrote: > I've followed the "thanks" thread with interest, because I'm in a similar boat to Petra's. Probably next semester I'll start with C or Java or somthing. If you have the choice, choose Java or C++ first, then C later. Bjarne Stroustrup recently pointed out that it's better for beginners to learn C++ first, then C. > So Rebol won't ruin me for other languages, but instead help me understand them? I'm already loyal to REBOL (its got a very high "cool" rating). But I think I have to really dive in to it to learn it. I've written two funcional scripts, but I'm out of stuff to do. > > Any ideas about how I can creep up the learning curve? As Elan suggested, a REBOL language or dialect that generates Java or C++ code would be interesting and would greatly increase your skill level in that language and in REBOL. Andrew Martin [EMAIL PROTECTED] http://members.xoom.com/AndrewMartin/ Online @ 33,600 Baud! -><-
[REBOL] Series essay Re:(7)
See remarks below: Russell [EMAIL PROTECTED] - Original Message - From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, December 28, 1999 4:34 PM Subject: [REBOL] Series essay Re:(6) > Gabriele, > > I think, using your example, that I have found a bug in REBOL. > >> block: copy [] repeat i 4 [use [x] [x: i * i append block 'x]] > == [x x x x] > >> do x/1 I get an error here; x has no value. Did you mean to use 'block in that expression and below, whereever 'x appears? >> do block/1 returns 1, do block/2 returns 4. Thus it appears that even though x has no value globally, it can be "done", ie, evaluated. Interestingly, if you precede your "code" with x: 25, it retains that value after executing your first code line. So the x's that appear in >> block [x x x x] differ from the global x with value 25. > == 1 > >> do x/2 > == 4 > >> x/1 = x/2 > == true > >> x/1 == x/2 > == true > >> > What do you think? Is it a bug? > > Jerry >
[REBOL] finding an item's position Re:(4)
Bo asked: > ... what is "Shadowrun"? It's a roleplaying game, available from FASA. Basically, Cyberpunk mixed with AD&D and real Central American mythology, set in the year 2050. Andrew Martin Mad roleplayer... [EMAIL PROTECTED] http://members.xoom.com/AndrewMartin/ Online @ 33,600 Baud! -><-
[REBOL] "logical" value referencing ... Re:(12)
Hi Joel,
You are certainly correct in pointing out that pointers and indexes can be
converted into each other. But you do have to be careful:
I am sure you agree with me that if i is an index into a buffer,
int i; char buf[10], *p;
then trying to access the element at buf[i] is quite something different
from using the index as a pointer, *i. That would be a huge bug.
Once I have modified the value of a pointer
for (p = buf; *p; p++) { printf ( "%c", *p ) }
I should not expect that *(p+i) is the same thing as buf[i]. The two
notations are convertible, provided I am aware of their differences.
And both Kernighan AND Ritchie would be surprised if given
char buf [10], *p;
I were to say:
for (buf = p; *buf; buf++) { printf ( "5c", *buf ) }
in place of the 'for expression I used above.
So, yes, I concede that they are convertible, without a question, but it's
certainly a good idea to keep in mind, what a pointer is, what a buffer is,
what an index is and in what ways they differ. If you're to survive as a C
programmer that is.
In a different way it is also true for REBOL that I can peek, poke and
eavesdrop in many ways:
first at series 10
pick series 10
and I can always say that I am refering to the 10th element of the series,
no matter how I access it, when I discuss the expressions above. Yet I can
construct values as references to a series, only if those values have the
datatype word! I would like to refine this statement.
It's an interesting thing with series. (Probably you discuss it in your
series essay, which, I admit, I still haven't read, but I think for a good
reason. I can only take very little time right now for the list, and I am
quite sure that once I start reading your essay, I will want to spent a
long time thinking about it and perhaps even some time responding to it
intelligently.)
I can construct a reference to a series, the word block:
>> block: [1 2 3 4 5]
== [1 2 3 4 5]
and embed the word block in a containing block:
>> container: [block]
== [block]
I can also do that programmatically:
>> insert container: [] 'block
== []
>> container
== [block]
REBOL visually represents the embedded reference as the word block. Even
more, type? also recognizes the embedded reference as a word:
>> type? first container
== word!
And - as we all know - I can retrieve the value being referenced - using get:
>> get first container
== [1 2 3 4 5]
None of this is sensational.
I can also say:
>> c: head insert/only [] block
== [[1 2 3 4 5]]
Since the word is evaluated before 'insert receives its argument, what is
inserted in c is visually represented as the value and not as the word by
which I was referencing it (also quite known and not sensational). Insert
has no clue that I was referencing the block I inserted using the word
'block, which is fine:
>> c
== [[1 2 3 4 5]]
It's perhaps a little more interesting to note that type? also identifies
the inserted block as a block, and not as a reference to a block:
>> type? first c
== block!
But we know that the inserted block is inserted only as a reference:
>> insert first c 1000
== [1 2 3 4 5]
>> c
== [[1000 1 2 3 4 5]]
>> block
== [1000 1 2 3 4 5]
Inserting 1000 into the head of the block embedded in c results in a
modification to the block referenced by the word 'block. Not much of a
surprise. But I think terminologically we need to be able to distinguish
between an embedded reference of the type
container: [block]
and a reference of the type
>> c
== [[1000 1 2 3 4 5]]
They act the same way with in some respects and different in others. I
already demonstrated the use of type?, which in one case returns the
datatype of the referer, whereas in the second case type? returns the
datatype of the value being refered to. Another example:
Even though in both cases the value is being referenced, we can access the
first item of the embedded block using first first
>> first first c
== 1000
whereas - even though in the second example the word 'block is also a
reference to the exact same block - first first container will return an
error:
>> first first container
** Script Error: first expected series argument of type: series money date
object port time tuple
any-function.
** Where: first first container
In short, if we wish to access the value being referenced in the 'container
example:
>> container: [block]
== [block]
we have to explicitly dereference the word:
>> insert get first container
== [1000 1 2 3 4 5]
Since I must *explicitly* dereference the embedded word 'block in order to
get at its value, whereas REBOL *automatically* dereferences the embedded
literal block for me, when I try to insert something into it, or when I
retrieve its datatype using type?, I think it would make sense to refer to
values of type word! as explicit references, whereas we could refer to
embedded series as automatic references.
If you follow me in the distinction I am making here, then I would refine
my previous statement, saying th
[REBOL] Handy Timer Functions Re:(2)
Hi Elan Thanks for the comment. I agree. Actually, I am experimenting with trying to implement Lisp (actually Scheme) programming techniques in REBOL. Capturing state in a function is one of the basic techniques emphasized in Structure and Interpretation of Computer Programs by Abelson and Sussman. I suspect you know this book. Anyway, I found a version of 'tic and 'toc that I like even better than version 3 below. It avoids the awkwardness of using 'compose and is easily generalized for more complex situations. It does not seem to be hurt by 'recycle. tic5: func [/local t] [ t: now/time toc5: func [] [print ["elapsed time:" now/time - t]] ] >> tic5 wait 5 recycle toc5 elapsed time: 0:00:05 What do you think? Larry - Original Message - From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, December 28, 1999 5:50 PM Subject: [REBOL] Handy Timer Functions Re: > Hi Larry, > > first comment, I like your version 3 best: > > >tic3: func [] [toc3: func [] compose/deep [print ["elapsed time:" now/time - > >(now/time)]]] > > This approach really makes good use of REBOL's abilities. While it looks > trivial, I think that functions, which create functions, which in turn > reflect some state at the time the "dynamic" function was created is an > important technique for building smarter programs. In a different > application the state embedded in the created function coould very well be > more complicated and specific to the creating function then in your case. > Imagine a whole chain of function-creating functions. > > Elan >
[REBOL] "logical" value referencing ... Re:(11)
[EMAIL PROTECTED] wrote: > > We are concerned with a terminology that is designed to > conceptualize the REBOL programming language... > No. I am concerned with understanding, and being able to describe and predict, the behavior of REBOL expressions using concepts and terms that are common in the field of computer programming. You, on the other hand, have stated your opposition to that goal. Fair enough. I certainly have neither the desire nor the capability of forcing you to think or speak in a manner of my choosing. However, the converse is also true. In the transcript below: (1)>> a: [1 2 3] == [1 2 3] (2)>> b: reduce [a a] == [[1 2 3] [1 2 3]] (3)>> c: copy b == [[1 2 3] [1 2 3]] (4)>> append a 4 == [1 2 3 4] (5)>> b == [[1 2 3 4] [1 2 3 4]] (6)>> c == [[1 2 3 4] [1 2 3 4]] we observe that the output for lines (5) and (6) differs from the output for lines (2) and (3). In conversation, I would explain that fact by saying that b's first and second elements are both references to the same block as a, as are c's first and second elements. If I were dealing with a beginning student, or with a language lawyer on some ANSI committee, or with someone who seemed particularly determined not to understand me, I might say it with more words: a contains a reference to a block (initially of three elements). b contains a reference to a block of two elements; both of those elements refer to the same block as a. c contains a reference to a different block of two elements; but, again, both of those elements refer to the same block as a. Performing an operation that alters the block referenced by a also alters the values of both elements of the values of b and c, because they all refer to the same block. I am simply using different words to communicate the same idea, although with a different level of explicit detail. I also freely admit that I'm talking about a conceptual model which may or may not correspond exactly to the data structures that the REBOL interpreter builds in memory. However, I use the term "reference" because it makes more sense to me that one would have multiple pointers/handles/descriptors/whatever designating a single data structure than to assume that there are multiple copies of the same data embedded all over the place that have to be kept in synch. Whether it is the case that: a) you disapprove of my using the word "reference" in this manner, or b) you refuse to understand how I'm using it (despite my repeated attempts to explain -- in different words -- what I mean), or c) I am incapable of explaining coherently what I mean, or d) any arbitrary weighted average of the above three options, really no longer matters. What matters is that I simply acknowledge my failure to be able to communicate the idea of the example above in a way that you will accept. I can accept failures and mistakes; I've certainly made plenty of both. But what really saddens me is the idea of unrecoverable failure. In the following exchange: > > > >> A string cannot be a reference. > > > >I never said it could. > > Actually, you did. Perhaps you've changed your mind about that. > But here is the statement I was commenting on, as quoted from your > original email that everyone has access to: > ... > > You recall having said something quite different: your reaction is tantamount to accusing me of dishonesty (public dishonesty, judging from the phrase, "that everyone has access to"). You misunderstood my original statement, placed your own interpre- tations on my use of the concept of reference, thereby misconstruing the statement to mean something I did not intend, and then proceded (at considerable length!) to argue that the resulting statement was nonsense. When I tried to correct the misunderstanding by expressing the same idea in a slightly different way, you then accuse me of dishonesty and wasting your time. > > I wish you had said what now you claim to have said. It would have > saved me alot of work. Unfortunately you didn't. > I find this especially sad because, from the beginning of my reading of the REBOL mailing list, it has been clear to me that you are a very knowledgeable and experienced member of the REBOL community. I've learned quite a bit by considering questions/puzzles that you've posted, and from your more objective remarks on REBOL. You've been able to correct some mistaken assumptions of mine, including (most recently) one having to do with when local contexts are created. That information (specifically the code which allowed it to be demonstrated) was very helpful, and I thank you for it -- regardless of the overall tone of the posting which contained it. However, the increasingly personal tenor of your successive posts leave me little reason to think that I'll be able to explain my thoughts in a way that you will respect and consider objectively. Thank y
[REBOL] "logical" value referencing ... Re:(11)
[EMAIL PROTECTED] wrote: > > In C pointers and indexes are different ways > >to get at, peek into, observe, manipulate, or eavesdrop on, the > Nevertheless it would not be a good idea for a C programmer to > confuse an index with a pointer, nor would it be advisable for > someone, who wants to provide a conceptual theory of C, to confuse > pointers with indexes. > It would not be a good idea for a C programmer (or someone who wants to provide a conceptual theory of C) to remain ignorant of the fact that -- beneath the surface -- indexes and pointers are merely different means of dealing with the same underlying concept. "Rather more surprising, at least at first sight, is the fact that a reference to a[i] can also be written as *(a+i). In evaluating a[i], C converts it to *(a+i) immediately; the two forms are completely equivalent. Applying the operator & to both parts of this equivalence, it follows that &a[i] and a+i are also identical: a+i is the address of the i-th element beyond a. As the other side of this coin, if pa is a pointer, expressions may use it with a subscript: pa[i] is identical to *(pa+i). In short, any array and index expression can be written as a pointer and offset, and vice versa, even in the same statement." _The_C_Programming_Language_, B. Kernighan and D. Ritchie page 94 -jn-
[REBOL] learning to code... Re:
Hi -t, why not write a C or Java source code generator in REBOL? You'll have to learn what a Java or C source file looks like. Let's take C. Normally a C file is either a source code file, or a header file. A code file (typically filename.c) will begin by including some header files such as: stdio.h stdlib.h If you're programming is going to interact with sockets under Windows, it'll probably have to include winsock.h. Depending on what you are doing you may also include some other header files, like header files for database libraries, or, if you're programming under windows, you used to have to inlucde windows.h So, the begining of your source code file may look like this: #include #include #include #include Then you may define some constants, for instance #define MY_LOGIN_NAME "icimjs" #define MY_PASSWORD "" #define TRIES 10 #define FTP_OPORT 21 #define FTP_IPORT 22 and typedefs, such as #typedef char * NODE or something like that. Next you may declare variables and functions that will be globally accessable, or you may declare them static to ensure that they remain limited to the source file. To find out the details, grab a good book on C programming. I still think Kernighan/Ritchie's book on C Programming is the best introcutory around. Then you can build yourself REBOL objects that will generate the code and the different files you need for you. The point is that as you read through the book and try out the examples, you summarize in your mind the repeating patterns of header files and function declarations and so on, and you use that information to implement REBOL objects and functions that will take some arguments or set some words, which will the be used to generate file which contains the proper C code. While you think about how to structure your REBOL program you will be intesively dealing with the structure of C programs that is the data you are trying generate using REBOL. By the time you've got your REBOL C case tool completed, I bet you'll be quite some C expert and at the same time your efforts will pay you back by providing you with a tool that guarantees that a good portion of your code will be syntactically correct. Basically, REBOL becomes a tool, that use in order to think about C programs and with which test your own theories about how C programs, functions, constants, structures, and variables are declared and defined. You would be creating a REBOL dialect that allows to discuss C programs with REBOL and - if its well done - will allow you use REBOL as your assistant in creating C programs. Kind of a C programming metalanguage, or a compiler for your own language, whose target language is C. You can then look at specific programming tasks. What do linked lists look like in C. How can you create a REBOL function that generates C code that will declare and define the necessary data structures and supporting structures for generic linked list structure? Whenever you investigate a language for the purpose of creating a tool to support the language, you become for more intimate with the language your investigating, then when you're just trying to keep up with the curriculum. Elan At 03:03 AM 12/28/99 +0200, you wrote: >Hi guys, > >I've followd the "thanks" thread with intrest, because I'm in a similiar >boat to Petra's. Probably next semester I'll start with C or Java or >somthing. > >So Rebol won't ruin me for other languages, but instead help me >understand them? I'm already loyal to REBOL (its got a very high "cool" >rating). But I think I have to really dive in to it to learn it. I've >written two funcional scripts, but I'm out of stuff to do. > >any ideas about how I can creep up the learning curve? >-- > > >-t > > >
[REBOL] Series essay Re:(7)
Hi Jerry, I attempted to try your example, but I ran into a glitch: >> block: copy [] repeat i 4 [use [x] [x: i * i append block 'x]] == [x x x x] >> do x/1 ** Script Error: x has no value. ** Where: do x/1 Perhaps you meant: >> do block/1 If you did mean do block/1 and do block/2 etc. then I don't think you have found a bug. What you observe makes perfectly sense. When you say: do block/1 you are asking REBOL to evaluate that thing it finds at block/1. That thing is the word 'x. When x is evaluated, it retrieves the value it was bound to. In you repeat loop four contexts were created and in each context there exists a word 'x which is bound to a different value. When you say >> block/1 = block/2 you are asking whether whatever is found at position 1 of the block is equal to whatever is found at position 2 of the block. What is found at position 1 of the block is the word x, which is not being evaluated: >> block/1 == x What you find at position 2 of the block is also 'x before it is evaluated: >> block/2 == x So, what REBOL is saying that the unevaluated, literal word 'x is the same thing as an unevaluated, literal word 'x. Since 'x has not been evaluated, the 'x itself here is being treated as the value. If you say: >> same? block/1 block/2 == false REBOL returns false, because now REBOL is not only comparing the values 'x and 'x but it is also checking if these two 'x are identical. Compare to REBOL's behavior here: >> = [] [] == true >> same? [][] == false Hope this helps, Elan >> [: - )] you are asking whether the path block/1 references the same thing as the At 06:34 PM 12/28/99 -0500, you wrote: >Gabriele, > >I think, using your example, that I have found a bug in REBOL. >>> block: copy [] repeat i 4 [use [x] [x: i * i append block 'x]] >== [x x x x] >>> do x/1 >== 1 >>> do x/2 >== 4 >>> x/1 = x/2 >== true >>> x/1 == x/2 >== true >>> >What do you think? Is it a bug? > >Jerry > > >
[REBOL] Handy Timer Functions Re:(2)
Hi Jerry Yup, that works. But you could also nest timings with a simple change to tic3 and toc3. tic: func [] [insert [] now/time exit] toc: func [] [ print ["elapsed time:" now/time - first second second :tic] remove second second :tic exit ] >> tic tic wait 3 toc tic wait 5 toc tic wait 2 toc toc elapsed time: 0:00:03 elapsed time: 0:00:05 elapsed time: 0:00:02 elapsed time: 0:00:10 BTW you can see what's stored in tic with 'source: >> tic wait 2 tic >> source tic tic: func [][insert [18:01:45 18:01:43] now/time exit] Best Wishes Larry - Original Message - From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, December 28, 1999 4:45 PM Subject: [REBOL] Handy Timer Functions Re: > Larry, > I like your tic toc pair. However I sometimes wish to nest their use as in > the example: > >> tic tic wait 3 toc tic wait 5 toc tic wait 2 toc toc > 0:00:03 > 0:00:05 > 0:00:02 > 0:00:10 > >> > The program I used is > stack: copy [] > push: func [x][insert stack x exit] > pop: func [/local a] > [ >if (length? stack) = 0 [Print "can't pop empty stack" exit] >a: first stack remove stack a > ] > tic: func [][ push now/time exit] > toc: func [][print now/time - pop exit] > > What do you think? > > Jerry >
[REBOL] How to form a rule? Re:(3)
Hi Petr, I'm also interested in a good challenge - and I happen to be looking for an opportunity to practive parse rules. If you have the time, could you release (on or off list) a more detailed specification for what you are trying to do? If parse can't handle it well, I'd like to know that that is the case and what the limitation is in your case. TIA, Elan >> [: - )] At 11:23 PM 12/28/99 +0100, you wrote: > > >[EMAIL PROTECTED] wrote: > >> Hello [EMAIL PROTECTED]! >> >> On 27-Dic-99, you wrote: >> >> P> [thru "s" "om" skip " " "t" thru "t" " " "to" " " "p" skip >> P> skip "se"] >> >> What about: >> >> [thru "som" skip " t" thru " to p" 2 skip "se"] > >Well, it doesn't solve my situation actually. The search string user >enters can be something like "s?me", and you have to scan for the "s" >occurance, followed by the rest of the rule - skip "me" " " etc The >buil-rule function seems to work, seems to translate ? and * into right >(almost, need to think about t*t case :-) sequences. The problem is >really skip to "right" occurance of "s", to match the rule. I am now >thinking about using some "ordinary" iteration, which should use 'find, >to find "s", and then will try to apply the rule. I know the solution >with rule | skip was also suggested here, but I think it will slow >things a little bit > >Anyway, thanks for the help ... > >-pekr- > >> It shouldn't be a problem to build that. >> >> Regards, >> Gabriele. >> -- >> o) .-^-. (--o >> | Gabriele Santilli / /_/_\_\ \ Amiga Group Italia --- L'Aquila | >> | GIESSE on IRC \ \-\_/-/ / http://www.amyresource.it/AGI/ | >> o) `-v-' (--o > > >
[REBOL] Handy Timer Functions Re:
Hi Larry, first comment, I like your version 3 best: >tic3: func [] [toc3: func [] compose/deep [print ["elapsed time:" now/time - >(now/time)]]] This approach really makes good use of REBOL's abilities. While it looks trivial, I think that functions, which create functions, which in turn reflect some state at the time the "dynamic" function was created is an important technique for building smarter programs. In a different application the state embedded in the created function coould very well be more complicated and specific to the creating function then in your case. Imagine a whole chain of function-creating functions. Elan
[REBOL] "logical" value referencing ... Re:(2)
Hi Eric, I have a moment, so here is another piece of the puzzle. You wrote: > The > series used as the range argument must reference the same > series that's being searched. > >You'll see that a "series" is said to reference a "series" - not terribly >clear wording, but given that they haven't had time to fully consider Joel's >proposals I'd say it's a forgivable lapse. You appear to be unhappy with the wording. I have to agree with you in this case. Here the word series is not used in the sense of a datatype, it is used as a name for a specific value of that datatype. What is being confused is: >> series: [1 2 3 4] == [1 2 3 4] >> series? series == true A value of type series! is being referred to by the word 'series. Of course the word series is not the same thing as the datatype series: >> type? series! == datatype! >> series? series! == false En passant, when you nail down what the quote is saying, you find that it supports my position. My statement was that only words can be references. The quote happens to use the word 'series to refer to a value of type series! I'm curious what you think? Elan >> [: - )]
[REBOL] Series essay Re:(7)
Jerry, What is 'x supposed to be in your example? >> block: copy [] repeat i 4 [use [x] [x: i * i append block 'x]] == [x x x x] >> print block 1 4 9 16 >> do x/1 ** Script Error: x has no value. ** Where: do x/1 >> do x/2 ** Script Error: x has no value. ** Where: do x/2 I didn't have any global named 'x, nor did the initialization of 'block create one. Did you perhaps have one left over from some prior activity? -jn- Gerald Goertzel wrote: > > Gabriele, > > I think, using your example, that I have found a bug in REBOL. > >> block: copy [] repeat i 4 [use [x] [x: i * i append block 'x]] > == [x x x x] > >> do x/1 > == 1 > >> do x/2 > == 4 > >> x/1 = x/2 > == true > >> x/1 == x/2 > == true > >> > What do you think? Is it a bug? > > Jerry
[REBOL] Handy Timer Functions Re:
Larry, I like your tic toc pair. However I sometimes wish to nest their use as in the example: >> tic tic wait 3 toc tic wait 5 toc tic wait 2 toc toc 0:00:03 0:00:05 0:00:02 0:00:10 >> The program I used is stack: copy [] push: func [x][insert stack x exit] pop: func [/local a] [ if (length? stack) = 0 [Print "can't pop empty stack" exit] a: first stack remove stack a ] tic: func [][ push now/time exit] toc: func [][print now/time - pop exit] What do you think? Jerry
[REBOL] learning to code...
Hi guys, I've followd the "thanks" thread with intrest, because I'm in a similiar boat to Petra's. Probably next semester I'll start with C or Java or somthing. So Rebol won't ruin me for other languages, but instead help me understand them? I'm already loyal to REBOL (its got a very high "cool" rating). But I think I have to really dive in to it to learn it. I've written two funcional scripts, but I'm out of stuff to do. any ideas about how I can creep up the learning curve? -- -t
[REBOL] Series essay Re:(6)
Gabriele, I think, using your example, that I have found a bug in REBOL. >> block: copy [] repeat i 4 [use [x] [x: i * i append block 'x]] == [x x x x] >> do x/1 == 1 >> do x/2 == 4 >> x/1 = x/2 == true >> x/1 == x/2 == true >> What do you think? Is it a bug? Jerry
[REBOL] Handy Timer Functions
Hi all Below are some handy timer functions for REBOL. The idea of tic and toc comes from the MATLAB numeric package. One advantage of using a pair of functions is that they can be placed most anywhere in a piece of code without modifying it (as is sometimes necessary with the time-block approach. I provide three implementations which differ in how the initial time is stored. example usage: >> tic loop 100 [sine 30] toc elapsed time: 0:00:02 >> The first approach is plain vanilla; the initial time is stored in a global variable. To minimize name conflicts, I gave it an unusual name: __t__. (feel free to be creative with this name) tic1: func [] [__t__: now/time exit] toc1: func [] [print ["elapsed time:" now/time - __t__]] In the second approach, the initial time is stored in a literal block in the body of the tic function, and then retrieved by toc. tic2: func [] [change [] now/time exit] toc2: func [] [print ["elapsed time:" now/time - first second second :tic2]] In the third approach, the initial time is stored in the body of the toc function which is created by tic. tic3: func [] [toc3: func [] compose/deep [print ["elapsed time:" now/time - (now/time)]]] Just choose the one you like and rename to plain tic and toc. Comments welcome! Larry
[REBOL] How to form a rule? Re:(2)
[EMAIL PROTECTED] wrote: > Hello [EMAIL PROTECTED]! > > On 27-Dic-99, you wrote: > > P> [thru "s" "om" skip " " "t" thru "t" " " "to" " " "p" skip > P> skip "se"] > > What about: > > [thru "som" skip " t" thru " to p" 2 skip "se"] Well, it doesn't solve my situation actually. The search string user enters can be something like "s?me", and you have to scan for the "s" occurance, followed by the rest of the rule - skip "me" " " etc The buil-rule function seems to work, seems to translate ? and * into right (almost, need to think about t*t case :-) sequences. The problem is really skip to "right" occurance of "s", to match the rule. I am now thinking about using some "ordinary" iteration, which should use 'find, to find "s", and then will try to apply the rule. I know the solution with rule | skip was also suggested here, but I think it will slow things a little bit Anyway, thanks for the help ... -pekr- > It shouldn't be a problem to build that. > > Regards, > Gabriele. > -- > o) .-^-. (--o > | Gabriele Santilli / /_/_\_\ \ Amiga Group Italia --- L'Aquila | > | GIESSE on IRC \ \-\_/-/ / http://www.amyresource.it/AGI/ | > o) `-v-' (--o
[REBOL] ZIP and RAR archives with REBOL
Hi, is there any way how to go into ZIP and RAR archives with REBOL? I need to get archive structure at least (list of compressed files in the archive) thanx oLdes
[REBOL] finding an item's position Re:(3)
I may be totally naive, but what is "Shadowrun"? On 27-Dec-1999/2:37:47-6:00, [EMAIL PROTECTED] wrote: >Hello, >On 26-Dec-99, [EMAIL PROTECTED] wrote: > foo: [a b c d e] >> == [a b c d e] index? find foo 'b >> == 2 > >Short and sweet, thanks. Now to start figuring out how I want to make the >rest of the script work. >One part will be to let the user choose the order of the items. First I >need to start organizing whatever data I'll be working with. (FYI, it'll >be a Shadowrun character generator) > >Elliott > -- Bohdan "Bo" Lechnowsky REBOL Adventure Guide REBOL Technologies 707-467-8000 (http://www.rebol.com) Download the REBOL Messaging Language for all Platforms
[REBOL] Series essay Re:(6)
{{
Actually, nothing happens when entering or exiting the functions.
The binding is done when they are created. That is, make function!
creates a new context based on the spec, and then binds the body
block to that context.
}}
Which also neatly explains why local values are persistent. They are
(apparently) intialized to none when the block is made, and continue
through the session. It's only our prior knowledge of other languages
that lead us think locals might wax and wane whenever a function is
evaluated.
{{
Because 'c actually exists in the global context, and its value is
unset!. Look:
>> c
** Script Error: c has no value.
** Where: c
>> type? get/any 'c
== unset!
}}
Since this works as the first statement in a new session, I guess that,
theoretically, this would mean all words exist, but are initially
'unset.
-Ted.
[REBOL] "logical" value referencing ... Re:(2)
Hi Eric, you appear baffled by my use of the term "dereference". I hope the following quote will help. Note the sentence: "Is it important to clear large blocks of data before DEREFERENCING them?" > Quote Begins Here << From: [EMAIL PROTECTED] Hi Bo, Thank you very much for showing me your history list functions. I just have a couple of questions. One is that it seems REBOL automatically purges the history list of duplicates, so I didn't try to put that into mine. Was that necessary for an older version of REBOL? I notice that you do clear system/console/history system/console/history: history Is clearing the history important for releasing the memory that the list occupied? Is it important to clear large blocks of data before dereferencing them? One thing that I think would be very useful for a lot of functions, not just for a history-search function, would be the ability do something like this: userdata: ask/default "Prompt: " "Edit this string" The user would see: Prompt: Edit this string and would be able to edit the default string, just like you can edit a string selected from the history list with the up and down keys. Is there any way to do this with REBOL now? Thanks again, Eric Quote Ends Here << Hope this helps, Elan
[REBOL] Series essay Re:(7)
Don't know if you tried this, Joel, but here's a few more interesting lines to add to your example. >> a: 1 == 1 >> b: 2 == 2 >> e: [a b c] == [a b c] >> print e ** Script Error: c has no value. ** Where: c >> f: func [n /local c][c: n bind e 'c print e] >> f ** Script Error: f is missing its n argument. ** Where: f >> f 99 1 2 99 >> print e 1 2 99 >> bind e 'e == [a b c] >> print e ** Script Error: c has no value. ** Where: c ; (more) >> f 99 1 2 99 >> print e 1 2 99 ; 'c is restored to the 'e context >> c: 12 >> bind e 'e == [a b c] >> print e >> 1 2 12 ; 'e binds to 'c in the this context >> unset 'c >> print e ** Script Error: c has no value. ** Where: c ; no 'c in this context now >> f 99 1 2 99 >> print e 1 2 99 >> bind/copy e 'e == [a b c] >> print e 1 2 99 ; with the copy refinement, 'e binds to the 'c in the 'f local context. >>f 98 1 2 98 >>print e 1 2 98 ; and when the 'c in the the 'f local context changes, so does the 'c in the 'e local context >>a: 65 65 >>print e 65 2 98 ; and we are still bound to the orignal 'a So to retain a word set to a value in a local context, we can use the 'bind/copy refinement. At first, I was thinking we were copying the 'c from the 'f context. But I guess we're really copying the 'c from the 'e context. Bind is operating in the block outside of 'e and so 'c does not exist to it. But I guess the /copy refinement recreates the local 'c so that bind can use it. It doesn't seem to be a "copy" in the usual sense though, since it appears to be the same value first created in 'f. Just as a value can be shared between words, perhaps a word can be shared among contexts. -Ted.
[REBOL] Re: Series essay Re:(4)
Hello [EMAIL PROTECTED]!
On 27-Dic-99, you wrote:
j> Thanks for your descriptions! They've stimulated some
j> additional questions, given below. Might I trouble you for
j> some more ideas?
No trouble. :-) I'll try to provide you my own answers, even if
they could be wrong. :-)
j> You've persuaded me that one part of that concept does NOT
j> apply to REBOL -- that of searching a chain of environments,
j> from most-local to most-global, to find the appropriate
j> binding for a word.
Yes. Indeed, in the beginning I thought that a word had to mantain
a list of contexts, from the most "local" to the most "global",
but Ladislav (IIRC) showed me I was wrong. The magic is done by
bind, which sets the reference to the context in a word only if it
is present in that context.
j> It seems clear that context-juggling is implicitly performed
j> via entry and exit to the bodies of functions and 'use, as in:
Actually, nothing happens when entering or exiting the functions.
The binding is done when they are created. That is, make function!
creates a new context based on the spec, and then binds the body
block to that context.
j> 2) three words, whose names happen to share the same spelling.
Three different words. It's like having series with the same
sequence but a different position --- you have words with the same
spelling but different contexts.
j>>> same? 'c third e
j>== false
j> This WASN'T what I expected. It appears that the third element
j> of 'e is a different 'c from the one whose name I can type
j> into the console.
Not really surprising:
{{context! * *}} ; the global context
^ | `-> << ... >>
| `---> << ... >>
|
{{word! * *}} ; global 'c
|
`---> << #"c" >>
^
|
.---'
/
{{word! * *}} ; local 'c
|
|
v
{{context! * *}} ; the local context
| `> << 12 >>
`--> << c >>
Even if they referred to the same sequence of character, they
would refer to a different contexts. Actually, in your example
even the sequence of characters would have not been exactly
the same.
j> H. Within 'f (where we've bound 'c) the words 'a and 'b
j> would have evaluated globally. However, attempting to bind 'e
j> back to that context doesn't restore 'a and 'b (in e!) to
j> refer to the global 'a and 'b.
This is not a surprise too. Within f's context there's no 'a or
'b, so bind simply ignores them. Their binding is not changed;
keep in mind that you are not binding code, but single words ---
every word can have its own context. The following example should
not surprise you:
>> block: [x]
== [x]
>> x: 1
== 1
>> reduce block
== [1]
>> use [x] [x: 2 insert tail block 'x]
== []
>> use [x] [x: 3 insert tail block 'x]
== []
>> use [x] [x: 4 insert tail block 'x]
== []
>> block
== [x x x x]
>> reduce block
== [1 2 3 4]
See, four different x's.
j> But 'f is defined in the global context for which 'a -> 1, 'b
j> -> 2, and 'c is undefined. So, although it seems clear why
j> this last use of 'bind restored 'a and 'b (in 'e!) to their
j> global binding, it's not immediately obvious to me why 'c (in
j> 'e) got clobbered (when the 'bind in 'g didn't affect it).
Because 'c actually exists in the global context, and its value is
unset!. Look:
>> c
** Script Error: c has no value.
** Where: c
>> type? get/any 'c
== unset!
j>> So, every word simply mantains a reference to a context (and
j>> probably, for efficiency, directly to its value in that
j>> context --- this could be proven in the previous version of
j>> REBOL),
j> Fascinating! Could you provide a code speciment that
j> demonstrates?
REBOL <= 2.1 made possible to modify the first and the second
componets of objects, that is, the list of words and the list of
values of its context. Something like:
>> obj: make object! [a: 1 b: 2]
>> words: first obj
== [self a b]
>> values: second obj
== [
make object! [
a: 1
b: 2
] 1 2]
>> change next words 'c
== [b]
>> words
== [self c b]
>> print mold obj
make object! [
c: 1
b: 2
]
(This is no longer possible, for security; now first obj would
return a copy of the actual block.)
If we had an 'a bound to that context that evaluated to 1 before
the change, it would continue to evaluate to 1 after the change,
even if 'a no more exists in that context after the change.
Regards,
Gabriele.
--
o) .-^-. (--o
| Gabriele Santilli / /_/_\_\ \ Amiga Group Italia --- L'Aquila |
| GIESSE on IRC \ \-\_/-/ / http://www.amyresource.it/AGI/ |
o) `-v-' (--o
[REBOL] "logical" value referencing ... Re:(2)
Hi, sorry for disagreeing with you: not silly. Ladislav > > Hi Elan, > > I think you've got us all mystified. You said to Joel: > > >You also quote excerpts that demonstrate the use of the verb "to refer" in > >a context where something is being referred to. This class of quotes does > >not make any statement about WHAT IS DOING the referring. What use are > >quotes that demonstrate that values can be referred to, even though they > >are not words? I never claimed that values being referred to must be words. > >I said that only words are references, and only words can be dereferenced: > >>> help get > >Gets the value of a word. > >Arguments: > >word -- Word to get (any-word) > >Refinements: > >/any -- Allows any type of value, even unset. > > I can't for the life of me see how the help for GET says anything about the > technical meaning of the word of the term "refer" or "reference", given that > the word isn't used at all. Then when you go on to prove that string values > cannot refer by showing that strings cannot be used as an argument to GET, > my confusion is compounded many-fold. Where does it say that only words can > be dereferenced? I haven't even seen the term "dereference" in the > documentation. > > > Maybe this will help me understand what you're thinking. How do you explain > what happens here? > > >> string: "abcdefghij" > == "abcdefghij" > >> b: [] loop 5 [append b string string: next string] > == "fghij" > >> b > == ["abcdefghij" "bcdefghij" "cdefghij" "defghij" "efghij"] > >> unset 'string > >> remove first b > == "bcdefghij" > >> b > == ["bcdefghij" "cdefghij" "defghij" "efghij" "fghij"] > > > Here's an interesting use of the term "reference" from the > User's Guide 2.2.0 [DRAFT 2] (sersearch.html) > > >Search Constraints > >The /part refinement takes one argument, a range to search. >This can be a numeric range, or series. When a series is >used, find/part uses the count of elements between the >current index of the search series and the current index of >the series argument as the range to constrain to. The >series used as the range argument must reference the same >series that's being searched. > > You'll see that a "series" is said to reference a "series" - not terribly > clear wording, but given that they haven't had time to fully consider Joel's > proposals I'd say it's a forgivable lapse. > > The behavior described here may be illustrated as follows: > > >> a: "this is a string to be searched" > == "this is a string to be searched" > >> find a "string" > == "string to be searched" > >> find a "search" > == "searched" > >> find/part a "string" find a "search" > == "string to be searched" > >> find/part a "search" find a "string" > == none > > In the final statement here, > >find a "string" > > returns a reference to A which constrains the find/part to a portion of A > which doesn't include the substring "search" > > Here's another example, from sercopy.html: > >Copying Embedded Series With the /deep Refinement > >The /deep refinement forces copy to copy all series values >within a block. > >When copying series values in a block, the reference to the >series is copied, not the series itself. Modifications to >series in a copied block will modify the series in the copy. > > It implies quite clearly that references can exist within a block. > > BTW, you may have spotted Joel's solution to my puzzle, which I confess is a > silly variation of one of Ladislav's puzzles. > > See you, > Eric > > >
[REBOL] Series essay Re:(7)
Yes, that's what I tried to say. You're welcome. Ladislav - Pùvodní zpráva - Od: <[EMAIL PROTECTED]> Komu: <[EMAIL PROTECTED]> Odesláno: 28. prosince 1999 16:43 Pøedmìt: [REBOL] Series essay Re:(6) > [EMAIL PROTECTED] wrote: > > > > Hi, Joel, > > > > although not been asked, trying to answer some questions. > > > > 1) The model of binding Gabriele (not Gabrielle) > > [sigh...] It seems I am unable to type these days without making a > typo! [My apollogies, Gabriele!] > > > > > proposed was proposed as a > > hypothesis, that could explain the Rebol behaviour. Since then it has > > succeeded to explain every situation encountered and to make valid > > predictions, so it's validity is much less questionable than validity of any > > other binding model proposed. > > > > Gabriele's email to which I was responding certainly expressed some > ideas that were helpful to me. My questions were intended to help me > understand it better. I appreciate your assistance in that regard. > > So, let me do a sanity check by attempting to answer the questions I > raised, based on my understanding of what you and Gabriele have said. > > > > You've persuaded me that one part of that concept does NOT apply to > > > REBOL -- that of searching a chain of environments... > > There is no "chain of environments". Each word directly refers to its > own context. > > > > >> e > > > == [a b c] > > > >> print e > > > 1 2 12 > > > >> c > > > ** Script Error: c has no value. > > > ** Where: c > > > >> same? 'c third e > > > == false > > The 'c at the third element of 'e ['s value] had been bound to the > local context of a function (value of 'f), and was therefore a > different word from a global 'c (although spelled the same). > > > > >> h: func [][bind e third e print e] > > > >> h > > > 20 21 12 > > > > > > H. Within 'f (where we've bound 'c) the words 'a and 'b would > > > have evaluated globally. However, attempting to bind 'e back to > > > that context doesn't restore 'a and 'b (in e!) to refer to the > > > global 'a and 'b. > > Precisely because global 'a and 'b aren't in the context to which the > third element of 'e ['s value] is bound, and therefore aren't changed > by the 'bind within 'h ['s value]. > > > > >> bind e 'f > > > == [a b c] > > > >> print e > > > ** Script Error: c has no value. > > > ** Where: c > > > >> a > > > == 1 > > > >> print first e > > > a > > > >> print get first e > > > 1 > > The last one is the only one I'm still trying to understand. Running > the following (in a fresh REBOL console) highlights my question. > > >> a: 1 > == 1 > >> b: 2 > == 2 > >> e: [a b c] > == [a b c] > >> print e > ** Script Error: c has no value. > ** Where: c > >> f: func [n /local c][c: n bind e 'c print e] > >> f > ** Script Error: f is missing its n argument. > ** Where: f > >> f 99 > 1 2 99 > >> print e > 1 2 99 > >> bind e 'e > == [a b c] > >> print e > ** Script Error: c has no value. > ** Where: c > > What I think you've said is that the bind in f affects only the > third element of e because the other elements refer to words not > in the context used for the bind. c is bound, but a and b are > left alone. > > OTOH, the last bind above affects all of a, b, and c, because it > the target context is the global context. Therefore, a and b > get bound back to a context where they already have values, but > c gets bound to a context where it does NOT have a value. > > Did I interpret your description correctly? > > Thanks for your feedback (and patience) ! > > -jn- > > >
[REBOL] Re: How to form a rule?
Hello [EMAIL PROTECTED]! On 27-Dic-99, you wrote: P> [thru "s" "om" skip " " "t" thru "t" " " "to" " " "p" skip P> skip "se"] What about: [thru "som" skip " t" thru " to p" 2 skip "se"] It shouldn't be a problem to build that. Regards, Gabriele. -- o) .-^-. (--o | Gabriele Santilli / /_/_\_\ \ Amiga Group Italia --- L'Aquila | | GIESSE on IRC \ \-\_/-/ / http://www.amyresource.it/AGI/ | o) `-v-' (--o
[REBOL] Series essay Re:(6)
[EMAIL PROTECTED] wrote: > > Hi, Joel, > > although not been asked, trying to answer some questions. > > 1) The model of binding Gabriele (not Gabrielle) [sigh...] It seems I am unable to type these days without making a typo! [My apollogies, Gabriele!] > > proposed was proposed as a > hypothesis, that could explain the Rebol behaviour. Since then it has > succeeded to explain every situation encountered and to make valid > predictions, so it's validity is much less questionable than validity of any > other binding model proposed. > Gabriele's email to which I was responding certainly expressed some ideas that were helpful to me. My questions were intended to help me understand it better. I appreciate your assistance in that regard. So, let me do a sanity check by attempting to answer the questions I raised, based on my understanding of what you and Gabriele have said. > > You've persuaded me that one part of that concept does NOT apply to > > REBOL -- that of searching a chain of environments... There is no "chain of environments". Each word directly refers to its own context. > > >> e > > == [a b c] > > >> print e > > 1 2 12 > > >> c > > ** Script Error: c has no value. > > ** Where: c > > >> same? 'c third e > > == false The 'c at the third element of 'e ['s value] had been bound to the local context of a function (value of 'f), and was therefore a different word from a global 'c (although spelled the same). > > >> h: func [][bind e third e print e] > > >> h > > 20 21 12 > > > > H. Within 'f (where we've bound 'c) the words 'a and 'b would > > have evaluated globally. However, attempting to bind 'e back to > > that context doesn't restore 'a and 'b (in e!) to refer to the > > global 'a and 'b. Precisely because global 'a and 'b aren't in the context to which the third element of 'e ['s value] is bound, and therefore aren't changed by the 'bind within 'h ['s value]. > > >> bind e 'f > > == [a b c] > > >> print e > > ** Script Error: c has no value. > > ** Where: c > > >> a > > == 1 > > >> print first e > > a > > >> print get first e > > 1 The last one is the only one I'm still trying to understand. Running the following (in a fresh REBOL console) highlights my question. >> a: 1 == 1 >> b: 2 == 2 >> e: [a b c] == [a b c] >> print e ** Script Error: c has no value. ** Where: c >> f: func [n /local c][c: n bind e 'c print e] >> f ** Script Error: f is missing its n argument. ** Where: f >> f 99 1 2 99 >> print e 1 2 99 >> bind e 'e == [a b c] >> print e ** Script Error: c has no value. ** Where: c What I think you've said is that the bind in f affects only the third element of e because the other elements refer to words not in the context used for the bind. c is bound, but a and b are left alone. OTOH, the last bind above affects all of a, b, and c, because it the target context is the global context. Therefore, a and b get bound back to a context where they already have values, but c gets bound to a context where it does NOT have a value. Did I interpret your description correctly? Thanks for your feedback (and patience) ! -jn-
[REBOL] "logical" value referencing ... Re:
Hi Elan, I think you've got us all mystified. You said to Joel: >You also quote excerpts that demonstrate the use of the verb "to refer" in >a context where something is being referred to. This class of quotes does >not make any statement about WHAT IS DOING the referring. What use are >quotes that demonstrate that values can be referred to, even though they >are not words? I never claimed that values being referred to must be words. >I said that only words are references, and only words can be dereferenced: >>> help get >Gets the value of a word. >Arguments: >word -- Word to get (any-word) >Refinements: >/any -- Allows any type of value, even unset. I can't for the life of me see how the help for GET says anything about the technical meaning of the word of the term "refer" or "reference", given that the word isn't used at all. Then when you go on to prove that string values cannot refer by showing that strings cannot be used as an argument to GET, my confusion is compounded many-fold. Where does it say that only words can be dereferenced? I haven't even seen the term "dereference" in the documentation. Maybe this will help me understand what you're thinking. How do you explain what happens here? >> string: "abcdefghij" == "abcdefghij" >> b: [] loop 5 [append b string string: next string] == "fghij" >> b == ["abcdefghij" "bcdefghij" "cdefghij" "defghij" "efghij"] >> unset 'string >> remove first b == "bcdefghij" >> b == ["bcdefghij" "cdefghij" "defghij" "efghij" "fghij"] Here's an interesting use of the term "reference" from the User's Guide 2.2.0 [DRAFT 2] (sersearch.html) Search Constraints The /part refinement takes one argument, a range to search. This can be a numeric range, or series. When a series is used, find/part uses the count of elements between the current index of the search series and the current index of the series argument as the range to constrain to. The series used as the range argument must reference the same series that's being searched. You'll see that a "series" is said to reference a "series" - not terribly clear wording, but given that they haven't had time to fully consider Joel's proposals I'd say it's a forgivable lapse. The behavior described here may be illustrated as follows: >> a: "this is a string to be searched" == "this is a string to be searched" >> find a "string" == "string to be searched" >> find a "search" == "searched" >> find/part a "string" find a "search" == "string to be searched" >> find/part a "search" find a "string" == none In the final statement here, find a "string" returns a reference to A which constrains the find/part to a portion of A which doesn't include the substring "search" Here's another example, from sercopy.html: Copying Embedded Series With the /deep Refinement The /deep refinement forces copy to copy all series values within a block. When copying series values in a block, the reference to the series is copied, not the series itself. Modifications to series in a copied block will modify the series in the copy. It implies quite clearly that references can exist within a block. BTW, you may have spotted Joel's solution to my puzzle, which I confess is a silly variation of one of Ladislav's puzzles. See you, Eric
[REBOL] Thanks Re:(2)
Hi Petra, it is a bitter truth. Jobwise you will currently find more opportunities with Perl than with REBOL. You will also find far more competent competitors in the market. If I may wonder out loud: How many people on this list know of job openings that could be filled with someone who knows REBOL (no, I'm not looking for a job ;-). Frankly, Perl IMHO has a rather steep learning curve. By the time you master Perl, you may find that REBOL has become far more marketable. You could always easily build a Perl generating engine in REBOL and let REBOL do your Perl work for you ;-). To remain realistic, at this point in time I'd have a very bad conscience, if I were to recommend that anyone pursue REBOL as a career decision. If you can control which scripting or programming language you want to use, if you would rather learn a superior scripting/programming language, if this is going to be your first programming language, if you are willing to take a gamble (careerwise that is), then definitely go with REBOL. I don't have any empirical material to support this last claim, but I'm willing to bet that you will probably find it much easier to learn Perl, once you've mastered REBOL. REBOL will teach you how to program (provided this is your first programming language) and it's much easier to figure out other programming languages once you've mastered your first one. And Perl certainly can't beat REBOL as an introductory language. You may find that the time you spend learning REBOL will significantly reduce the time it takes you to learn Perl. Enough of being reasonable. Learn REBOL and apply for a job with REBOL Tech ;-). Now that's a career decision. Elan
[REBOL] Series essay Re:(5)
Hi, Joel,
although not been asked, trying to answer some questions.
1) The model of binding Gabriele (not Gabrielle) proposed was proposed as a
hypothesis, that could explain the Rebol behaviour. Since then it has
succeeded to explain every situation encountered and to make valid
predictions, so it's validity is much less questionable than validity of any
other binding model proposed.
2) When you use a code like:
a: 1
b: 'a
use [a] [print 'a = b print same? 'a b]
you get:
true
false
which really means that the words you are comparing are somehow equal and
somehow different.
The model:
Every word (e.g. 'a) is an entity that has at least attributes:
text-representation (e.g. "a")
binding (e.g. the global context)
>From the model point of view the words are considered equal as long as their
text-representations are equal. The words compared above are considered
equal, but are not the same, because their binding attributes differ.
3) About the difference between the global context and any other context:
Any word can be bound to the global context. (In other words: the global
context is enlarge-able.) That is why the 'c being bound to the global
context looks "clobbered".
As to the local contexts:
The local contexts created with a help of the Use function (or a similar
mechanism) are limited in the following sense: Bind Word Local-Context-Word
doesn't change the Word's binding, if it doesn't encounter the Word's
equivalent in the Local-Context. That is why within F 'a and 'b don't change
their binding - the 'a and 'b words are not in the F's local context.
Ladislav
- Pùvodní zpráva -
Od: <[EMAIL PROTECTED]>
Komu: <[EMAIL PROTECTED]>
Odesláno: 27. prosince 1999 20:15
Pøedmìt: [REBOL] Series essay Re:(4)
> Gabrielle,
>
> Thanks for your descriptions! They've stimulated some additional
> questions, given below. Might I trouble you for some more ideas?
>
> [EMAIL PROTECTED] wrote:
> >
> > My model for binding/contexts is the following:
> >
> > {{context! * *}}
> > ^ | `-> <<... 1 ...>> ; values (simplified
notation)
> > \|
> >\ `---> <<... a ...>> ; words (simplified notation)
> > \
> > \
> > {{word! * *}}
> > |
> > V
> > << #"a" >>
> >
> ...
> >
> > >> obj: make object! [
> > [a: 1
> > [b: 2
> > []
> > >> first obj
> > == [self a b]
> > >> second obj
> > == [
> > make object! [
> > a: 1
> > b: 2
> > ] 1 2]
> >
>
> >From other languages, I had a concept of "environment" -- basically
> a dictionary ("a-list" in LISP, "hash" in Perl, etc.) which supported
> looking up a variable/word/token and obtaining the corresponding
> value. That much seems compatible with the model you provided.
>
> You've persuaded me that one part of that concept does NOT apply to
> REBOL -- that of searching a chain of environments, from most-local
> to most-global, to find the appropriate binding for a word. While
> that notion works well for pure lexical scoping and pure dynamic
> scoping, I don't see how it effectively supports REBOL's
> word-at-a-time capability accessed via 'bind.
>
> It seems clear that context-juggling is implicitly performed via
> entry and exit to the bodies of functions and 'use, as in:
>
> >> a: "global a"
> == "global a"
> >> f: func [][print a]
> >> g: func [/local a][a: "g's local a" print a f print a]
> >> h: func [][use [a][a: "h's local a" print a g print a]]
> >> h
> h's local a
> g's local a
> global a
> g's local a
> h's local a
> >>
>
> I'm not clear on whether it's better to think of the above as
>
> 1) a single word 'a whose context is being magically managed by
> the interpreter, or
>
> 2) three words, whose names happen to share the same spelling.
>
> To display my ignorance (and confusion) on this point, consider this
> console transcript:
>
> >> a: 1
> == 1
> >> b: 2
> == 2
> >> e: [a b c]
> == [a b c]
> >> reduce e
> ** Script Error: c has no value.
> ** Where: c
>
> That was expected, as I had not defined 'c previously.
>
> >> f: func [n /local c] [c: n bind e 'c print e]
> >> f 12
> 1 2 12
>
> So far, still expected, as 'f supplies a context for 'c to be
> evaluated in.
>
> >> e
> == [a b c]
> >> print e
> 1 2 12
> >> c
> ** Script Error: c has no value.
> ** Where: c
> >> same? 'c third e
> == false
>
> This WASN'T what I expected. It appears that the third element of
> 'e is a different 'c from the one whose name I can type into
> the console.
>
> >> g: func [m /local a b] [bind e 'a a: m b: m + 1 print e]
> >> g 20
> 20 21 12
> >> e
> == [a b c]
> >> print e
> 20 21 12
>
> No surprise here.
>
> >> h: func [][bind e third e print e]
> >> h
> 20 21 12
>
> H. Within 'f (where we've bound 'c) the words 'a and 'b would
> have evaluated glo
