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

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