Cunning use of [], () & {} in R# and in future? Rebol versions?
[1/32] from: andrew:martin:colenso:school at: 24-Dec-2003 22:40
It occurred to me as I was writing Rebol code, that it's possible to
re-use these characters [], () & {}, in useful ways. I've noticed that
when I'm writing block!, paren! & string values, I leave white space
before and after the [], () & {} characters. It would be nice to have:
>> X: ["a" "b" "c"]
== ["a" "b" "c"]
>> X[2]
== "b"
In other words, by running the block "hard" against the word, it's like:
pick X 2
I don't know what use () and {} could have, though. What's your
thoughts?
Andrew J Martin
Attendance Officer
& Grail Jedi who is tapping on the dungeon wall with Rebol...
Colenso High School
Arnold Street, Napier.
Tel: 64-6-8310180 ext 826
Fax: 64-6-8336759
http://colenso.net/scripts/Wiki.r?AJM
http://www.colenso.school.nz/
DISCLAIMER: Colenso High School and its Board of Trustees is not responsible (or legally
liable) for materials distributed to or acquired from user e-mail accounts. You can report
any
misuse of an e-mail account to our ICT Manager and the complaint will be investigated.
(Misuse can come in many forms, but can be viewed as any material sent/received that
indicate or suggest pornography, unethical or illegal solicitation, racism, sexism, inappropriate
language and/or other issues described in our Acceptable Use Policy.)
All outgoing messages are certified virus-free by McAfee GroupShield Exchange 5.10.285.0
Phone: +64 6 843 5095 or Fax: +64 6 833 6759 or E-mail: [postmaster--colenso--school--nz]
[2/32] from: amicom:sonic at: 15-Oct-2003 21:32
Andrew,
That would break some existing Rebol scripts. Right now, someone might
have some Rebol code written like:
x: true
either X[2][3]
This would break with your implementation.
Why not use X/2 ? It's shorter anyway.
Bohdan "Bo" Lechnowsky
Lechnowsky Technical Consulting
At 05:05 PM 10/16/03 +1300, you wrote:
[3/32] from: atruter:labyrinth:au at: 16-Oct-2003 14:46
>>> X: ["a" "b" "c"]
> == ["a" "b" "c"]
>>> X[2]
> == "b"
>
> In other words, by running the block "hard" against the word, it's like:
> pick X 2
Why not simply use path (x/2 in the example above) notation, it saves a
character at least. ;)
As for finding "other" uses for "[], () & {}", if it makes sense in a
certain context then great, but I suspect it could lead to subtle and hard
to find errors (especially of the mismatched number of opening / closing
xxx type).
Regards,
Ashley
[4/32] from: rebol:techscribe at: 15-Oct-2003 21:50
Hi Andrew.
You wrote:
>I've noticed that when I'm writing block!, paren! &
> string values, I leave white space before and after
> the [], () & {} characters.
After puzzling over your intro briefly, it appears to me that you see
the additional space as being significant in distinguishing between your
two examples:
(1) With space
>>X: ["a" "b" "c"]
>>
>>
== ["a" "b" "c"]
and (2) without space
>>X[2]
>>
>>
== "b"
Notice, however, that the colon is also missing in example 2. I.e., even
if you were not to supply the extra space in example 1, i.e.
>> X:["a" "b" "c"] ;- example 3
you would still have the significant distinction to example 2 in that
in example 3 you again have the colon separating the X from the block ,
whereas in example (i.e. X[2]) there is no such colon.
Andrew Martin wrote:
[5/32] from: maximo:meteorstudios at: 16-Oct-2003 9:06
> Andrew Martin wrote:
> >It occurred to me as I was writing Rebol code, that it's possible to
<<quoted lines omitted: 16>>
> >>>
> >== "b"
more liquely [X--2], X#2, X>2, X\2, X.2, X|2, X,2
one would equate to
>> at X 2
["b" "c"]
another to
>> at head X 2
this breaks no current rules (it might collide with mail datatype though?) and is a logical
complement for the X/2 which we all use. If a specific datatype does not usually return
a block (like a tuple), then it would have to do so.
print ["my 0.02" (locale/currency)]
-MAx
[6/32] from: nitsch-lists:netcologne at: 16-Oct-2003 15:37
Hum. If this magic-char-thread is serious, could i borrow someone my
perl-interpreter? ;)
-Volker
Am Donnerstag, 16. Oktober 2003 15:06 schrieb Maxim Olivier-Adlhoch:
[7/32] from: andrew:martin:colenso:school at: 24-Dec-2003 22:41
Volker wrote:
> Hum. If this magic-char-thread is serious, could I borrow someone my
perl-interpreter? ;)
With Rebol, my words mean what I want them to mean. :) :-/
But if I want to be understood and want to understand others, it's best
that we all agree on what Rebol or R# words mean to all of us! :)
Andrew J Martin
Attendance Officer,
Grail Jedi, Knight of Lucidity & destroyer of gibberish!
Colenso High School
Arnold Street, Napier.
Tel: 64-6-8310180 ext 826
Fax: 64-6-8336759
http://colenso.net/scripts/Wiki.r?AJM
http://www.colenso.school.nz/
DISCLAIMER: Colenso High School and its Board of Trustees is not responsible (or legally
liable) for materials distributed to or acquired from user e-mail accounts. You can report
any
misuse of an e-mail account to our ICT Manager and the complaint will be investigated.
(Misuse can come in many forms, but can be viewed as any material sent/received that
indicate or suggest pornography, unethical or illegal solicitation, racism, sexism, inappropriate
language and/or other issues described in our Acceptable Use Policy.)
All outgoing messages are certified virus-free by McAfee GroupShield Exchange 5.10.285.0
Phone: +64 6 843 5095 or Fax: +64 6 833 6759 or E-mail: [postmaster--colenso--school--nz]
[8/32] from: greggirwin:mindspring at: 16-Oct-2003 17:38
Hi Andrew,
AM> It occurred to me as I was writing Rebol code, that it's possible to
AM> re-use these characters [], () & {}, in useful ways. I've noticed that
AM> when I'm writing block!, paren! & string values, I leave white space
AM> before and after the [], () & {} characters. It would be nice to have:
>>> X: ["a" "b" "c"]
AM> == ["a" "b" "c"]
>>> X[2]
AM> == "b"
AM> In other words, by running the block "hard" against the word, it's like:
AM> pick X 2
I'd stick with standard notations. I like the idea that blocks are
blocks and not used as another notation. As others have pointed out,
we have path notation (which is even more concise than the C/C# notation
for accessing array elements).
-- Gregg
[9/32] from: andrew:martin:colenso:school at: 24-Dec-2003 22:41
Earlier I wrote:
>> X[2]
> == "b"
It looks like I'm solving problems which not yet exist.
Andrew J Martin
Attendance Officer
& Grail Jedi, fighting with laser swords...
Colenso High School
Arnold Street, Napier.
Tel: 64-6-8310180 ext 826
Fax: 64-6-8336759
http://colenso.net/scripts/Wiki.r?AJM
http://www.colenso.school.nz/
DISCLAIMER: Colenso High School and its Board of Trustees is not responsible (or legally
liable) for materials distributed to or acquired from user e-mail accounts. You can report
any
misuse of an e-mail account to our ICT Manager and the complaint will be investigated.
(Misuse can come in many forms, but can be viewed as any material sent/received that
indicate or suggest pornography, unethical or illegal solicitation, racism, sexism, inappropriate
language and/or other issues described in our Acceptable Use Policy.)
All outgoing messages are certified virus-free by McAfee GroupShield Exchange 5.10.285.0
Phone: +64 6 843 5095 or Fax: +64 6 833 6759 or E-mail: [postmaster--colenso--school--nz]
[10/32] from: carl:cybercraft at: 24-Dec-2003 22:41
On 17-Oct-03, Andrew Martin wrote:
> Earlier I wrote:
>>> X[2]
>> == "b"
> It looks like I'm solving problems which not yet exist.
But it got me thinking anyway, so would this be useful...
>> blk: ["a" "b" "c" "d" "e"]
== ["a" "b" "c" "d" "e"]
>> blk/[1 4 5]
== ["a" "d" "e"]
?
--
Carl Read
[11/32] from: AJMartin:orcon at: 24-Dec-2003 22:41
Carl Read wrote:
> > Earlier I wrote:
> >>> X[2]
<<quoted lines omitted: 6>>
> == ["a" "d" "e"]
>> blk: ["a" "b" "c" "d" "e"]
== ["a" "b" "c" "d" "e"]
>> picks blk [1 4 5]
== ["a" "d" "e"]
:)
Andrew J Martin
Grail Jedi
ICQ: 26227169
http://www.rebol.it/Valley/
http://valley.orcon.net.nz/
http://Valley.150m.com/
[12/32] from: carl:cybercraft at: 24-Dec-2003 22:41
On 17-Oct-03, A J Martin wrote:
> Carl Read wrote:
>>> Earlier I wrote:
<<quoted lines omitted: 15>>
> :)
>> ? picks
No information on picks (word has no value)
? (Tried in View up to 1.2.10)
--
Carl Read
[13/32] from: AJMartin:orcon at: 24-Dec-2003 22:41
Carl Read wrote:
> >> ? picks
> No information on picks (word has no value)
Hmmm, seems to work OK for me: :-)
>> source picks
picks: func [
[catch throw]
{Returns the values at the specified positions in the series.}
Series [series! pair! event! money! date! time! object! port! tuple!
any-function!]
Indexes [block!]
][
foreach Index Indexes collect/full/only [
if not number? Index [
throw make error! reduce ['script 'expect-arg 'Picks 'Indexes
mold [any number!]]
]
pick Series Index
]
]
Of course, you'll need the source for 'collect as well:
>> source collect
collect: func [
"Collects the results of block evaluations."
Block [block!] "The block to 'do."
/Only "Inserts the result as a series."
/Full "Don't ignore none! values."
/Initial Type [series! datatype!] "Specifies the type of the result."
][
use [Break Result Results] [
Break: func [
"Breaks out of the 'Collect."
/Return "Forces the loop function to return a Value."
Value [any-type!]
] [
system/words/break/return either Return [
Value
] [
Results
]
]
Results: any [
all [
datatype? Type
make Type 0
]
Type
copy []
]
compose/deep [
if not any [
unset? set/any 'Result do [(bind Block 'Break)]
(pick [[none? :Result] []] not Full)
] [
(pick [insert insert/only] not Only) tail Results :Result
Results
]
Results
]
]
]
Enjoy!
Andrew J Martin
Grail Jedi
ICQ: 26227169
http://www.rebol.it/Valley/
http://valley.orcon.net.nz/
http://Valley.150m.com/
[14/32] from: maximo:meteorstudios at: 17-Oct-2003 9:23
> -----Original Message-----
> From: Carl Read [mailto:[carl--cybercraft--co--nz]]
<<quoted lines omitted: 12>>
> >> blk/[1 4 5]
> == ["a" "d" "e"]
now you're talking
it even looks rebolish... add python's list notation which is nice (I must admit, and
is missing altogether in rebol).
examples (with equivalent rebol line after):
series[5:10] -> return a series starting at 5 ending at 10
copy/part at series 5 at series 10
series[5] -> return element 5
series/5 (I'd rather keep series/5 and add /[5] which returns a block with only the
fifth element in it
series[:10] -> return everything up to element 10
copy/part series at series 10
series[5:] -> return everything starting a element 5
at series 5
you can even use negative indexes to reverse the direction...
so:
series[-5:-10]
reverse at series (length? series - 10) at series (length? series - 5)
the advantage of the python notation is that it is much more unified. It is also often
much shorter and more visual
I'm not saying scrap the current system (we needs its versatility and oppeness), just
adding some equivalent to the python method in the way Carl just wrote it. We'd all
benefit from shorter, often, more redeable scripts.
I know we can write a function for it... but that adds a word in the source which really
isn't needed if its supported in the base syntax. Only RT can do that.
the way carl just describes it, added with added range notation does not break any current
rebol syntax I can remember, yet it makes our lives much simpler.
What do you all think?
-MAx
[15/32] from: mmastroianni::lepcorp::com at: 17-Oct-2003 11:22
Hi all -
This thread reminds me of some of the
very nice MATLAB notation for referencing
matrix or array elements:
A(1:10) - elements 1 thru 10
A(:,5:10) - all rows, only columns 5 thru 10
A(5:10,:) - all columns, only rows 5 thru 10
A(:) - all elements
A' - all elements transposed (cols switched
with rows) dimension r x c becomes c x r
It might be nice to accommodate the two dimensional
idea as an enhancement; n-dimensional referencing
might be nice too...
A REBOL shorthand for block or series referencing
in this flavor might be very helpful -- at least
I think it would. On the other hand, I've got a
long way to go before I appreciate the subtleties
of REBOL ...
Mike
<SNIP>
[16/32] from: carl:cybercraft at: 24-Dec-2003 22:41
On 18-Oct-03, Maxim Olivier-Adlhoch wrote:
>> -----Original Message----- From: Carl Read
>> [mailto:[carl--cybercraft--co--nz]] Sent: Friday, October 17, 2003 2:02
<<quoted lines omitted: 40>>
> lives much simpler.
> What do you all think?
I'm not sure how best to impliment it in a REBOL way, but it would be
nice. For selecting ranges within a series, perhaps parens could be
used something like this...
>> blk: ["a" "b" "c" "d" "e" "f" "g"]
== ["a" "b" "c" "d" "e" "f" "g"]
>> blk/[1 (3 5)]
== ["a" "c" "d" "e"]
>> blk/[(first 2) (5 last)]
== ["a" "b" "e" "f" "g"]
But, should it also work like this...
>> blk/[(first 2) (5 last)]/3
== "e"
?
--
Carl Read
[17/32] from: antonr:iinet:au at: 18-Oct-2003 19:57
That looks like a new "range selection" dialect.
I can imagine a range-pick function perhaps:
range-pick: func [series dialect][...]
blk: [a b c d e f g]
range-pick blk [1 (3 5)]
;== [a c d e]
That would be similar to Andrew's picks function.
Anton.
[18/32] from: moliad:aei:ca at: 18-Oct-2003 11:22
> That looks like a new "range selection" dialect.
> I can imagine a range-pick function perhaps:
>
> range-pick: func [series dialect][...]
>
> blk: [a b c d e f g]
> range-pick blk [1 (3 5)]
> ;== [a c d e]
but now you can't leave the start and end infinite unless we do something like:
blk/[ 1 (3 *)]
I still prefer this type of syntax:
blk/[1 3:5]
it is clear, and uses the least typing each space defines a block to extract it
also looks most like spreadsheets syntax when specifying ranges .
we could even add the ~ or ! (not ) operator
blk/[ 5: ~10 ] ; everything starting at 5 but not the tenth element.
because the colon is already used, maybe we could simply use another character:
-MAx
[19/32] from: greggirwin:mindspring at: 18-Oct-2003 13:02
Max et al,
I agree that something more concise than "raw REBOL" (copy/part
at...) would be great, but the slice notation as used in Python and
Ruby isn't grabbing me--not for general use anyway.
MOA> I still prefer this type of syntax:
MOA> blk/[1 3:5]
MOA> it is clear, and uses the least typing each space defines a block to
MOA> extract it also looks most like spreadsheets syntax when specifying
MOA> ranges.
...
MOA> blk/[ 5: ~10 ] ; everything starting at 5 but not the tenth element.
It may be clear to programmers that are familiar with that notation,
but I'm not sure it would be clear to normal people (spreadsheet
people are in-between and would understand the basic range notation,
but would have to learn any extensions to it).
The n:m notation would conflict with time! values as well.
General clarity aside, my gut reaction to the path/block/slice
notation isn't positive. I don't think it buys us anything in the long
run, and it could have a pretty serious impact on things if included
as a base syntactical change (particularly if it doesn't fit within
REBOL's current lexicon).
MOA> because the colon is already used, maybe we could simply use another
MOA> character:
If you "simply use another character", then you: a) lose what I see as
the most positive aspect of it--that it's a known range notation for
some people, and b) fall into a "what fits" approach, rather than
designing for clear meaning and intent.
Now, since I disagree, it's only fair that I offer up a solution. :)
At the end of this message is a function called EXCERPT, that uses a
simple dialect. I originally called it CUT (as in the *nix utility
that does the same kind of thing), which also maps closely to the
slice
concept in other languages. The problem I saw was that we're
not really cutting anything out, we're copying things out, so it isn't
really an accurate name (IIRC, Python and Ruby have different
semantics for slicing). COPY, SELECT, and PICK are already taken, as
is EXTRACT; though EXTRACT is a mezzanine that we could enhance, which
might be a better bet. EXCERPT implies the correct meaning to me, but
it isn't grabbing me as a great word so far. :)
Let me know what you think.
-- Gregg
; The dialect allows you to use commas in the block, but how they
; are interpreted is not how you might think. Coming after a number,
; they are a valid lexical form, but they denote a decimal! rather
; than being seen as a separator, which means you can't use them too
; flexibly.
excerpt: func [
{Returns the specified items and/or ranges from the series.}
series [series!]
offsets [block!] {Offsets of the items to extract; dialected.}
/only "return sub-block ranges as blocks"
/local
emit emit-range rules
from* to* index* ; parse vars
result
][
emit: func [value] [
either only [append/only result value][append result value]
]
emit-range: func [start end] [
start: to integer! start
if number? end [end: to integer! end - start + 1]
emit either end = 'end [copy at series start][
copy/part at series start end
]
]
rules: [
some [
opt 'from set from* number! 'to set to* number! (
emit-range from* to*
)
| opt 'from set from* number! 'to 'end (emit-range from* 'end)
| 'to set to* number! (emit-range 1 to*)
| set index* number! (emit pick series index*)
| into rules
]
]
; Return a block. Easy enough for them to REJOIN if they want.
result: make block! length? series
parse offsets rules
result
]
b: [1 2 3 4 5 6 7 8 9 10 11 12 13 14]
excerpt b [1 3 5]
excerpt b [1 3 to 6 8]
excerpt/only b [1, 3 to 6, 8]
excerpt b [1 [5 to 7] 8]
excerpt/only b [1 (from 5 to 7) 8]
excerpt b [(to 2) [4 to 6] 8, 10, from 12 to end]
excerpt/only b [to 2, 4 to 6, 8, 10, (12 to end)]
; Can't use a comma after 'end
excerpt/only b [to 2 to 6 8 10 to end 12 to end]
excerpt/only b [to 2, to 6, 8 [10 to end] 12 to end]
excerpt/only trim {
REBOL is my favorite language
} [
to 5, 10 to 11, 13, 14, 15, 22 to end
]
[20/32] from: nitsch-lists:netcologne at: 18-Oct-2003 22:40
Gregg, cool . but how about parse?
>> b: [1 2 3 4 5 6 7 8 9 10 11 12 13 14]
== [1 2 3 4 5 6 7 8 9 10 11 12 13 14]
>> parse b[ 4 skip copy v 2 skip]
== false
>> v
== [5 6]
-Volker
Am Samstag, 18. Oktober 2003 21:02 schrieb Gregg Irwin:
[21/32] from: greggirwin:mindspring at: 19-Oct-2003 9:51
Hi Volker,
VN> Gregg, cool . but how about parse?
>>> b: [1 2 3 4 5 6 7 8 9 10 11 12 13 14]
VN> == [1 2 3 4 5 6 7 8 9 10 11 12 13 14]
>>> parse b[ 4 skip copy v 2 skip]
VN> == false
>>> v
VN> == [5 6]
That would work well for a single slice, but I'd still wrap it in a
function to make the meaning clearer. For multiple slices, it would
get ugly real fast I think.
-- Gregg
[22/32] from: moliad:aei:ca at: 19-Oct-2003 15:29
before I start,
I don't want you to know that I agree to most of what you say in theory, I'm
just trying to see if there isn't a way to extend the base syntax in a way that
code is shorter, and easier to read. Since we are in email, the tone gets
perceived by the reader, not sent by the writter... I've had bad past experience
in this kind of on-going discussions before (but not on this list :-)
I love philosophy so, nothing here is personal... :-)
----- Original Message -----
From: "Gregg Irwin" <>
> It may be clear to programmers that are familiar with that notation,
[ start : end ] Seemed clear to me, the first time I read it. a month. ago (I'm
not a python expert, believe me... I generaly hate it)
I even tought it used similar rebolish syntax...
advanced features get used by advanced users... a lot of the code I see from
the guru is hard to read for me, simply because it uses tricks I have not
stumbled on yet... The words are all similar, but when looking at them, they
seem to have no meaning.
have you tried going through all the view code... there is much to learn, but
darn some of it is almost impossible to grasp.
another example is the series/:index notation I mean, really that wasn't
obvious, although logical. Eventually, when a programmer gets to a point where
he needs that notation, he jumps on the list and gets the answer... I've seen it
already a few times this year...
> people are in-between and would understand the basic range notation,
> but would have to learn any extensions to it).
nothing is clear in rebol, until you've programmed in it a few months. words
not being variables, for example, is the basic thing in rebol which goes
unnoticed until some weird thing happens in your code... its happened to all
experienced reboler (unless they where already well versed in lisp speak, I
guess).
> The n:m notation would conflict with time! values as well.
My guess is that RT can make sure that if they found a path value with a block
in it, they'd simply understand it as a range instead... isn't that what a
dialect is? context specific code?
> General clarity aside, my gut reaction to the path/block/slice
> notation isn't positive. I don't think it buys us anything in the long
> run, and it could have a pretty serious impact on things if included
> as a base syntactical change
it isnt really a change, its more of an addition, but I guess you mean that
people creating dialects and expecting paths, would have to handle range
notations too, then you are right, that it causes some mishaps. But then most of
the code I get from this list already isn't supported in older versions of
rebol... especially view v1.2.3
> excerpt: func [
[...]
> ]
cool func !!
----------------
don't want to look picky but
a: 1
b: 5
excerpt b [a to b]
I know someone will say do this:
excerpt b compose [(a) to (b)]
but then, the idea behind the discussion starts loosing most of its sense.
The idea I find, is that sometimes, lines of code get sooo long when a simple
new notation could address them.
cheers!
-MAx
[23/32] from: ingo:2b1 at: 19-Oct-2003 21:45
Hi Maxim,
Maxim Olivier-Adlhoch wrote:
<...>
> advanced features get used by advanced users... a lot of the code I see from
> the guru is hard to read for me, simply because it uses tricks I have not
> stumbled on yet... The words are all similar, but when looking at them, they
> seem to have no meaning.
Yup, been there, done that, but didn't even get the T-Shirt ;-)
> have you tried going through all the view code... there is much to learn, but
> darn some of it is almost impossible to grasp.
Right again.
<...>
>>excerpt: func [
> [...]
<<quoted lines omitted: 5>>
> b: 5
> excerpt b [a to b]
<...>
It's no problem to write the dialect to understand this (at least, once
you understand how the 'layout dialect works (which, incidentally, I don't)).
Any takers?
Ingo
[24/32] from: nitsch-lists:netcologne at: 20-Oct-2003 4:20
a[ 5 : 10 ] instead of
copy/part skip a 5 skip a 10
?
how about extending path syntax?
a/5:10
?
a/(5 + 7 + 29 + 3) is hard to read IMHO. the "/" is very hidden now.
how about something spreadsheet-oriented?
could even be a whole datatype.
i would like to position inside a matrix, so having
a: [
[1 2 3 4]
[5 6 7 8]
[9 A B C]
]
b: skip-matrix a 2 2
;fictional
!>> b/1/1
== 6
!>> b/2/1
== A
!> b/1:2/1:2
== [ [6 7] [A B] ]
Half spreadsheet :)
Intersting:
>> 'b/1:2/1:2
== b/1:02/1:02
a valid path. with time-values.
now when i do a spreadsheed-dialect i could use rebol-syntax directly.
with up to 60 columns :)
-Volker
Am Sonntag, 19. Oktober 2003 21:29 schrieb Maxim Olivier-Adlhoch:
[25/32] from: AJMartin:orcon at: 24-Dec-2003 22:41
Volker suggested:
> how about extending path syntax?
> a/5:10
How about these two alternatives:
a/5-10
a/5..10
?
Both use reasonably common indicators which mean "missing something out,
which is very obvious".
Andrew J Martin
ICQ: 26227169
http://www.rebol.it/Valley/
http://valley.orcon.net.nz/
http://Valley.150m.com/
[26/32] from: brett:codeconscious at: 20-Oct-2003 16:29
As Max wrote:
> I love philosophy so, nothing here is personal... :-)
> Volker suggested:
<<quoted lines omitted: 6>>
> Both use reasonably common indicators which mean "missing something out,
> which is very obvious".
Paths are a series of values - each value in the series having a datatype.
So is a/5..10 one path of length two - the second value (5..10) being a new
datatype? Something like a pair?
But if it is a new datatype we would want to store them in a block
a: [1..3 5..10]
a/5..10 ...oh oh.
Or is a/5..10 meaning that .. is an operator with the necessary whitespace
missing in which case it should be written
a/5 .. 10
or perhaps even
.. a/5 10
Hmm...
I don't doubt that REBOL can be improved, but I've don't think I've seen any
compelling suggestion on this thread yet - though I do admit, lots of
innovation! :^)
Then again, I still occasionally lament the removal of aggressively
evaluated paths so who am I to comment?! (-:
Brett.
[27/32] from: g:santilli:tiscalinet:it at: 20-Oct-2003 10:00
Hi Brett,
On Monday, October 20, 2003, 8:29:41 AM, you wrote:
BH> So is a/5..10 one path of length two - the second value (5..10) being a new
BH> datatype? Something like a pair?
There are two issues here that people seem to forget. First of
all, REBOL is based on values, not on "operators". So we are not
talking about adding a new operator, we are talking about adding a
new type of value, or at least adding new semantics for some
existing datatype when encountered by the function interpreter.
Second, there's something I don't like in the kind of semantics we
are talking about: we are hiding under some kind of syntactic
sugar an operation that is going to require an amount of
computation that is not evident by looking at the notation itself.
This is in part the case for paths too, so I'm not saying a firm
no
, but I'm very afraid of this kind of syntactic sugar.
Regards,
Gabriele.
--
Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer
Amiga Group Italia sez. L'Aquila --- SOON: http://www.rebol.it/
[28/32] from: carl:cybercraft at: 24-Dec-2003 22:41
On 20-Oct-03, Brett Handley wrote:
> As Max wrote:
>> I love philosophy so, nothing here is personal... :-)
<<quoted lines omitted: 12>>
> So is a/5..10 one path of length two - the second value (5..10)
> being a new datatype? Something like a pair?
Curiously, 5..10 is already a valid datatype...
>> 5..10
== 5.0.10
5-10 isn't though...
>> 5-10
** Syntax Error: Invalid date -- 5-10
** Near: (line 1) 5-10
If a new datatype, it'd be called range! I guess. But how to indicate
first or last? Maybe...
5-10
*-10
5-*
or some alternative to an asterix, though not a colon, as it'd be much
too confusing in a path.
> But if it is a new datatype we would want to store them in a block
> a: [1..3 5..10]
<<quoted lines omitted: 11>>
> evaluated paths so who am I to comment?! (-:
> Brett.
--
Carl Read
[29/32] from: brett:codeconscious at: 20-Oct-2003 22:15
I thought of a range datatype too, and it would pobably have its uses, but
my intent was not to promote a new type so much as to indicate a position
far more elegantly and precisely described by Gabriele.
Regards,
Brett.
----- Original Message -----
From: "Carl Read" <[carl--cybercraft--co--nz]>
To: <[rebol-list--rebol--com]>
Sent: Monday, October 20, 2003 8:33 PM
Subject: [REBOL] Re: Cunning use of [], () & {} in R# and in future? Rebol
versions?
[30/32] from: greggirwin:mindspring at: 20-Oct-2003 10:48
Hi Max,
MOA> I love philosophy so, nothing here is personal... :-)
Yes, same here.
MOA> a lot of the code I see from
MOA> the guru is hard to read for me, simply because it uses tricks I have not
MOA> stumbled on yet... The words are all similar, but when looking at them, they
MOA> seem to have no meaning.
MOA> have you tried going through all the view code... there is much to learn, but
MOA> darn some of it is almost impossible to grasp.
This is one of the mindset changes I still struggle with. I used to
design and code so that things were as generically-understandable as
possible, at the expense of elegance. What I think about more and more
with REBOL is how to make things as clear as possible to a subset of
people--people that I want to communicate with. This is tough with
things like reusable modules and functions that could have a wide
audience and be put to use in many contexts.
Rather than writing for drop-in usage everywhere, I'll allow myself
to make assumptions and know that people will modify things to suit
their needs. It's a whole different view, and not an easy change for
me. But when I look at Carl's code in many places, that's how I
interpret what he has done. Really advanced REBOL is a different
language than very basic REBOL; a dialect if you will. :)
MOA> nothing is clear in rebol, until you've programmed in it a few months.
I can only speak for myself, but I *think* programmers coming from
other languages may have the hardest time with things. Even after two
years, I still don't always think of things how I know I should in
REBOL.
One of the best tricks I have found for myself is a twist on the idea
of "playing turtle" in Logo. I "play interpreter" by reading my code
as a series of values and stepping through it mentally. It's fun. :)
MOA> My guess is that RT can make sure that if they found a path value
MOA> with a block in it, they'd simply understand it as a range
MOA> instead... isn't that what a dialect is? context specific code?
...
MOA> it isnt really a change, its more of an addition, but I guess you mean that
MOA> people creating dialects and expecting paths, would have to handle range
MOA> notations too, then you are right, that it causes some mishaps. But then most of
MOA> the code I get from this list already isn't supported in older versions of
MOA> rebol... especially view v1.2.3
Yes, but I guess I see it as a more sweeping change than that, because
it's adding a dialect to a datatype, which has a specific lexical
form, so if you do it for paths: do you do it for other datatypes; is
it only valid as a complete path element; are they aggressively
evaluated; does it cause other side effects; how does COMPOSE work
with it (i.e. block flattening); can they be nested; do we go as far
as the concept of generators in Icon, and what would that mean, etc.
Maybe I just worry too much. :)
Could I do stuff like this?
start: 2
stop: 12
foreach ip 192.168.[1:10].1 [
; time! values as range boundaries?
foreach data read join http:// [ip "/dat[(00:00):(4:30)].html"] [
foreach addr data-monitor-[#"a":#"f"]@synedyne.dom [
send addr data/[:start::stop] ;<< ??? syntax
]
]
]
And what would be the cost in time, effort, and complexity, versus
what we gain, maybe compared with writing a RANGE function that knows
how to handle this stuff, but makes it an explicit dialected function?
MOA> don't want to look picky but
MOA> a: 1
MOA> b: 5
MOA> excerpt b [a to b]
MOA> I know someone will say do this:
MOA> excerpt b compose [(a) to (b)]
Wouldn't a range notation have the same issue? A dialect is a dialect
(no matter how small :).
How would a range notation handle it?
b/[a:b] ; aggressively evaluated. Only integer! boundaries OK?
b/:[a:b] ; per current path evaluation syntax
b/[:a::b] ; with a twist
compose b/[(a:b)] ; COMPOSE has to know about range notation
compose b/[(a):(b)] ; COMPOSE doesn't know about range notation
Thanks for the conversation on this!
-- Gregg
[31/32] from: greggirwin:mindspring at: 20-Oct-2003 9:39
Hi Volker,
VN> Intersting:
>>> 'b/1:2/1:2
VN> == b/1:02/1:02
VN> a valid path. with time-values.
VN> now when i do a spreadsheed-dialect i could use rebol-syntax directly.
VN> with up to 60 columns :)
I do kind of like the idea for a spreadsheet dialect. Have to think
about how you could catch out-of-range errors. By extending the time!
values to use minutes, you have a 3-D worksheet. :)
-- Gregg
[32/32] from: robert:muench:robertmuench at: 21-Oct-2003 21:56
On Mon, 20 Oct 2003 18:50:35 +1300, A J Martin <[AJMartin--orcon--net--nz]>
wrote:
> a/5..10
I like this one. Robert
Notes
- Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted