REBOL Enhancement Proposals (REPs)

Hello REBOLers, Why wouldn't we collect - following the path of Python Enhancement Proposals i.e. PEPs - REBOL Enhancement Proposals (REPs) ? Some of us certainly sent ideas to RT's feedback but why couldn't we share and discuss these information before transmitting it to RT's "magic cauldron" ? Let me start the row with my 2 (really two :-) ) cents : REBOL Enhancement Proposals =========================== #1 Immediate (paren) values in paths It would be a very nice and elegant construct if paths may contain immediately evaluated paren expressions yielding path fragments, not only words: e.g. a: [1 2 3] and instead of: b: 2 probe a/:b this: probe a/(1 + 1) or with a twist: probe a/(b) I think that this modification is not simply a syntactic sugar but eliminates setting intermediate working words and using them only once - i.e. in the creation of a dynamic path value. #2 "Polymorph" multiple 'SET SET now expects a word to set. Words in objects seem to be buried deep, being not really suitable for an elegant multiple set operation: e.g. a: context [ b: context [c: none]] d: context [ e: none] The logical and straightforward way unfortunately does not work: set [a/b/c d/e] [1 2] The current method to bind a word in an object to a value is IMHO awkward and distorts code readability thus expressiveness: set reduce [(in a/b 'c) (in d 'e)] [1 2] -- Best regards, Geza Lakner MD mailto:[geza67--freestart--hu]

I full heartedly agree with both proposals! :D BUT I think if we do this we might want to create a new ML to discuss such things on. Only because of the high volume of mail that it might generate. OTH it would probably be extremely informative to some of us less experienced REBOLers. ;D Enjoy!! Ammon

The parens in paths idea has come up before and I really liked it then. Although now I see it as asking alot, and maybe too much from the REBOL interpeter. I also now think it tends to break some simplicity of REBOL. The problem is that it introduces a really strange animal into REBOL, a sort of seriesword. If you look at all things in REBOL they breakup nicely into series or words. This seriesword would not because it would simultaniusly represent a series, a non series value, and a word itself. Somethings in REBOL appear as though they might do this, like urls, but actually they remain to the interpeter as mere words, and are broken up into a series by its scheme under certain circumstances. 'Select makes quick work of such situations well enough, without strange animals. I do like auto binding set idea though. --Ryan Geza Lakner MD wrote:

> Hello REBOLers, > Why wouldn't we collect - following the path of Python Enhancement > [rebol-request--rebol--com] with "unsubscribe" in the > subject, without the quotes.

On Tue, Sep 25, 2001 at 04:57:45PM -0700, Ryan Cole wrote:

> The parens in paths idea has come up before and I really liked it then. Although > now I see it as asking alot, and maybe too much from the REBOL interpeter. I > circumstances. > 'Select makes quick work of such situations well enough, without strange animals.

>> FieldNames: head FieldNames

>> a: 1

>> b: 3

>>pick FieldNames (a + b)

> I do like auto binding set idea though.

> --Ryan > Geza Lakner MD wrote: > [rebol-request--rebol--com] with "unsubscribe" in the > subject, without the quotes.

Hi, Geza, Geza Lakner MD wrote:

> Hello REBOLers, > > Why wouldn't we collect - following the path of Python > Enhancement Proposals i.e. PEPs - REBOL Enhancement Proposals > (REPs) ? >

> Some of us certainly sent ideas to RT's feedback but why > couldn't we share and discuss these information before > transmitting it to RT's "magic cauldron" ? >

> REBOL Enhancement Proposals > > > but eliminates setting intermediate working words and using > them only once - i.e. in the creation of a dynamic path value.

> #2 "Polymorph" multiple 'SET > SET now expects a word to set. Words in objects seem to be > The logical and straightforward way unfortunately does not work: > set [a/b/c d/e] [1 2]

Hi, again, Geza, Further clarification... Joel Neely wrote:

> Geza Lakner MD wrote: > > > to the following? > a/b/c: 1 d/e: 2

Joel, I would find that REP handy, particularly when dealing with REBOL/Command and the blocks it returns . ["username" "userpass"] e.g config: context [user: pass: none offset: 0x0 color: grey] insert db-port [{SELECT User, Pass FROM Clients WHERE ClientID = 3}] set [config/user config/pass] pick db-port 1 This is more using the "c-struct" fashion as you mention, but when dealing with a lot of fields, I will make less errors when dealing with named elements from an object (or block) rather than trying to remember their index numbers to pick them from a block. Cheers, Allen K See some past REPs at http://www.rebolforces.com/archive/rep/

> I would find that REP handy, particularly when dealing with REBOL/Command > and the blocks it returns . ["username" "userpass"] > > e.g > config: context [user: pass: none offset: 0x0 color: grey] > insert db-port [{SELECT User, Pass FROM Clients WHERE ClientID = 3}] > set [config/user config/pass] pick db-port 1

> This is more using the "c-struct" fashion as you mention, but when dealing > with a lot of fields, I will make less errors when dealing with named > elements from an object (or block) rather than trying to remember their > index numbers to pick them from a block.

----- Original Message ----- From: "Cal Dixon" <[deadzaphod--flyingparty--com]> To: <[rebol-list--rebol--com]> Sent: Wednesday, September 26, 2001 6:39 PM Subject: [REBOL] Re: REBOL Enhancement Proposals (REPs)

> > I would find that REP handy, particularly when dealing with

> > and the blocks it returns . ["username" "userpass"] > > > what's wrong with > set bind [ user pass ] in config 'self pick db-port 1

> REBOL Enhancement Proposals > > > #1 Immediate (paren) values in paths

Hi, Allen and Geza and all, Allen Kamp wrote:

> I would find that REP handy, particularly when dealing with > REBOL/Command and the blocks it returns . > rather than trying to remember their index numbers to pick > them from a block.

>> fee == "fee" >> fie == "fie" >> set [fee fie] reduce [fie fee] == ["fie" "fee"] >> fee == "fie" >> fie == "fee"

>> do %pset.r >> source a source d print f

>> pset bp ["yes" "no" "maybe"] source a source d print f

>> pset bp [1] source a source d print f

> See some past REPs at http://www.rebolforces.com/archive/rep/ >

Hi, Andrew, I was recently startled into believing that they're more than similar...

>> something: []

>> foreach item [a/b/c d/e] [append something :item]

>> length? something

>> something: []

>> foreach item [a/b/c d/e] [append/only something :item]

>> length? something

> > REBOL Enhancement Proposals > > > > > value could have more of the features of a block! value, > as they are similar.

Clarify a little, please. Wouldn't that allow you to use Path! on a block using values rather than an index? Thanks!! Ammon

----- Original Message ----- From: "Joel Neely" <[joel--neely--fedex--com]> To: <[rebol-list--rebol--com]> Sent: Tuesday, September 25, 2001 5:04 PM Subject: [REBOL] Re: REBOL Enhancement Proposals (REPs)

<Snip> > > > of the object. > Just a question of style, but I'm interested in your views.

From: "Joel Neely" <[joel--neely--fedex--com]>

> I was recently startled into believing that they're more than > similar... >> any-block? first [a/b/c]

>> to-block first [a/b/c]

>> pick first [a/b/c] 1

>> poke first [a/b/c] 2 'z

> Which, I'll admit, was quite a surprise to me!

Hi, Ammon, Joel (and so on),

> The quick reason that I can see is this: > > z: [1 2] > y: [a/b/c d/e] > > set y z

>> set [a:] 2

>> set first [a:] 2

Hi Ryan,

> The parens in paths idea has come up before and I really liked it then.

> now I see it as asking alot, and maybe too much from the REBOL interpeter.

> 'Select makes quick work of such situations well enough, without strange

Ammon asked:

> Clarify a little, please. Wouldn't that allow you to use Path! on a block

Joel wrote:

> I was recently startled into believing that they're more than similar...

Hi Andrew, they actually "have" such feature: b: make path! 3 insert tail :b 'a insert tail :b "a test" insert/only tail :b first [(12 + i)] :b ; == a/"a test"/(12 + i) :-)

Ladislav pointed out:

> they actually "have" such feature: > > b: make path! 3 > insert tail :b 'a > insert tail :b "a test" > insert/only tail :b first [(12 + i)] > :b ; == a/"a test"/(12 + i)

Hi, Ladislav and all, Ladislav Mecir wrote:

> Hi Andrew, > they actually "have" such feature: > :b ; == a/"a test"/(12 + i) > :-)

>> bb: make block! 10

>> repeat i 10 [append bb i * i - i]

>> bp: make path! 2

>> append :bp 'bb

>> i: 0

>> insert/only tail :bp first [(i + 1)]

>> :bp

>> bp

>> i + 1

Andrew Martin wrote:

> b: first [a/"a test"/(12 + i)]

>> to-path [word "string" [block] (whatever)]

>> block: ["One" 1 "Two" 2]

>> p: to-path [block "One"]

>> p

>> block: [(paren) "does this"]

>> p: to-path [block (paren)]

>> p

Hi Joel, I love a puzzle, plus I need more console time with REBOL, being a newbie. << Given a block of numbers, what's the simplest way in REBOL to write a smoothing operation that averages each interior value (i.e., all but the first and last) with the two values on either side of it? >> My first whack is a direct translation of what you posted: smooth-interior: func [blk /local i] [ for i 2 (length? blk) - 1 1 [ change at blk i divide ((pick blk i - 1) + (pick blk i) + (pick blk i + 1)) 3 ] ] The "pick" and "change at" stuff is more verbose than direct element access by index. To try and simplify things, I broke out a sub-function and tried using next and back: avg-fore-back: func [blk] [ divide ((first back blk) + (first blk) + (first next blk)) 3 ] smooth-interior: func [blk /local i] [ for i 2 (length? blk) - 1 1 [ change at blk i avg-fore-back at blk i ] ] Next I moved the change at bit to the sub-function to see how I liked that: avg-fore-back: func [blk] [ change blk divide ((first back blk) + (first blk) + (first next blk)) 3 ] smooth-interior: func [blk /local i] [ for i 2 (length? blk) - 1 1 [ avg-fore-back at blk i ] ] Finally, I added other generic functions to see what that did for me: sum: func [values[any-block!]] [ either tail? values [0][add (first values) (sum next values)] ] avg: func [values[any-block!]] [ divide (sum values) (length? values) ] smooth-interior: func [blk /local i] [ for i 2 (length? blk) - 1 1 [ change at blk i avg copy/part at blk (i - 1) 3 ] ] At first I didn't like this because the call to avg virtually disappears, becoming indistinct as a separate function. BUT, if I read it as a sentence as if it were pseudo-code it "reads" very clearly. I think the first version would be the most familiar for people coming from other mainstream languages, but I think I like the last one the best. I'll have to spend some more time with it to be sure. One other advantage to it, is that it's easy to extend for more than 3 point averaging. smooth-interior: func [blk width[integer!] /local i wd-offset] [ wd-offset: to-integer ((width - 1) / 2) ; TBD Ensure width is odd for i (1 + wd-offset) ((length? blk) - wd-offset) 1 [ change at blk i avg copy/part at blk (i - wd-offset) width ] return head blk ] I know flexibility wasn't part of your puzzle, and I'm not a numerical analyst, or number theory kinda' guy, so I don't know how valuable that is but common sense tells me it could be useful. Thanks for the prompt to learn a little more! --Gregg

Hi Andrew, ...snip...

> It should just require a parser change, I think. > > Andrew Martin > ICQ: 26227169 http://zen.scripterz.org

Hi Joel, here you have got my trial: cfor [i: 1 b: at a 2 c: at a 3] [(length? a) - 1 > i] [ change at b i a/:i + b/:i + c/:i / 3 i: i + 1 ] CFOR is the function I defined in http://www.sweb.cz/LMecir/highfun.r BTW, is your Perl implementation correct?

> > It should just require a parser change, I think. > If we are in agreement that (1 + 2)/(2 + 1) shouldn't yield 1, then there

Hi, Ladislav, Ladislav Mecir wrote:

> Hi Joel, > here you have got my trial: > > } > >

Joel wrote:

> Given a block of numbers, what's the simplest way in REBOL to write a

>> b: [1 2 3 4 5 6 7 8 9 10]

>> c: []

>> i: b

>> forall i [t: copy/part i 3 if 3 = length? t [append/only c t]]

>> c

>> map c func [t][(t/1 + t/2 + t/3) / 3]

> > > > BTW, is your Perl implementation correct? > What looked suspicious to you? > -jn-

Hi, Andrew, Andrew Martin wrote:

> Joel wrote: > > Given a block of numbers, what's the simplest way in REBOL to > >> map c func [t][(t/1 + t/2 + t/3) / 3] > == [2 3 4 5 6 7 8 9]

Hi, Ladislav, Ladislav Mecir wrote:

> > > > > > BTW, is your Perl implementation correct? > ;$i < $#a; for Perl and the C ; i < sizeof(a)/sizeof(double) - 2; > looked suspicious to me.

Joel pointed out:

> Note that there is a subtle difference between the result of code and the

> Just being nit-picky for the sake of conversation... ;-)

Ladislav Mecir wrote:

> If we are in agreement that (1 + 2)/(2 + 1) shouldn't yield 1, then there > seems to be no reason why this shouldn't be implemented!

>> 1+1

Hi,

> Ladislav Mecir wrote: > > > If we are in agreement that (1 + 2)/(2 + 1) shouldn't yield 1, then

> > seems to be no reason why this shouldn't be implemented! > Well... > Regards, > Gabriele.

Ladislav Mecir wrote: [paths, delimiters...]

> Any opinions on the subject?

Ladislav Mecir wrote: [paths, delimiters...]

> Any opinions on the subject?