Allow <expr> <identifier> <expr> call Syntax

[back2dos]

IIRC, Scala allows you to write <expr> <identifier> <expr> to denote <expr>.<identifier>(<expr>). With support for this, #17 would be easy to solve. Just have using RaxeWords with this:

extern class RaxeWords {
   static public inline function and(a:Bool, b:Bool):Bool return a && b;
   static public inline function or(a:Bool, b:Bool):Bool return a || b;
   static public inline function is<T>(a:A, b:A):Bool return a == b;
}

And there you go: foo and bar becomes foo.and(bar) which is turned to foo && bar. Whether or not RaxeWords is used in every file is a matter of taste.

[deathbeam]

This is nice addition and I really like it. But it do not goes well with Raxe philisophy No runtime library requirement.

[back2dos]

I don't understand.

1. The syntax in general has nothing to do with any library whatsoever. It is just an alternative syntax for calls with a single argument.
2. Using this to implement and and or does not require a "runtime library". The RaxeWords class is a pure compile time construct.

[deathbeam]

I mean that right now, when you compile Raxe to Haxe, you can even run it from try.haxe.org if you are not using any external libraries. So compiled Raxe source do not need any external library right now.

[NobbZ]

So it will after implementing this proposal, at least that's how I understand it, as syntactic sugar.

Tomas Slusny notifications@github.com schrieb am Do., 08.10.2015, 23:15:

I mean that right now, when you compile Raxe to Haxe, you can even run it from try.haxe.org if you are not using any external libraries. So compiled Raxe source do not need any external library right now.

— Reply to this email directly or view it on GitHub https://github.com/nondev/raxe/issues/20#issuecomment-146688348.

[sledorze]

that would be very pleasing! And of course, not runtime lib required, it's compile time resolution :)

[kobi2187]

How will the parser know what to do? I agree it is nice to define prefix, infix, or postfix style functions. foo and bar => foo.and.bar ? => foo(and(bar)) ? => foo.and(bar) ? maybe others, how will it know which to choose?

def infix and (foo, bar) # foo and bar
def postfix times ( num ) # 3 times

may work and be more explicit about what you're trying to do. so no guesses. but then parser will have to have lists of functions, number of arguments to expect, and the way they're meant to be used. In other words, it needs to understand some of the code. I think that right now, it's just a syntax replacement in parser level. though maybe that's the next stage

[back2dos]

I think this kind of complicates things and is not quite what I have proposed. Both of these are prefix functions:

foo.and(bar)
foo and bar

The latter is just a different notation for the same thing, to avoid death by parentheses. If any ambiguity is introduced, it is in cases like foo and bar or baz, which could mean foo.and(bar.or(baz)) or foo.and(bar).or(baz). I think we should shamelessly steal from Scala here. Any insights @sledorze might be able to share?

[sledorze]

@deathbeam @back2dos maybe this would shed some lights: http://stackoverflow.com/questions/5592642/when-to-use-parenthesis-in-scala-infix-notation/5597154#5597154