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

Core 2.5.5 Beta Versions

 [1/43] from: carl::s::rebol::com at: 19-Feb-2003 14:50


Prerelease versions of REBOL/Core 2.5.5 can be found at http://www.reboltech.com/downloads/ (core2505xxx.rcb -- see about-rcb.html for download info). This release is a minor update to bring Core versions in-sync with the new Mac OS X version as well as the REBOL/SDK kernels. Current platforms are Win, OSX, and Linux (libc6). More to be added once initial beta testing has succeeded. Watch for an announcement of 2.5.5 and change documentation on our web site in the next few days. -Carl Sassenrath REBOL Technologies

 [2/43] from: lmecir:mbox:vol:cz at: 20-Feb-2003 13:29


Another road to hell:
>> a: "0123456789"
== "0123456789"
>> b: tail a
== ""
>> remove back tail a
== ""
>> pick b -5
== #"4"
>> append a #"9"
== "0123456789"
>> pick b -5
== #"5" Cheers -L

 [3/43] from: lmecir:mbox:vol:cz at: 20-Feb-2003 13:23


Hi, had a look at the
>> rebol/version
== 2.5.5.3.1 The following behaviour
>> set/any 'c get/any 'b
== ** Script Error: Out of range or past end Looks like a disaster to me. Yet another class of "illegal" values! This is a road to hell.

 [4/43] from: joel:neely:fedex at: 20-Feb-2003 7:22


Hi, Ladislav, What did INDEX? have to say during all of that? -jn- Ladislav Mecir wrote:

 [5/43] from: g:santilli:tiscalinet:it at: 20-Feb-2003 14:26


Hi Ladislav, On Thursday, February 20, 2003, 1:23:23 PM, you wrote:
>>> set/any 'c get/any 'b
LM> == ** Script Error: Out of range or past end That happens during the MOLD; the SET/GET part is not the problem and should be behaving correctly. Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amigan -- AGI L'Aquila -- REB: http://web.tiscali.it/rebol/index.r

 [6/43] from: lmecir:mbox:vol:cz at: 20-Feb-2003 14:53


Hi, in the Core 2.5.5 it looks, like series have a volatile position attribute, which may change, when we append a value:
>> a: "1"
== "1"
>> b: tail a
== ""
>> index? b
== 2
>> append a #"1"
== "11"
>> index? b
== 2 very unfortunate Regards -L

 [7/43] from: lmecir:mbox:vol:cz at: 20-Feb-2003 15:23


Hi Joel,
> What did INDEX? have to say during all of that?
here you are:
>> a: "1"
== "1"
>> b: tail a
== ""
>> index? b
== 2
>> remove a
== ""
>> index? b
== 1
>> insert tail a #"1"
== ""
>> index? b
== 2 It can be interpreted as follows: {it looks, like series have a volatile position attribute, which may change, if you append a value to the series} Regards -L

 [8/43] from: petr:krenzelok:trz:cz at: 20-Feb-2003 15:36


Ladislav Mecir wrote:
>Hi, had a look at the >>>rebol/version
<<quoted lines omitted: 7>>
>== ** Script Error: Out of range or past end >Looks like a disaster to me. Yet another class of "illegal" values! This is a road to hell.
It works here .... Even Cyphre tried it with new core and it works for him .... works = does nothing at console - no error message ... strange you are observing error then? -pekr-

 [9/43] from: joel:neely:fedex at: 20-Feb-2003 8:28


Hi, Gabriele, Gabriele Santilli wrote:
> That happens during the MOLD; the SET/GET part is not the problem > and should be behaving correctly. >
Can you help me understand why it didn't happen here? This is a transcript from a fresh REBOL process... 8<-------------- REBOL/Core 2.5.0.3.1 Copyright 1997-2001 REBOL Technologies REBOL is a Trademark of REBOL Technologies All rights reserved. Component: "Internet Protocols" (22-Mar-2001/17:38:17) Finger protocol loaded Whois protocol loaded Daytime protocol loaded SMTP protocol loaded POP protocol loaded IMAP protocol loaded HTTP protocol loaded FTP protocol loaded NNTP protocol loaded Script: "User Preferences" (8-Feb-2003/9:01:11-6:00)
>> rebol/version
== 2.5.0.3.1
>> set/any 'c get/any 'b >> value? 'c
== false

 [10/43] from: lmecir:mbox:vol:cz at: 20-Feb-2003 16:54


Hi all, I prepared my own REAL-INDEX?, ANY-SKIP and PEEK functions. The behaviour is as follows:
>> rebol/version
== 2.5.5.3.1
>> a: []
== []
>> series? b: any-skip a 6
== true
>> index? b
== 1
>> real-index? b
== 7
>> insert a [1 2 3 4 5 6]
== []
>> index? b
== 7
>> real-index? b
== 7
>> pick b -4
== 3
>> peek b -4
== 3
>> remove back tail a
== []
>> peek b -4
== 3
>> pick b -4
== 2
>> index? b
== 6
>> real-index? b
== 7
>> pick b -6
== none
>> peek b -6
== 1
>> pick b -7
== none
>> peek b -7
** User Error: Out of range ** Near: peek b -7 I may be dense, but what is wrong with my functions? Ladislav

 [11/43] from: rotenca:telvia:it at: 20-Feb-2003 15:43


index is returning a good value (> length?), but for a clear series arise some problems: b: tail a: "a" clear a
>> index? b
== 1
>> index? b
== 1
>> length? a
== 0
>> length? b
== 0
>> a
== ""
>> b
== ** Script Error: Out of range or past end ** Near: lenght? b A bug:
>> b: tail a: "a" clear a ;== ""
== ""
>> insert b #"1" ;
== ** Script Error: Out of range or past end
>> a
== "^@" --- Ciao Romano

 [12/43] from: lmecir:mbox:vol:cz at: 20-Feb-2003 17:13


Hi Joel and Pekr.
> It works here .... Even Cyphre tried it with new core and it works for > him .... works = does nothing at console - no error message ... strange > you are observing error then?
That was my mistake. As I said: my head was too hot to handle it correctly. The whole code was as follows: a: "1" b: tail a clear a set/any 'c get/any 'b If I used a code like: set/any 'c get/any 'b , nothing unexpected would have happened Sorry for misleading all. Regards -L

 [13/43] from: cyphre:seznam:cz at: 20-Feb-2003 17:11


Hi Ladislav, Joel, Petr and all this is my test under the nev core2.5.5 - running on WindowsXP Proffesional Version 2002 --------------------------snip---------------------------------------- REBOL/Core 2.5.5.3.1 Copyright 1997-2003 REBOL Technologies REBOL is a Trademark of REBOL Technologies All rights reserved. Component: "REBOL Mezzanine Extensions" 1.1.2.1 (29-Nov-2002/18:29:09) Component: "REBOL Internet Protocols" 1.59.2.15 (14-Feb-2003/0:45:14) Finger protocol loaded Whois protocol loaded Daytime protocol loaded SMTP protocol loaded POP protocol loaded IMAP protocol loaded HTTP protocol loaded FTP protocol loaded NNTP protocol loaded Component: "System Port" 1.1.2.5 (30-Nov-2002/16:24:03) Script: "User Preferences" (18-Sep-2002/11:07:50+2:00)
>> set/any 'c get/any 'b >> value? 'c
== false
>>
--------------------------snip---------------------------------------- regards, Cyphre

 [14/43] from: g:santilli:tiscalinet:it at: 20-Feb-2003 17:44


Hi Joel, On Thursday, February 20, 2003, 3:28:51 PM, you wrote: JN> Can you help me understand why it didn't happen here? This is a JN> transcript from a fresh REBOL process... I think that Ladislav's 'b was referring to an out-of-ranges series, i.e. as in: a: [1 2 3] b: tail a clear a Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amigan -- AGI L'Aquila -- REB: http://web.tiscali.it/rebol/index.r

 [15/43] from: g:santilli:tiscalinet:it at: 20-Feb-2003 17:43


Hi Ladislav, On Thursday, February 20, 2003, 4:54:42 PM, you wrote:
>>> real-index? b
LM> == 7 I would agree in principle, but what should LENGTH? return then?
>>> peek b -7
LM> ** User Error: Out of range LM> ** Near: peek b -7 Personally I prefer it returning NONE, but probably it's just a matter of taste. Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amigan -- AGI L'Aquila -- REB: http://web.tiscali.it/rebol/index.r

 [16/43] from: lmecir:mbox:vol:cz at: 20-Feb-2003 18:51


Hi Gabriele,
> >>> real-index? b > LM> == 7 > > I would agree in principle, but what should LENGTH? return then?
It should return either: index? tail :b - real-index? :b , or max 0 index? tail :b - real-index? :b Both are acceptable for me. This is a different story, than INDEX? manipulation.
> >>> peek b -7 > LM> ** User Error: Out of range > LM> ** Near: peek b -7 > > Personally I prefer it returning NONE, but probably it's just a > matter of taste.
If there were a possibility like: peek/default b -7 [none] ; == none it might have the advantages of both. Ciao -L

 [17/43] from: andreas:bolka:gmx at: 20-Feb-2003 18:13


Thursday, February 20, 2003, 12:29:09 PM, Ladislav wrote:
> Another road to hell: >>> a: "0123456789"
<<quoted lines omitted: 9>>
>>> pick b -5 > == #"5"
Thursday, February 20, 2003, 1:53:51 PM, Ladislav wrote:
> in the Core 2.5.5 it looks, like series have a volatile position > attribute, which may change, when we append a value:
i am wondering: this is nothing 2.5.5 specific, is it? -- Best regards, Andreas mailto:[andreas--bolka--gmx--net]

 [18/43] from: lmecir:mbox:vol:cz at: 20-Feb-2003 21:07


Hi Andreas,
> > in the Core 2.5.5 it looks, like series have a volatile position > > attribute, which may change, when we append a value: > > i am wondering: this is nothing 2.5.5 specific, is it?
As far as I know, it is 2.5.5 specific. Regards -L

 [19/43] from: andreas:bolka:gmx at: 20-Feb-2003 21:56


Thursday, February 20, 2003, 8:07:37 PM, Ladislav wrote:
>> > in the Core 2.5.5 it looks, like series have a volatile position >> > attribute, which may change, when we append a value: >> >> i am wondering: this is nothing 2.5.5 specific, is it? > As far as I know, it is 2.5.5 specific.
You sure?
>> rebol/version
== 2.5.0.3.1
>> >> a: "1"
== "1"
>> b: tail a
== ""
>> index? b
== 2
>> append a #"1"
== "11"
>> index? b
== 2
>> >> a: "1"
== "1"
>> b: tail a
== ""
>> clear a
== ""
>> set/any 'c get/any 'b
== ** Script Error: Out of range or past end the same results in core 2.5.0, 2.5.1, 2.5.2, 2.5.3, 2.5.4 and 2.5.5 as well as in view 1.2.1 and 1.2.8 (all win32). either i don't get something or this behaviour has been around for at least a while. -- Best regards, Andreas mailto:[andreas--bolka--gmx--net]

 [20/43] from: lmecir:mbox:vol:cz at: 21-Feb-2003 7:44


Hi Andreas,
> >> set/any 'c get/any 'b > == ** Script Error: Out of range or past end
This was my mistake, as I have said. The following is 2.5.5 specific:
>> a: "1"
== "1"
>> b: tail a
== ""
>> index? b
== 2
>> remove a
== ""
>> index? b
== 1
>> insert tail a #"1"
== ""
>> index? b
== 2
>> a: "0123456789"
== "0123456789"
>> b: tail a
== ""
>> remove back tail a
== ""
>> pick b -5
== #"4"
>> append a #"9"
== "0123456789"
>> pick b -5
== #"5 Regards -L

 [21/43] from: g:santilli:tiscalinet:it at: 21-Feb-2003 10:59


Hi Ladislav, On Thursday, February 20, 2003, 6:51:16 PM, you wrote: LM> It should return either: LM> index? tail :b - real-index? :b The problem I see is that this would break the intuitive rule that INDEX? is between 1 and LENGTH?. I.e. it would need to be clearly documented and newbies would need to be pointed out that INDEX? can in some occasions be out of range, with examples. Otherwise we would just be getting much more bugs than it could solve. (Anyway, the proposal I and Romano sent to feedback asked for a different solution to the problem; I still think it would be better.) Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amigan -- AGI L'Aquila -- REB: http://web.tiscali.it/rebol/index.r

 [22/43] from: rotenca:telvia:it at: 21-Feb-2003 16:01


Hi all,
>> a: "1"
== "1"
>> b: tail a
== ""
>> index? b
== 2
>> remove a
== ""
>> index? b
== 1
>> insert tail a #"1"
== ""
>> index? b
== 2
>> a: "0123456789"
== "0123456789"
>> b: tail a
== ""
>> remove back tail a
== ""
>> pick b -5
== #"4"
>> append a #"9"
== "0123456789"
>> pick b -5
== #"5 It don't see an easy solution for this problem. When one remove a series value, the interpreter should check if any other relative series is now out-of-range and correct the index value to make it equal to the new tail, but this is a time consuming task. How to resolve this situation of confusion between out-of-range series and tail series? For any out-of-range series: 1) correct the index of all relative series (too slow) 2) index? returns x + index? tail 3) index? returns unset! or none!, mold/trace/? should work with these series 4) index? returns error! (like in the previous version), but mold/trace/? should work with these series What do you think? --- Ciao Romano

 [23/43] from: joel:neely:fedex at: 21-Feb-2003 16:41


Hi, Romano, Romano Paolo Tenca wrote:
> It don't see an easy solution for this problem. >
We could make it easier if we tackle a larger problem! (see below ;-)
> When one remove a series value, the interpreter should check if > any other relative series is now out-of-range and correct the > index value to make it equal to the new tail, but this is a time > consuming task. >
I don't agree that it "should", but do agree that it is infeasible (especially with the insertion of the word "too", which you did a few sentences later ;-). But there's a bigger issue anyway. We have multiple cases of REBOL expressions that we'd think would mean/do the same thing, but which do not. For example, let's set up with this:
>> a: "abcdefg" == "abcdefg" >> b: back tail a == "g"
<<quoted lines omitted: 3>>
>> pick at a index? b 1 == #"g" >> pick at a c 1 == #"g"
Note that the last four expressions yield identical values. Now let's start down the slippery slope:
>> clear at a 5
== ""
>> a
== "abcd" and find that (with 1.2.1.3.1) lots of things break...
>> length? b
** Script Error: Out of range or past end ** Where: halt-view ** Near: length? b
>> index? b
** Script Error: Out of range or past end ** Where: halt-view ** Near: index? b
>> first at a index? b
** Script Error: Out of range or past end ** Where: halt-view ** Near: first at a index? b
>> pick at a index? b 1
** Script Error: Out of range or past end ** Where: halt-view ** Near: pick at a index? b but note this contrast!!!
>> first at a c
** Script Error: Out of range or past end ** Where: halt-view ** Near: first at a c
>> pick at a c 1
== none Why should PICK _ 1 behave differently than FIRST _ in any situation?
> How to resolve this situation of confusion between out-of-range > series and tail series? >
I suggest that the following behavior for series values is simple, and also makes sense (not always the same! ;-) - INDEX? should *always* return the "position" of the series, regardless of the number of values in the underlying sequence. - Content access (whether directly via that series ref, or using AT , SKIP , BACK , NEXT , etc. relative to current position) should *always* return NONE if the reference (or relative position after adjustment) is out-of-bounds, or should *always* return actual data if the reference (or relative position after adjustment) is within bounds. In this view, given something like this: a: "ABCDEFGHI" b: at a 5 ; i.e., assuming a is at head index arithmetic such as index? b ; ==> should be 5 index? back back b ; ==> should be 3 would always evaulate consistently, even if something like clear next a intervened. Additionally, the role of NONE would become more standardized, so that (just as SELECT and FIND simply return NONE to indicate that the requested value is unavailable) the previous five expressions would leave us in a state where first b would simply evaluate to NONE instead of throwing an error, in much the same way that
>> pick "?" 3
== none behaves nicely (and, as we all know, the apparently equivalent
>> third "?"
** Script Error: Out of range or past end ** Where: halt-view ** Near: third "?" does not!) Any thoughts on that? -jn- -- ---------------------------------------------------------------------- Joel Neely joelDOTneelyATfedexDOTcom 901-263-4446 Counting lines of code is to software development as counting bricks is to urban development.

 [24/43] from: antonr:iinet:au at: 22-Feb-2003 14:40


I agree with Joel, though there might be some reasons for the way things are that we're missing. Anton.

 [25/43] from: rotenca:telvia:it at: 22-Feb-2003 15:08


Hi, all these are the results of my tests under Core 2.5.5.3.1 b: tail a: "a" clear a These expressions return an error: mold b probe b ? b ?? b help b poke b 1 #"a" first b ;... last b same? b b equal? b b ;... These expressions CRASH the interpreter: copy b find b 1 select b 1 replace b #"a" #"b" uppercase b lowercase b Detab has this effect mold/all b ;== {#[string! "" 2]} mold/all detab b ;== {#[string! "^^@" 2]} Change has this effect mold/all change b #"a" ;== {#[string! "^^@a" 3]} mold/all b ;== {#[string! "^^@a" 2]} --- Ciao Romano

 [26/43] from: lmecir:mbox:vol:cz at: 23-Feb-2003 19:48


Hi all, I would like to welcome Elan too. <Gabriele wrote:>
> (Anyway, the proposal I and Romano sent to feedback asked > for a different solution to the problem; I still think it would be > better.)
I don't know your proposal, but I suspect, that its feasibility was questionable (for the current interpreter implementation). <Joel wrote:>
> > How to resolve this situation of confusion between out-of-range > > series and tail series?
<<quoted lines omitted: 3>>
> - INDEX? should *always* return the "position" of the series, > regardless of the number of values in the underlying sequence.
Count my vote for this too. I call it a REAL-INDEX? as opposed to any adjusted indices. My reasons for it are: 1) Compatibility: this behaviour is the most compatible, because if we had such a function, it would be easy to define an PRE-255-INDEX? as follows: PRE-255-INDEX?: func [ [catch] s [series!] ] [ either real-index? :s <= (real-index? tail :s) [ real-index? :s ] [ throw make error! "Out of range" ] ] as well as INDEX?-255 INDEX?-255: func [ [catch] s [series!] ] [ either real-index? :s <= (real-index? tail :s) [ real-index? :s ] [ throw make error! "Out of range" ] ] , while neither of these can be used alone to define REAL-INDEX?. 2) Symmetry: REAL-INDEX? is much more symmetrical, than any other implementation proposed (its behaviour doesn't depend on some factors, that are essential for other proposed indices).

 [27/43] from: lmecir:mbox:vol:cz at: 24-Feb-2003 13:02


Hi Gabriele, you wrote:
> LM> I don't know your proposal, but I suspect, that its feasibility was > LM> questionable (for the current interpreter implementation).
<<quoted lines omitted: 8>>
> insert a "12345" > index? b ; == 1
it is as I guessed. The functionality you suggested is not compatible with the current implementation. The series index attribute isn't implemented as volatile, therefore the INDEX? function isn't able to change B (even if implemented natively). Your proposed behaviour would require a change of the series implementation.
> (as out-of-range > series are not useful, so I don't need that concept in the > language)
1) Out-of-range series are products of the current implementation and there is no way, how we can get rid of them without changing the implementation. 2) The current implementation of series allows the implementor to define three natives INT-INDEX? INT-PICK and INT-SKIP with the following properties: a) for any series S holds, that int-index? :s yields identical result as insert tail :s #"1" int-index? :s (This is a definition of the INT-INDEX? function.) b) for any series S and any integer I holds, that int-index? int-skip :s i always yields identical result as (int-index? :s) + i (This is a definition of the INT-SKIP function.) c) for any series S and any integer I holds, that int-pick :s i yields identical result as int-pick int-skip head :s (int-index? :s) + i - 1 (This is a main property of the INT-PICK function.) Moreover, I propose, that the INT-PICK function should fire an error for the "out of range" references, i.e. for such situations, where: any [ ((int-index? :s) + i - 1) > (length? head :s) ((int-index? :s) + i - 1) < 1 ] yields TRUE. 3) Compatibility: with a help of the above natives it is easy to define mezzanines like: INDEX?-PRE255, INDEX?-255, SKIP-PRE255, SKIP-255, PICK-PRE255, PICK-255, LENGTH?-PRE255, LENGTH?-255 etc. 4) Usefulness: a) see sub 3), with a help of the three proposed natives we can implement many different "index models". b) Some "index models" don't need any new mezzanines at all. E.g. a zero-based indexing: a: "123456789" a0: int-skip a 1 int-pick a0 0 ; == #"1" Or a 3-based indexing: a3: int-skip a 1 - 3 int-pick a3 3 ; == #"1" 5) Advantages: a) We will get rid of "second class/unuseful/strange" series, the previously "out of range" series will become I-based series for some I. b) We will have a flexible indexing system. c) No series reimplementation necessary. d) This indexing system will be simpler. e) This indexing system will be faster. 6) Disadvantages: we need three new natives.

 [28/43] from: joel:neely:fedex at: 24-Feb-2003 5:44


Hi, Gabriele, A slightly different POV... Gabriele Santilli wrote:
> On the contrary, I think it would be very easy to implement. > I just think the interpreter should reset out-of-range series > values to the series tail when they are evaluated. >
Horrors! 8-0 I think we'd be much better served by having INDEX? simply tell us the index of a series under all circumstances (whether in range or not). A script could then easily determine in advance whether a series ref was "safe" to use or not, without having an error thrown. In this approach, your hypothetical example would appear as...
> a: "12345" > b: skip a 2 > clear a ; nothing happens to b here > index? b ; == 3 (KEEPS its position attribute)
...at which point one could evaluate index? b > length? head b ; == true ... to see that it isn't currently "safe" to access via b, then ...
> insert a "12345" > index? b ; == 3 (STILL at the same position) >
...at which point b ; == "345" (at same position over new data)
> This way it would be like if out-of-range series did not > exist at all; I think it would be much less confusing > (as out-of-range series are not useful, so I don't need > that concept in the language). >
If the interpreter handled every attempt to access an undefined word by changing the word reference to some other (defined) word in SYSTEM/WORDS, then we'd never get errors caused by UNSET! either. I think unset words are not useful, so i don't need that concept in the language. ;-) Seriously, I *strongly* dislike having the language change things behind our backs, instead of just giving us a straightforward way to look at the actual situation and make our own decisions. In the following transcript:
>> a: "1234567" ; == "1234567" >> b: at a 4 ; == "4567" >> clear at a 3 ; == "" >> a ; == "12" >> append a "CDEFG" ; == "12CDEFG" >> b ; == "DEFG"
the position of B is *temporarily* out of bounds while the string in A is being massaged. At the completion of that massaging, however, B now provides access to what is at the corresponding position in the new data. That seems useful to me. To illustrate... Suppose I have a source of data providing fixed-format lines (or groups of lines) sepearated by empty/blank lines: HOST TIME STAT USERS CPU 197.168.0.1 23:45:00 Up 13 27% 197.168.100.23 23:45:01 Up 5 11% 197.168.101.2 23:45:01 Down 0 0% 197.168.0.1 23:50:00 Up 15 45% 197.168.100.23 23:50:01 Up 7 23% 197.168.101.2 23:50:01 Up 4 70% ... and so on. Now imagine the behavior of the following fragment if we were allowed to examine INDEX? as I recommend: a: first-log-line b: find a "STAT" forever [ a: next-log-line if length? a >= index? b [ print b ] ] We'd get output containing (well, beginning with -- adding the code to break off at the first blank or end of string would have bulked up the example) the STATus field for every line coming from the data source. B is keeping up with which part of A we need to look at (for every A that has that much data). I'm certainly not saying that this is the only (or even best) way to write this little fragment, but just trying to illustrate that knowing where you were in a series (or being able to look at that same place again) is a useful concept, regardless of how the data in the series may change. -jn-

 [29/43] from: lmecir:mbox:vol:cz at: 24-Feb-2003 13:13


Hi all, Gabriele wrote: ...
> I > just think the interpreter should reset out-of-range series values
<<quoted lines omitted: 10>>
> series are not useful, so I don't need that concept in the > language).
I forgot to ask: What did you propose for the following situation? a: "12345" b: skip a 2 c: b clear a ; nothing happens to b here index? b ; == 1 (b is reset to tail b as soon as it is evaluated) insert a "12345" index? b ; == 1 index? c ; == ? Ciao -L

 [30/43] from: rotenca:telvia:it at: 24-Feb-2003 13:18


Hi,
> a: "12345" > b: skip a 2 > clear a ; nothing happens to b here > index? b ; == 1 (b is reset to tail b as soon as it is evaluated) > insert a "12345" > index? b ; == 1
Instead:
> a: "12345" > b: skip a 2 > clear a ; nothing happens to b here > insert a "12345" > index? b ; == 3
Gabriele, don't you see any problem in this? I could like also the Joel solution (= my second solution). But the big problem with out-of-range series is debugging. What i want to see is an "always debuggable" series. Today is a true hell with cases like these:
>> b: tail a: "1"
== ""
>> c: reduce [a b]
== ["1" ""]
>> clear a
== ""
>> probe c
** Script Error: Out of range or past end ** Where: probe ** Near: print mold :value :value How to understand what series is out-of-range? I can accept also moving index if i can debug it. But in the 2.5.5 beta debugging problems are the same (but with more crash). --- Ciao Romano

 [31/43] from: g:santilli:tiscalinet:it at: 24-Feb-2003 14:06


Hi Joel, On Monday, February 24, 2003, 12:44:37 PM, you wrote: JN> Horrors! 8-0 I disagree. ;-) JN> range or not). A script could then easily determine in advance JN> whether a series ref was "safe" to use or not, without having JN> an error thrown. I get accused of being too "implementation dependent", but when I try not to be I get accused of not being. ;-) Out-of-range series are an implementation artifact. From an "abstract" point of view they make no sense. (IMHO) JN> Seriously, I *strongly* dislike having the language change things JN> behind our backs, instead of just giving us a straightforward way JN> to look at the actual situation and make our own decisions. You can think of it as if out-of-range series did not exist. If you think it this way, there's nothing changing behind our backs. :-) JN> In the following transcript: JN> >> a: "1234567" ; == "1234567" JN> >> b: at a 4 ; == "4567" JN> >> clear at a 3 ; == "" JN> >> a ; == "12" JN> >> append a "CDEFG" ; == "12CDEFG" JN> >> b ; == "DEFG" JN> the position of B is *temporarily* out of bounds while the string JN> in A is being massaged. At the completion of that massaging, JN> however, B now provides access to what is at the corresponding JN> position in the new data. That seems useful to me. My proposed change would not change that piece of code. You do not access B so the interpreter does not have chances of resetting it. JN> from the data source. B is keeping up with which part of A we JN> need to look at (for every A that has that much data). Hmm, I don't think that exact piece of code would do that, but I see what you mean. Since INDEX? B does not change inside the loop you just save it and don't need to access B if it is out-of-range. JN> I'm certainly not saying that this is the only (or even best) JN> way to write this little fragment, but just trying to illustrate JN> that knowing where you were in a series (or being able to look JN> at that same place again) is a useful concept, regardless of how JN> the data in the series may change. You *can* look at any place with the AT function anyway, so I don't think this is really that useful. Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amigan -- AGI L'Aquila -- REB: http://web.tiscali.it/rebol/index.r

 [32/43] from: g:santilli:tiscalinet:it at: 24-Feb-2003 14:10


Hi Ladislav, On Monday, February 24, 2003, 1:02:16 PM, you wrote: LM> it is as I guessed. The functionality you suggested is not LM> compatible with the current implementation. The series index LM> attribute isn't implemented as volatile, therefore the INDEX? LM> function isn't able to change B (even if implemented LM> natively). How can you say that? LM> Your proposed behaviour would require a change of the series LM> implementation. IMHO, it doesn't. Of course, only RT can know, and decide what's the best way to solve the problem. LM> 1) Out-of-range series are products of the current LM> implementation and there is no way, how we can get rid of them LM> without changing the implementation. I agree, but we can make them "almost" invisible. [...] I think you should send this to feedback, to see what Carl thinks of it. Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amigan -- AGI L'Aquila -- REB: http://web.tiscali.it/rebol/index.r

 [33/43] from: g:santilli:tiscalinet:it at: 24-Feb-2003 14:29


Hi Ladislav, On Monday, February 24, 2003, 1:13:27 PM, you wrote: LM> a: "12345" LM> b: skip a 2 LM> c: b LM> clear a ; nothing happens to b here LM> index? b ; == 1 (b is reset to tail b as soon as it is evaluated) LM> insert a "12345" LM> index? b ; == 1 LM> index? c ; == ? 3 If this is not acceptable to you, then we have two choices: change the implementation so that both B and C get reset to the tail or the head of the series whenever they get out of bounds, or change the way series are defined/documented to account for the concept of "being out of range". For the latter, you would have to explain to me what a series is and what should happen when FORMing etc. an out of range series, because it does not match my concept of series of values . Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amigan -- AGI L'Aquila -- REB: http://web.tiscali.it/rebol/index.r

 [34/43] from: g:santilli:tiscalinet:it at: 24-Feb-2003 10:35


Hi Ladislav, On Sunday, February 23, 2003, 7:48:54 PM, you wrote: LM> I don't know your proposal, but I suspect, that its feasibility was LM> questionable (for the current interpreter implementation). On the contrary, I think it would be very easy to implement. I just think the interpreter should reset out-of-range series values to the series tail when they are evaluated. I.e.: a: "12345" b: skip a 2 clear a ; nothing happens to b here index? b ; == 1 (b is reset to tail b as soon as it is evaluated) insert a "12345" index? b ; == 1 This way it would be like if out-of-range series did not exist at all; I think it would be much less confusing (as out-of-range series are not useful, so I don't need that concept in the language). Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amigan -- AGI L'Aquila -- REB: http://web.tiscali.it/rebol/index.r

 [35/43] from: lmecir:mbox:vol:cz at: 24-Feb-2003 16:16


Hi Gabriele, you wrote: ...
> LM> The series index > LM> attribute isn't implemented as volatile, therefore the INDEX? > LM> function isn't able to change B (even if implemented > LM> natively). > > How can you say that?
I know for sure, that the series have an index attribute and that it isn't volatile. I am not able to prove, that RT implemented series in such a way, that even a different native INDEX? implementation can't change B in your code sample (and in all similar code samples), but I can bet :-)
> LM> 1) Out-of-range series are products of the current > LM> implementation and there is no way, how we can get rid of them > LM> without changing the implementation. > > I agree, but we can make them "almost" invisible.
Almost invisible they have always been. They can not become invisible. I prefer usefulness. I think, that if: a: "123456789" b: tail a , then the expression pick b -9 doesn't have any more sense (or a different purpose), than in the case like: a: "123456789" b: tail a remove back tail a the same expression pick b -9 has.

 [36/43] from: g:santilli:tiscalinet:it at: 24-Feb-2003 16:51


Hi Ladislav, On Monday, February 24, 2003, 4:16:26 PM, you wrote: LM> I know for sure, that the series have an index attribute and LM> that it isn't volatile. You can't change it in REBOL, but I bet you can easily change it in native code. LM> "Almost invisible" they have always been. They can not become I would not say so, they bomb out quite easily currently. :) Anyway, I wonder what Carl thinks about all this. It would be fine for me to have your solution, I just wonder about how would you explain it to "newbies", and if we should consider it an implementation artifact or a "feature". Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amigan -- AGI L'Aquila -- REB: http://web.tiscali.it/rebol/index.r

 [37/43] from: joel:neely:fedex at: 24-Feb-2003 10:57


Hi, Gabriele, Perhaps the fact that we're on opposite sides of the Greenwich meridian causes us to look at it from a different perspective (but at least we're both in the Northern hemisphere... ;-) Gabriele Santilli wrote:
> I get accused of being too "implementation dependent", but when I > try not to be I get accused of not being. ;-) Out-of-range series > are an implementation artifact. From an "abstract" point of view > they make no sense. (IMHO) > >From my "abstract" POV, the phrase "the third child in the family"
is a reasonable phrase, even when the phrase "the family" is allowed to take different meanings at different points in time. Even if we are (at the moment) discussing a one-child family, I see no problem with asking "Which child have we been talking about during this conversation?" and being told "The third one." Suppose we were looking at a specimen family and noticed that the third child was the first one to catch the measles. We then began looking through census and medical data to see how frequently the study child (third by age) was first to contract measles. At a point in that search where we are looking at a one-child family, the question "Does this family have a study child?" can be meaningfully asked and answered ("no"). Likewise the question "Who is the study child in this family?" can be meaningfully asked and answered ("There isn't one.") [* see footnote] In the same way, I think of the phrase "the third position of the series" as a reasonable (abstract, non-implementation-dependent) phrase, even when the phrase "the series" is allowed to take different meanings at different points in time. Even if we are (at the moment) discussing a one-element series, I see no problem with asking "Which element have we been examining through this reference?" and being told "3". To continue the parallel, the question length? this-series >= index? positioned-series could be meaningfully asked and answered (FALSE). Likewise the question first positioned-series could be meaningfully asked and answered (NONE). REBOL already does this using some "turns of phrase", as in pick [1] 3 ; == none I'm simply asking for consistency. Letting NONE universally represent There is no answer to your question. would seem to me to be a big step forward, and *away* from what I consider to be unnecessary, confusing, and implementation-dependent inconsistencies, such as
>> third [1]
** Script Error: Out of range or past end ** Where: halt-view ** Near: third [1] IMHO, evaluating
>> a: [1 2 3 4 5] ; == [1 2 3 4 5] >> b: at a 3 ; == [3 4 5]
is equivalent to saying "Let B refer to the data of A at the third position." and that meaning should be able to survive e.g.
>> clear next a
== [] but, of course, it currently can't.
>> index? b
** Script Error: Out of range or past end ** Where: halt-view ** Near: index? b even though I *can* phrase a question about the equivalent concept (the third position of the data in A) and get a calm answer
>> pick a 3
== none that essentially means "There's not one." instead of hysteria. -jn- [* footnote] In our hypothetical "third child" scenario, if asked about "the study child" of a one-child family, I'd be very disappointed if my associate burst into hysteria and ran from room shrieking "You can't say that anymore!!!". Likewise, I'd be disappointed if my associate refused to answer the question "Which child have we been talking about in each family?" However, I'd be truly horrified if my assistant dealt with the one-child situation by giving me information about the first/only child of the family and making the secret resolution to tell me thereafter about the first child of any subsequent family. -- ---------------------------------------------------------------------- Joel Neely joelDOTneelyATfedexDOTcom 901-263-4446 Counting lines of code is to software development as counting bricks is to urban development.

 [38/43] from: ammon:addept:ws at: 25-Feb-2003 2:06


Hello, As usual, beautifully said Joel!!! Enjoy!! Ammon Johnson CIO of Addept ---------- (www.addept.ws) 435.616.2322 ---------- (ammonATaddeptDOTws)

 [39/43] from: g:santilli:tiscalinet:it at: 25-Feb-2003 11:58


Hi Joel, On Monday, February 24, 2003, 5:57:57 PM, you wrote: JN> From my "abstract" POV, the phrase "the third child in the family" JN> is a reasonable phrase, even when the phrase "the family" is allowed JN> to take different meanings at different points in time. Even if we I agree, and REBOL handles that very nicely, with:
>> pick [1 2] 3
== none Notice that I never liked:
>> third [1 2]
** Script Error: Out of range or past end ** Near: third [1 2] while Ladislav suggest this to be applied to PICK too. Out-of-range series are a different issue IMHO. If you ask yourself the question: "is the child you have in front of you the third child?" then the answer "there's no third child in this family" seems reasonable to me. JN> In the same way, I think of the phrase "the third position of the JN> series" as a reasonable (abstract, non-implementation-dependent) The third element yes, the third position no, if we think of position as a possible state for a series value, IMHO. I.e. to the question "where am I?", why should I get the answer "nowhere"? Of course, we can define series differently as an infinite space where you can place values; if they are infinite, you can move forward and backward as you wish, even if the series is empty. But the current concept of series is a finite sequence of values. JN> asking "Which element have we been examining through this reference?" JN> and being told "3". Again, it's not a problem for me as long as we redefine the concept of "series". As I see them now, the answer above makes no sense for an empty series. JN> I'm simply asking for consistency. Letting NONE universally represent JN> "There is no answer to your question." would seem to me to be a big JN> step forward, and *away* from what I consider to be unnecessary, JN> confusing, and implementation-dependent inconsistencies, such as I agree wholeheartedly. I'm sure Lad has to object to this, however. :) JN> but, of course, it currently can't. JN> >> index? b JN> ** Script Error: Out of range or past end JN> ** Where: halt-view JN> ** Near: index? b Hmm, should it return NONE? (This question is probably more serious than it could look. :) JN> However, I'd be truly horrified if my assistant dealt with the JN> one-child situation by giving me information about the first/only JN> child of the family and making the secret resolution to tell me JN> thereafter about the first child of any subsequent family. Yup, and that's why I'd use PICK and not AT in that case. :-P Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amigan -- AGI L'Aquila -- REB: http://web.tiscali.it/rebol/index.r

 [40/43] from: lmecir:mbox:vol:cz at: 25-Feb-2003 14:13


Hi all, Gabriele wrote:
> Of course, we can define series differently as an infinite space > where you can place values; if they are infinite, you can move > forward and backward as you wish, even if the series is empty. But > the current concept of series is a finite sequence of values.
As I see it, there is no comprehensive description, what is a series. The description: {A series is a set of values organized in a specific order.} looks correct (Does it admit, that it is possible to have a series containing one value thrice?) Nevertheless, it looks to me, that the documentation describes colors: [red green blue] as a series, while it didn't admit in the text immediately following it, that colors2: next colors was a series too. The alternative to use the series implementation as its description is most probably wrong. E.g. the object-oriented programming is appreciated for "implementation details hiding". We can refer to the documentation: {Series data types can all be accessed and processed in the same way with the same small set of functions.} , which looks to me as an important part of the series description. What do we get, if we "consult" the interface? a) the PICK - influenced series description: a1) a Rebol series is a mapping, that maps an integer (or logic) INDEX to a Rebol value. a2) exceptions to the above rule are series, that don't map anything to anything, instead they fire an error when used with PICK. Let's call these "out of range" series as opposed to the "in range series" described above. a3) every "in range series" maps ZERO to NONE a3) For every series there is a LENGTH? value, such that every integer INDEX larger than the LENGTH? is mapped to NONE. a4) For every series there is an INDEX? value, such that every INDEX smaller than 1 - INDEX? is mapped to NONE It is interesting, that PICK is unable to discern a: [1 none] and b: [1] , which may or may not be necessary. Let's describe the NEXT function: a5) If the NEXT function obtains an "out of range series", it fires an error a6) If the NEXT function obtains an "in range" series, which has got LENGTH? equal to ZERO, it returns the series it obtained a7.1) If the NEXT function obtains an "in range" series, which has got LENGTH? greater than ZERO, it returns a series with LENGTH?, that is smaller by one, than the LENGTH? of the original series and with INDEX? greater by one, than the INDEX? of the original series. - the new series maps every positive INDEX to the value, to which the original series maps INDEX + 1. - the new series maps -1 to the value, to which the original value mapped 1 - the new series maps every INDEX smaller than -1 to the value, to which the original mapped INDEX + 1 (...) Isn't this boring? (It is, AFAIAC). Other possible alternatives are FIRST SKIP influenced descriptions, which are less complicated (try to formulate some rules), but the out/in range distinction still messes things unnecessarily sometimes (IMO). Regards -L

 [41/43] from: g:santilli:tiscalinet:it at: 25-Feb-2003 15:33


Hi Ladislav, On Tuesday, February 25, 2003, 2:13:52 PM, you wrote: LM> As I see it, there is no comprehensive description, what is a LM> series. So, should we write such a description, and send it to feedback, to see if it is ok and we can publish it as "the" description of series? We can even write two or more versions and let Carl comment on them. Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amigan -- AGI L'Aquila -- REB: http://web.tiscali.it/rebol/index.r

 [42/43] from: petr:krenzelok:trz:cz at: 25-Feb-2003 16:14


Gabriele Santilli wrote:
>Hi Ladislav, >On Tuesday, February 25, 2003, 2:13:52 PM, you wrote:
<<quoted lines omitted: 4>>
>series? We can even write two or more versions and let Carl >comment on them.
Wouldn't it be better, if RT (Carl) would comment directly? I remember similar discussion and mostly wasted time on similar topics, where clear explanation from RT folks would save you a lot of time. The only value of such discussion is educational one :-) -pekr-

 [43/43] from: g:santilli:tiscalinet:it at: 25-Feb-2003 17:11


Hi Petr, On Tuesday, February 25, 2003, 4:14:18 PM, you wrote: PK> Wouldn't it be better, if RT (Carl) would comment directly? I remember It would. But do you think he has the time to write down such a description for us? It's better if we do the work, and he just says "no" or "yes" --- that should not take him too much time. :) Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amigan -- AGI L'Aquila -- REB: http://web.tiscali.it/rebol/index.r

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