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

The reaseon for having SERIES?

 [1/7] from: fuka::fuxoft::cz at: 5-Jan-2003 14:22


What is the reason for having SERIES type in Rebol? I understand what the series are for but it seems to me that exact same things can be done using normal strings. Having series type when you have string seems to me like having negative-integer type when you have integer (i.e. redundant)... -- Frantisek Fuka (yes, that IS my real name) (and it's pronounced "Fran-tjee-shek Foo-kah") ---------------------------------------------------- My E-mail: [fuka--fuxoft--cz] My Homepage: http://www.fuxoft.cz My ICQ: 2745855

 [2/7] from: joel:neely:fedex at: 5-Jan-2003 7:55


Hi, Frantisek, Frantisek Fuka wrote:
> What is the reason for having SERIES type in Rebol? I understand > what the series are for but it seems to me that exact same things > can be done using normal strings. Having series type when you have > string seems to me like having negative-integer type when you have > integer (i.e. redundant)... >
To stay with your analogy as best I can, I'd flip the example around; the REBOL types for numeric data include: NUMBER! INTEGER! DECIMAL! so that, e.g., if you specify something like nexamp: func [a [number!] ... then you will be able to evaluate nexamp 1 ... as well as nexamp 3.14 ... because NUMBER! subsumes both INTEGER! and DECIMAL! into one abstract pseudo-type. Now to your question: the REBOL type system includes (in part) the SERIES! family, which is the most general type of ordered structure that REBOL supports. But look at the family tree: SERIES! ANY-STRING! STRING! FILE! URL! EMAIL! ... ANY-BLOCK! BLOCK! LIST! HASH! so that any operation that can be applied to a SERIES! value can be applied to any of the specific types underneath. On the other hand, there are operations that can be applied to an ANY-STRING! value (such as UPPERCASE) that make no sense when applied to an ANY-BLOCK! value. This hierarchy allows us to conveniently/compactly express exactly what types (or sets of types) we expect to find used in various settings, without having to provide an exhaustive list in every case: both-ends: func [s [series!]] [ join copy/part s 1 last s ] which behaves as
>> foo: [1 3 5 7 9]
== [1 3 5 7 9]
>> both-ends foo
== [1 9] is clearly applicable to anything under the SERIES! family tree, and it's nicer to write it as such than to have to specify both-ends: func [x [string! file! url! ... block! list! hash!] ... to make sure that all are included. Hope this helps! -jn-

 [3/7] from: fuka:fuxoft:cz at: 5-Jan-2003 15:17


Yes, I understand this, but I don't understand why there is ISSUE type in Rebol at all. It seems tu me that I can simply use STRING instead of ISSUE in all possible circumstances and functionality would be the same. Joel Neely wrote:
> Hi, Frantisek, > Frantisek Fuka wrote:
<<quoted lines omitted: 53>>
> Hope this helps! > -jn-
-- Frantisek Fuka (yes, that IS my real name) (and it's pronounced "Fran-tjee-shek Foo-kah") ---------------------------------------------------- My E-mail: [fuka--fuxoft--cz] My Homepage: http://www.fuxoft.cz My ICQ: 2745855

 [4/7] from: rotenca:telvia:it at: 5-Jan-2003 19:01


Hi Frantisek,
> Yes, I understand this, but I don't understand why there is ISSUE type > in Rebol at all. It seems tu me that I can simply use STRING instead of > ISSUE in all possible circumstances and functionality would be the same.
At least:
>> to-integer "ff"
** Script Error: Invalid argument: ff ** Where: to-integer ** Near: to integer! :value
>> to-integer #ff
== 255 --- Ciao Romano

 [5/7] from: g:santilli:tiscalinet:it at: 5-Jan-2003 19:31


Hi Frantisek, On Sunday, January 5, 2003, 3:17:33 PM, you wrote: FF> Yes, I understand this, but I don't understand why there is ISSUE type FF> in Rebol at all. It seems tu me that I can simply use STRING instead of FF> ISSUE in all possible circumstances and functionality would be the same. Yes, unless you are designing a dialect. You could use strings for files or URLs, but having a specific datatypes makes VID able to distinguish a label from the path to an image. Different datatypes give you more expressivity; you can say more by typing less, and the code is still very readable (perhaps even more readable). Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amigan -- AGI L'Aquila -- REB: http://web.tiscali.it/rebol/index.r

 [6/7] from: joel:neely:fedex at: 5-Jan-2003 15:13


Hi, Frantisek, Frantisek Fuka wrote:
> Yes, I understand this, but I don't understand why there is ISSUE > type in Rebol at all. It seems tu me that I can simply use STRING > instead of ISSUE in all possible circumstances and functionality > would be the same. >
I was responding to your question about SERIES! and STRING! (as in the subject line). As for ISSUE! ... well, that's another issue ;-) to which others have responded. To be honest, I've been using REBOL for a few years now, and have almost never had a need for the ISSUE! type myself. But others find it useful sometimes. One cute little hack comes to mind; that of using ISSUE! as a way to save two keystrokes to represent individual character values:
>> join "" #A
== "A"
>> join "" #"A"
== "A"
>> equal? join "" #A join "" #"A"
== true Hardly the most urgent programming problem I've ever seen! ;-) -jn-

 [7/7] from: fuka:fuxoft:cz at: 5-Jan-2003 23:48


Joel Neely wrote:
> Hi, Frantisek, > Frantisek Fuka wrote:
<<quoted lines omitted: 6>>
> the subject line). As for ISSUE! ... well, that's another issue ;-) > to which others have responded.
Ah, sorry! It should've been "ISSUES" in the subject line, not "SERIES". And "reason", not "reaseon"... :) -- Frantisek Fuka (yes, that IS my real name) (and it's pronounced "Fran-tjee-shek Foo-kah") ---------------------------------------------------- My E-mail: [fuka--fuxoft--cz] My Homepage: http://www.fuxoft.cz My ICQ: 2745855

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