Re: Small feature request for future EU versions

new topic     » goto parent     » topic index » view thread      » older message » newer message

On Sun, 17 Oct 2004 00:24:23 -0700, rudy toews
<guest at RapidEuphoria.com> wrote:

>> Derek Parnell wrote:
>> > Yes, this is going to be survival-of-the-fitest game, with lots
>> > of variants vying for attention.
>please don't go off in different directions like pieces of a bomb.
>communicate with each other
FWIW, new operators are not actually needed, it is quite easy to
greatly improve the language using the current ones.

Taking the if <expr> then example, the interpreter should realise that
<expr> must deliver a boolean result (or crash), in other words map

e1<e2 to compare(e1,e2)=-1
e1<=e2 to compare(e1,e2)!=1
e1=e2 to equal(e1,e2),
e1!=e2 to not equal(e1,e2),
e1>=e2 to compare(e1,e2)!=-1
e1>e2 to compare(e1,e2)=1

Of course, it does not need to do this if e1 and e2 are both atoms.

Taking this a step further "if <e1> and <e2> then" must also deliver a
boolean result, which means the "need" for a boolean result must be
propagated into e1 and e2. The same is true for all the other
operators (not, unary minus, +, -, *, /, or, xor), and the same logic
applies to while, for, subscript, and slice expressions, but not to
assignments, constants, or parameters. If this all sounds horribly
complicated, don't worry, in practice it's not. I already have this
working in Posetf blink)

Regards,
Pete

new topic     » goto parent     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu