From: ZB on
Dnia 30.05.2010 Alexandre Ferrieux <alexandre.ferrieux(a)gmail.com> napisa�/a:

> Here is the corrected code. Tell me what's not satisfactory in your
> eyes (apart from the two aforementioned digressions from the initially
> wanted syntax):

It looks OK to me - see my (first) question to Donal... maybe he knows
something, that I'm missing?
--
Zbigniew
From: Donal K. Fellows on
On 30/05/2010 21:52, ZB wrote:
> 1. But, actually, how can I met such problem, when evalThis procedure
> is doing analysis only of my expressions, not going any "deeper"?

I don't quite understand what you're asking here. Please clarify.

> 2. Even, if so - did you use, for instance, single and double underscore?
> I think, it can be good replacement for these "arrows".

I don't like underscores. YMMV. :-)

Donal.
From: ZB on
Dnia 31.05.2010 Donal K. Fellows <donal.k.fellows(a)manchester.ac.uk> napisa�/a:

>> 1. But, actually, how can I met such problem, when evalThis procedure
>> is doing analysis only of my expressions, not going any "deeper"?
>
> I don't quite understand what you're asking here. Please clarify.

You wrote:

#v+
Your big issue is going to be dealing with existing code which uses -> and
<- for other purposes. For example, I use -> in [regexp] quite a bit as the
variable name for the whole-string match where I only really want the
substring matches...
#v-

Clarify, please. How actually can I meet such problem, while using the
"arrow-shaped quasi-operators", in the procedure created by Alexandre?
Any example?
--
Zbigniew
From: Alexandre Ferrieux on
On May 31, 12:23 pm, ZB <zbTHIS...(a)ispid.THIS-NOcom.pl> wrote:
> Dnia 30.05.2010 Alexandre Ferrieux <alexandre.ferri...(a)gmail.com> napisa³/a:
>
> > Here is the corrected code. Tell me what's not satisfactory in your
> > eyes (apart from the two aforementioned digressions from the initially
> > wanted syntax):
>
> It looks OK to me - see my (first) question to Donal... maybe he knows
> something, that I'm missing?

Oh, simply that the brute-force matching of "<-" in the code
necessarily comes with its share of quoting/escaping hell, in case you
have real strings with <- which are not supposed to be substituted
with [pop _stack]. I tend to react to this with a yawn, knowing that
when the problem arises, I'll just store the constant in a global var
and get away with it...

Bottom line: new syntax done at script level is very easy unless you
have very strict performance requirements; it's extremely flexible,
and needs zero consensus.
New syntax in the core has the exact opposite features ;-)

-Alex
From: ZB on
Dnia 31.05.2010 Alexandre Ferrieux <alexandre.ferrieux(a)gmail.com> napisa�/a:

> Bottom line: new syntax done at script level is very easy unless you
> have very strict performance requirements; it's extremely flexible,
> and needs zero consensus.

Of course, the strongest advantage is, that it can be used instantly... :)
--
Zbigniew