Would such a feature be possible, or is it something that should be avoided at all costs?
Just to make sure, I'm not necessarily talking operator overloading here.
For instance, i've on occation wanted to have
'**(double|int|string base,int|float power)
for doing powers of... stuff. Other things like setoperations, integration, etc... comes to mind.
I realise that interrest in this might be infinitly small - just probing.
Adding of new operators currently requires modifying of language.yacc (and most likely lexer.h et al).
/ Henrik Grubbström (Lysator)
Previous text:
2003-05-15 17:00: Subject: top level infix operators
Would such a feature be possible, or is it something that should be avoided at all costs?
Just to make sure, I'm not necessarily talking operator overloading here.
For instance, i've on occation wanted to have
'**(double|int|string base,int|float power)
for doing powers of... stuff. Other things like setoperations, integration, etc... comes to mind.
I realise that interrest in this might be infinitly small - just probing.
/ Peter Lundqvist (disjunkt)
Yes. If new operators are added we have to either hardcode their precedence, associativity etc, or introduce language constructs to control that. Personally I don't think it's worth a generic system with all it means in extra syntax to understand and various ambiguities and conflicts to resolve.
It's better to consider adding specific operators, I think. A power operator could be one, if there's sufficient interest. An alternative in that case is to extend the pow function to try lfuns if it's fed objects it doesn't understand. E.g. m_delete and random already have such things.
As for set operations, the existing `|, `&, `- etc are already used for that. Aren't those enough?
/ Martin Stjernholm, Roxen IS
Previous text:
2003-05-15 17:17: Subject: top level infix operators
Adding of new operators currently requires modifying of language.yacc (and most likely lexer.h et al).
/ Henrik Grubbström (Lysator)
I'd still like "8-bit" operators like ×, ·, ², ³.
/ Mirar
Previous text:
2003-05-15 19:38: Subject: top level infix operators
Yes. If new operators are added we have to either hardcode their precedence, associativity etc, or introduce language constructs to control that. Personally I don't think it's worth a generic system with all it means in extra syntax to understand and various ambiguities and conflicts to resolve.
It's better to consider adding specific operators, I think. A power operator could be one, if there's sufficient interest. An alternative in that case is to extend the pow function to try lfuns if it's fed objects it doesn't understand. E.g. m_delete and random already have such things.
As for set operations, the existing `|, `&, `- etc are already used for that. Aren't those enough?
/ Martin Stjernholm, Roxen IS
Hmm... how about having some sort of macro-ish construct for this?
SML has something similar (although I don't know the itty-bitty details). The idea is that you declare a token as an infix operator and assign it a function.
An example with a minimal pow operator:
int my_pow(int base, int power) { return pow(base,power); } infix "**" * my_pow; // or infix("**", 4 , my_pow); // 4 is how hard it binds in comparison to other operators
My thought is that this code
int foo = 2**3;
is expanded to
int foo = pow(2,3);
or rather the unoptimized case of
int foo = (pow(2,3));
/ Peter Lundqvist (disjunkt)
Previous text:
2003-05-15 19:38: Subject: top level infix operators
Yes. If new operators are added we have to either hardcode their precedence, associativity etc, or introduce language constructs to control that. Personally I don't think it's worth a generic system with all it means in extra syntax to understand and various ambiguities and conflicts to resolve.
It's better to consider adding specific operators, I think. A power operator could be one, if there's sufficient interest. An alternative in that case is to extend the pow function to try lfuns if it's fed objects it doesn't understand. E.g. m_delete and random already have such things.
As for set operations, the existing `|, `&, `- etc are already used for that. Aren't those enough?
/ Martin Stjernholm, Roxen IS
How macroish would that be? It'd be fairly simple if all the operator declarations are strictly lexical, just like cpp macros so that they would have to reside in some header file. Otherwise you'd have to figure out all sorts of rules regarding how the operators are looked up and what should happen if they conflict between different classes and/or modules.
/ Martin Stjernholm, Roxen IS
Previous text:
2003-05-15 20:48: Subject: top level infix operators
Hmm... how about having some sort of macro-ish construct for this?
SML has something similar (although I don't know the itty-bitty details). The idea is that you declare a token as an infix operator and assign it a function.
An example with a minimal pow operator:
int my_pow(int base, int power) { return pow(base,power); } infix "**" * my_pow; // or infix("**", 4 , my_pow); // 4 is how hard it binds in comparison to other operators
My thought is that this code
int foo = 2**3;
is expanded to
int foo = pow(2,3);
or rather the unoptimized case of
int foo = (pow(2,3));
/ Peter Lundqvist (disjunkt)
That wouldn't be very macroish, no.
/ Peter Lundqvist (disjunkt)
Previous text:
2003-05-15 21:09: Subject: top level infix operators
How macroish would that be? It'd be fairly simple if all the operator declarations are strictly lexical, just like cpp macros so that they would have to reside in some header file. Otherwise you'd have to figure out all sorts of rules regarding how the operators are looked up and what should happen if they conflict between different classes and/or modules.
/ Martin Stjernholm, Roxen IS
Well, I don't have any particular objections against extending the cpp with rewrite stuff. I think it should be a bit more cpp-esque in syntax than the example you gave, though.
/ Martin Stjernholm, Roxen IS
Previous text:
2003-05-15 21:14: Subject: top level infix operators
That wouldn't be very macroish, no.
/ Peter Lundqvist (disjunkt)
pike-devel@lists.lysator.liu.se
-
Henrik Grubbstr�m (Lysator) ＠ Pike (-) developers forum -
Martin Stjernholm, Roxen IS ＠ Pike developers forum
-
Mirar ＠ Pike developers forum
-
Peter Lundqvist (disjunkt) ＠ Pike (-) developers forum