[REBOL] Re: REBOL Enhancement Proposals (REPs)
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
> 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.
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:
>
> > 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]
> >
> > --
> > To unsubscribe from this list, please send an email to
> > [rebol-request--rebol--com] with "unsubscribe" in the
> > subject, without the quotes.
>
> --
>
> Ryan Cole
> Programmer Analyst
> www.iesco-dms.com
> 707-468-5400
>
> --
> To unsubscribe from this list, please send an email to
> [rebol-request--rebol--com] with "unsubscribe" in the
> subject, without the quotes.
--
Tim Johnson <[tim--johnsons-web--com]>
http://www.johnsons-web.com
