chris@mimsy.UUCP (Chris Torek) (01/29/88)
In article <744@PT.CS.CMU.EDU> edw@IUS1.CS.CMU.EDU (Eddie Wyatt) writes: >Why not? why not have an extendable language, where the user is free to >define his own infix operators? Is it that outragous? Not at all. Various people have done it, although it requires a weird parser. Personally, I like the idea of having *no* operators (a la Lisp, e.g.), perhaps with a `tricksy preprocessor' that can turn `operators' into functional notation. The latter might be done with augmented regular expressions (you need something powerful enough to handle nested parentheses, for instance). >THIS IS JUST HYPOTHETICAL - I"M NOT SERIOUSLY APPROSING THIS! Good. Neither am I ... at least for C. >I know that the [#define sqr(x) ((x)*(x))] macro won't work in all >situations, I don't think you can write one that will work in all >situations. So o.k. I'm game, what's "the right" way to write the >macro. :-/ How about something like this? overload sqr; inline int sqr(int x) { return (x * x); } inline float sqr(float x) { return (x * x); } inline double sqr(double x) { return (x * x); } inline complex sqr(complex x) { return (x * x); } inline dcomplex sqr(dcomplex x) { return (x * x); } inline quaternion sqr(quaternion x) { return (x * x); } /* etc */ But please, not in a standard that ought to be making C-as-it-was a standard, not C-as-we-think-it-should-be a standard. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris