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::yahoo 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:yaho:o 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:y:ahoo 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