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

REBOL Enhancement Proposals (REPs)

 [1/37] from: geza67::freestart::hu at: 26-Sep-2001 0:00


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]

 [2/37] from: ammoncooke:yaho:o at: 25-Sep-2001 17:53


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

 [3/37] from: ryanc:iesco-dms at: 25-Sep-2001 16:57


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
<<quoted lines omitted: 39>>
> [rebol-request--rebol--com] with "unsubscribe" in the > subject, without the quotes.
-- Ryan Cole Programmer Analyst www.iesco-dms.com 707-468-5400

 [4/37] from: tim:johnsons-web at: 25-Sep-2001 18:18


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
<<quoted lines omitted: 7>>
> circumstances. > 'Select makes quick work of such situations well enough, without strange animals.
Additionally: you can oftentimes use 'pick to achive parenthesizing access
>> FieldNames: head FieldNames
== ["Changes" "User Name" "Login" "Password" "Date Modified"]
>> a: 1
== 1
>> b: 3
== 3
>>pick FieldNames (a + b)
== "Password" I'm really Eagle-Eyed (far-sighted) and I like using 'pick with code that is oft-maintained or just forming up.
> I do like auto binding set idea though.
Yup. Me too.
> --Ryan > Geza Lakner MD wrote:
<<quoted lines omitted: 68>>
> [rebol-request--rebol--com] with "unsubscribe" in the > subject, without the quotes.
-- Tim Johnson <[tim--johnsons-web--com]> http://www.johnsons-web.com

 [5/37] from: joel:neely:fedex at: 25-Sep-2001 18:50


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) ? >
REBOL Technologies has already used the concept of REP ...
> 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" ? >
... and some of them have come directly from discussions on this mailing list in the past couple of years. As an example, the /SKIP refinement to SORT and SELECT was proposed and discussed on this list prior to its addition to REBOL/Core. Personally speaking, I'm always eager to hear from others on the list about ideas for ongoing improvement. Whether the discussion on the list reaches consensus (or not), and whether RT agrees to immediate implementation (or not), I'm usually stimulated to think hard about the issues raised and feel that I benefit from the process!
> REBOL Enhancement Proposals > >
<<quoted lines omitted: 14>>
> but eliminates setting intermediate working words and using > them only once - i.e. in the creation of a dynamic path value.
I proposed this one about a year ago. I'm still of the opinion that it would help reduce namespace clutter and would simplify an area of the notation that seems remarkably clumsy compared to the clean elegance of many other parts of REBOL.
> #2 "Polymorph" multiple 'SET > SET now expects a word to set. Words in objects seem to be
<<quoted lines omitted: 5>>
> The logical and straightforward way unfortunately does not work: > set [a/b/c d/e] [1 2]
Just for clarification... Could you explain why you would prefer the above SET expression to the following? a/b/c: 1 d/e: 2 -jn- -- Stocks have reached what looks like a permanently high plateau. -- Irving Fisher, Professor of Economics, Yale University, 1929 joel_dot_neely_at_FIX_PUNCTUATION_fedex_dot_com

 [6/37] from: joel:neely:fedex at: 25-Sep-2001 19:04


Hi, again, Geza, Further clarification... Joel Neely wrote:
> Geza Lakner MD wrote: > >
<<quoted lines omitted: 16>>
> to the following? > a/b/c: 1 d/e: 2
I'm not necessarily disagreeing, but interested in your rationale. I tend to use objects in a more "encapsulated" fashion, in which the methods of the function are responsible for modifying the attributes of the object, in constrast to a "c-struct" fashion, in which other code is free to go in and manipulate the content of the object. Just a question of style, but I'm interested in your views. -jn- -- There is no reason anyone would want a computer in their home. -- Ken Olson, DEC, 1977 joel>FIX>PUNCTUATION>dot>neely>at>fedex>dot>com

 [7/37] from: allenk:powerup:au at: 26-Sep-2001 18:05


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/

 [8/37] from: deadzaphod:flyingparty at: 26-Sep-2001 1:39


> 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
what's wrong with set bind [ user pass ] in config 'self 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.
if there were a lot of fields (rather than the two in this example) the existing syntax is shorter. The only time there is a significant advantage to the REP is if you want to set words in several objects at once. For those situations I recommend using something like the function below in place of 'bind... bind-with: func [ words obj-set /copy ] [ if copy [ words: system/words/copy/deep words ] foreach obj obj-set [ bind words in obj 'self ] return words ] I wrote this around a year ago when I needed something like a context hierarchy in one of my scripts. - Cal Dixon

 [9/37] from: allenk:powerup:au at: 26-Sep-2001 21:49


----- 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
REBOL/Command
> > and the blocks it returns . ["username" "userpass"] > >
<<quoted lines omitted: 4>>
> what's wrong with > set bind [ user pass ] in config 'self pick db-port 1
Thanks Cal, A solution to my problem (which I should have remembered), but seems a little verbose. Perhaps a general set-in or bind-with mezzanine could be added. (view has number of set- functions for setting word in sub-objects of a face easier, so a more general one wouldn't go a miss) Do you think the following change would have value? If IN could take either word! or a block of words. we could use set in aface/font [color size] [200.0.0 12] as well as the current singular usage set in aface/font 'color 200.0.0 Cheers, Allen K

 [10/37] from: al:bri:xtra at: 27-Sep-2001 0:51


> REBOL Enhancement Proposals > > > #1 Immediate (paren) values in paths
It also would be nice for string! values as well: a/"Bee"/c I think pekr was the first to suggest it. Also, a path! value could have more of the features of a block! value, as they are similar. Andrew Martin ICQ: 26227169 http://zen.scripterz.org

 [11/37] from: joel:neely:fedex at: 26-Sep-2001 2:48


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 .
<<quoted lines omitted: 10>>
> rather than trying to remember their index numbers to pick > them from a block.
Good point. I was also interested whether anyone would mention the old classic:
>> fee == "fee" >> fie == "fie" >> set [fee fie] reduce [fie fee] == ["fie" "fee"] >> fee == "fie" >> fie == "fee"
as an argument for a "multiple assignment" pattern without use of extra names. Anyway... Here's my quick, sleep-deprived hack on the subject; I'm sure it can be improved, especially in the error-handling area! (Ladislav? You're really skillful at such things...) a: make object! [ b: make object! [ c: "abc" ] ] d: make object! [ e: "de" ] f: "something" bp: [a/b/c d/e f] pset: function [ pp [block!] vv [block!] ][ x actions ][ x: make block! length? pp actions: reduce [ path! [append/only x to-set-path first pp] lit-path! [append/only x to-set-path first pp] set-path! [append/only x first pp] word! [append/only x to-set-word first pp] get-word! [append/only x to-set-word first pp] lit-word! [append/only x to-set-word first pp] set-word! [append/only x first pp] ] while [not empty? pp] [ switch/default type? first pp actions [ make error! append "Unexpected type: " mold pp ] pp: next pp either empty? vv [ append x none ][ append x first vv vv: next vv ] ] do x exit ] which behaves as follows:
>> do %pset.r >> source a source d print f
a: make object! [ b: make object! [ c: "abc" ] ] d: make object! [ e: "de" ] something
>> pset bp ["yes" "no" "maybe"] source a source d print f
a: make object! [ b: make object! [ c: "yes" ] ] d: make object! [ e: "no" ] maybe
>> pset bp [1] source a source d print f
a: make object! [ b: make object! [ c: 1 ] ] d: make object! [ e: none ] none Feedback/corrections/improvements welcomed!
> See some past REPs at http://www.rebolforces.com/archive/rep/ >
OBTW, Allen, in case no-one has said so recently... Thanks very to you and to Chris for all your work in making REBOL Forces such a useful (and usable!) resource to the REBOL community! Three cheers! -jn- -- All I ask is a chance to prove that money can't make me happy. -- John Alan Belli joel+dot+neely+at+fedex+dot+FIX+PUNCTUATION+com

 [12/37] from: joel:neely:fedex at: 26-Sep-2001 3:02


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]
== [a b c d e]
>> length? something
== 5 vs
>> something: []
== []
>> foreach item [a/b/c d/e] [append/only something :item]
== [a/b/c d/e]
>> length? something
== 2 Which, I'll admit, was quite a surprise to me! -jn- Andrew Martin wrote:
> > REBOL Enhancement Proposals > > > >
<<quoted lines omitted: 4>>
> value could have more of the features of a block! value, > as they are similar.
-- The hardest problem in computer science is finding a problem to solve your solution. -- Aaron Watters joel'dot'FIX'PUNCTUATION'neely'at'fedex'dot'com

 [13/37] from: ammoncooke:ya:hoo at: 26-Sep-2001 9:41


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

 [14/37] from: ammoncooke::yahoo at: 26-Sep-2001 9:19


----- 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> > >
<<quoted lines omitted: 12>>
> of the object. > Just a question of style, but I'm interested in your views.
The quick reason that I can see is this: z: [1 2] y: [a/b/c d/e] set y z I can see that type of a situation happening. Enjoy!! Ammon

 [15/37] from: rotenca:telvia:it at: 26-Sep-2001 18:06


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]
== true
>> to-block first [a/b/c]
== [a b c]
>> pick first [a/b/c] 1
== a
>> poke first [a/b/c] 2 'z
== a/z/c
> Which, I'll admit, was quite a surprise to me!
Also for me! --- Ciao Romano

 [16/37] from: rotenca:telvia:it at: 26-Sep-2001 18:32


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
At the end you will find my func 'set-all to make this kind of things. Waiting for bug/enhancement report... Writing it, I have found a little strange behaviour of standard set:
>> set [a:] 2
** Script Error: Invalid argument: a ** Where: do-boot ** Near: set [a:] 2 But:
>> set first [a:] 2
== 2 Here it is my function which should replace set in many (not all, /any is not present) situations: --- Ciao Romano ----------------- code ---------- Rebol[ Title: "set-all" Date: 26/09/01 Author: "Romano Paolo Tenca" Note: {not /any refinement} ] set-all: func [[catch] word [any-word! any-block!] value /local ret val] [ if any-word? :word [return set :word :value] if any[set-path? :word path? :word] [word: head insert/only copy [] first reduce [:word]] ret: make block! lenght? :word sin: func [x v][ reduce [either any-word? :x [to-set-word :x] [to-set-path :x] 'first reduce [:v]] ] throw-on-error [ while [not tail? word] [ x: first word either any-block? :value [ either tail? value [sin :x none][ val: first value value: next value ] append ret sin :x :val ][ either all [tail? next word] [ return do sin :x :value ][ do sin :x :value ] ] word: next :word ] reduce ret ] ] ;test aface: context[ font: context [color: 0 size: 150]] probe set-all [aface/font/color: aface/font/size a] [200.0.0 12 "string"] ?? aface probe set-all [b: 'c :d] [200.0.0 12 "string1"] probe set-all ['aface/font/color 'c :d] "string2" x: [aface/font/color: 'aface/font/size a] y: [100.0.0 5 "string3"] probe set-all x y ?? aface a: 1 set-all [a:] 2 ?? a set-all first [a:] 3 ?? a set-all first [a:] :do ?? a set-all first [a:] [:do] ?? a halt

 [17/37] from: lmecir:mbox:vol:cz at: 26-Sep-2001 20:28


Hi Ryan,
> 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 do agree with you. The introduction of: a/(1 + 1) to Rebol would break the rule stating, that #"(" and #")" are delimiters, which may really turn Rebol inside out.
> 'Select makes quick work of such situations well enough, without strange
animals. OTOH, the SELECT way doesn't work in all circumstances where paths are needed. Summary: if the "delimiter rule" breaking is not acceptable for Rebol, there must be another simple enough way to do this. I wrote a DO-PATH function, which at least summarizes the advantages of such approach. Regards Ladislav

 [18/37] from: al:bri:xtra at: 27-Sep-2001 7:44


Ammon asked:
> Clarify a little, please. Wouldn't that allow you to use Path! on a block
using values rather than an index? It will enable the direct use of more interesting values in a path! datatype that been typed in, like string! and paren! datatypes. Andrew Martin ICQ: 26227169 http://zen.scripterz.org

 [19/37] from: al:bri:xtra at: 27-Sep-2001 7:41


Joel wrote:
> I was recently startled into believing that they're more than similar...
That's right. Path! values are stored like block! values and I think they deserve to have more of the features of a block, like being able to have string! and paren! values between slashes. Like: b: first [a/"a test"/(12 + i)] Andrew Martin ICQ: 26227169 http://zen.scripterz.org

 [20/37] from: lmecir:mbox:vol:cz at: 27-Sep-2001 0:21


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) :-)

 [21/37] from: al:bri:xtra at: 27-Sep-2001 15:18


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! Yes, that's right. After all, a path! is much like a block!. But it would still be nice to be able write in a script: a/"a test"/(12 + i) directly. It should just require a parser change, I think. Andrew Martin ICQ: 26227169 http://zen.scripterz.org

 [22/37] from: joel:neely:fedex at: 26-Sep-2001 18:17


Hi, Ladislav and all, Ladislav Mecir wrote:
> Hi Andrew, > they actually "have" such feature:
<<quoted lines omitted: 4>>
> :b ; == a/"a test"/(12 + i) > :-)
Well... One may be able to make a value of datatype PATH! with that "spelling", but it doesn't quite have the semantics one would hope/expect. ;-)
>> bb: make block! 10
== []
>> repeat i 10 [append bb i * i - i]
== [0 2 6 12 20 30 42 56 72 90]
>> bp: make path! 2
==
>> append :bp 'bb
== bb
>> i: 0
== 0
>> insert/only tail :bp first [(i + 1)]
==
>> :bp
== bb/(i + 1)
>> bp
** Script Error: Invalid path value: i + 1 ** Near: bp
>> i + 1
== 1 So here's an open puzzle/challenge/question: 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? That is, the equivalent of the Perl for (my $i = 1; $i < $#a; ++$i) { $a[$i] = ($a[$i-1] + $a[$i] + $a[$i+1])/3; } or the Language Which Must Not B Named /* assuming double a[N]; */ for (int i = 1; i < sizeof(a)/sizeof(double) - 2; ++i) { a[i] = (a[i-1] + a[i] + a[i+1])/ 3.0; } (other languages may be imagined... ;-) One could, of course, define "simplest" in a variety of interesting ways: shortest overall code, fewest variables, fewest subexpressions, etc. A related issue would be to identify the fastest solution. -jn- -- Heavier-than-air flying machines are impossible. -- Lord Kelvin, president, Royal Society, 1895 joel#dot#neely#at#fedex#dot#FIX#PUNCTUATION#com

 [23/37] from: g:santilli:tiscalinet:it at: 27-Sep-2001 15:37


Andrew Martin wrote:
> b: first [a/"a test"/(12 + i)]
Actually,
>> to-path [word "string" [block] (whatever)]
== word/"string"/[block]/(whatever) It's just that the scanner is not able to parse that beast. However it mostly works:
>> block: ["One" 1 "Two" 2]
== ["One" 1 "Two" 2]
>> p: to-path [block "One"]
== block/"One"
>> p
== 1 and:
>> block: [(paren) "does this"]
== [(paren) "does this"]
>> p: to-path [block (paren)]
== block/(paren)
>> p
== "does this" My 2 cents, Gabriele. -- Gabriele Santilli <[giesse--writeme--com]> - Amigan - REBOL programmer Amiga Group Italia sez. L'Aquila -- http://www.amyresource.it/AGI/

 [24/37] from: greggirwin:starband at: 27-Sep-2001 10:18


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

 [25/37] from: lmecir:mbox:vol:cz at: 27-Sep-2001 17:00


Hi Andrew, ...snip...
> It should just require a parser change, I think. > > Andrew Martin > ICQ: 26227169 http://zen.scripterz.org
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! :-)

 [26/37] from: lmecir:mbox:vol:cz at: 27-Sep-2001 18:35


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?

 [27/37] from: al:bri:xtra at: 28-Sep-2001 4:57


> > 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
seems to be no reason why this shouldn't be implemented! The datatype of (1 + 2)/(2 + 1) should be path! The datatype of (1 + 2) / (2 + 1) should be integer! Note the space around the operator. Andrew Martin In complete agreement... ICQ: 26227169 http://zen.scripterz.org

 [28/37] from: joel:neely:fedex at: 27-Sep-2001 12:14


Hi, Ladislav, Ladislav Mecir wrote:
> Hi Joel, > here you have got my trial:
<<quoted lines omitted: 10>>
> > } > >
Yes, AFAICT. It even agrees with uSoft XL! ;-) What looked suspicious to you? -jn- -- This sentence contradicts itself -- no actually it doesn't. -- Doug Hofstadter joel<dot>neely<at>fedex<dot>com

 [29/37] from: al:bri:xtra at: 28-Sep-2001 5:32


Joel wrote:
> 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? >> I think this approach gives the correct result:
>> b: [1 2 3 4 5 6 7 8 9 10]
== [1 2 3 4 5 6 7 8 9 10]
>> c: []
== []
>> i: b
== [1 2 3 4 5 6 7 8 9 10]
>> forall i [t: copy/part i 3 if 3 = length? t [append/only c t]]
== []
>> c
== [[1 2 3] [2 3 4] [3 4 5] [4 5 6] [5 6 7] [6 7 8] [7 8 9] [8 9 10]]
>> map c func [t][(t/1 + t/2 + t/3) / 3]
== [2 3 4 5 6 7 8 9] Andrew Martin ICQ: 26227169 http://zen.scripterz.org

 [30/37] from: lmecir:mbox:vol:cz at: 27-Sep-2001 19:51


> > > > BTW, is your Perl implementation correct?
<<quoted lines omitted: 8>>
> What looked suspicious to you? > -jn-
I don't know Perl enough, but the difference between: ;$i < $#a; for Perl and the C ; i < sizeof(a)/sizeof(double) - 2; looked suspicious to me.

 [31/37] from: joel:neely:fedex at: 27-Sep-2001 13:28


Hi, Andrew, Andrew Martin wrote:
> Joel wrote: > > Given a block of numbers, what's the simplest way in REBOL to
<<quoted lines omitted: 14>>
> >> map c func [t][(t/1 + t/2 + t/3) / 3] > == [2 3 4 5 6 7 8 9]
That's certainly a nice entry to the discussion; thanks! Note that there is a subtle difference between the result of code and the results of the other versions. Since the others (including the "spec-by-example" descriptions) do an in-place update, the effects of previous smoothing propagates through the collection of values. OTOH, if all values are copied before any smoothing, the propagation doesn't happen. Just being nit-picky for the sake of conversation... ;-) -jn- -- This sentence contradicts itself -- no actually it doesn't. -- Doug Hofstadter joel<dot>neely<at>fedex<dot>com

 [32/37] from: joel:neely:fedex at: 27-Sep-2001 13:38


Hi, Ladislav, Ladislav Mecir wrote:
> > > > > > BTW, is your Perl implementation correct?
<<quoted lines omitted: 15>>
> ;$i < $#a; for Perl and the C ; i < sizeof(a)/sizeof(double) - 2; > looked suspicious to me.
The bug is in my composed-at-the-keyboard version for TLWMNBN. Both Perl and TLWMNBN use zero-origin indexing, which means that an array of length N has indices 0 .. N-1. This, in turn means that the "interior" elements have indices 1 .. N-2. The Perl construct $#a provides the last index of the array @a, so from 1 while < $#a really is correct. The other version should have read (in part) ... < sizeof(a)/sizeof(double) - 1 ... (or the equivalent ... <= sizeof(a)/sizeof(double) - 2 ... meaning that my typo was either the substitution of "2" for "1" or the omission of "=" ;-) You can draw your own conclusions about which of Perl and TLWMNBN I spend more time in (or pay more attention to) these days! Thanks for catching the error! -jn- -- This sentence contradicts itself -- no actually it doesn't. -- Doug Hofstadter joel<dot>neely<at>fedex<dot>com

 [33/37] from: al:bri:xtra at: 28-Sep-2001 8:22


Joel pointed out:
> Note that there is a subtle difference between the result of code and the
results of the other versions. Since the others (including the spec-by-example descriptions) do an in-place update, the effects of previous smoothing propagates through the collection of values. OTOH, if all values are copied before any smoothing, the propagation doesn't happen.
> Just being nit-picky for the sake of conversation... ;-)
That's right. I deliberately avoided the inplace update because I don't think it was intended to be that way in the problem description. :-) Andrew Martin ICQ: 26227169 http://zen.scripterz.org

 [34/37] from: giesse:writeme at: 28-Sep-2001 12:57


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!
Well...
>> 1+1
** Syntax Error: Invalid integer -- 1+1 ** Near: (line 1) 1+1 So... :-) Regards, Gabriele. -- Gabriele Santilli <[giesse--writeme--com]> - Amigan - REBOL programmer Amiga Group Italia sez. L'Aquila -- http://www.amyresource.it/AGI/

 [35/37] from: lmecir:mbox:vol:cz at: 30-Sep-2001 23:42


Hi,
> 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! > Well...
<<quoted lines omitted: 4>>
> Regards, > Gabriele.
I didn't try to tell that I disliked it. I only wanted to know, if there is anyone who prefers to preserve the backwards compatibility in this case and require the expression to yield 1. I would prefer the expression to yield an error and the #"(" and #")" characters to have less delimiting properties than they are having now. What about other delimiters? Any opinions on the subject?

 [36/37] from: g:santilli:tiscalinet:it at: 1-Oct-2001 13:52


Ladislav Mecir wrote: [paths, delimiters...]
> Any opinions on the subject?
I think the scanner should at least recognize strings in paths. Blocks and parens are probably less useful, but if that does not create problems... why not. Also parens can be used for evaluation as proposed, so maybe it would be a good idea. My $0.02, Gabriele. -- Gabriele Santilli <[giesse--writeme--com]> - Amigan - REBOL programmer Amiga Group Italia sez. L'Aquila -- http://www.amyresource.it/AGI/

 [37/37] from: giesse:writeme at: 1-Oct-2001 13:51


Ladislav Mecir wrote: [paths, delimiters...]
> Any opinions on the subject?
I think the scanner should at least recognize strings in paths. Blocks and parens are probably less useful, but if that does not create problems... why not. Also parens can be used for evaluation as proposed, so maybe it would be a good idea. My $0.02, Gabriele. -- Gabriele Santilli <[giesse--writeme--com]> - Amigan - REBOL programmer Amiga Group Italia sez. L'Aquila -- http://www.amyresource.it/AGI/

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