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