mdlcpgs@lhn.dsir.govt.nz (04/23/91)
>> Then of course printf isnt lovely but then neither is M2's individual calls >> for each IO item... :-) Personally, I support the idea of operator >> overloading and variable no. of parameters in procedure calls. It seems to >> me to be lack of imagination to suggest that compilers cant do this safely. >> ^^^^^^^^^^^^^^^^^^^ > > If you read my discussion, there is no insinuation on my part that compilers > cannot do overator overloading, variable parameters, or any C-like syntactic > extension correctly. Such an insinuation would be completely absurd, because > we (compiler writers) already know how to implement such features. Further, it > is the case that compiler writers are implementing such features (as is the > case in JPI Modula-2). > > I will suggest, however, that language extensions probably ought to be done in > a fashion consistent with the original philosophy of the language. Modula-2 > was designed to support the notion of very strong typing. An extension to the > language which allows variable argument lists effectively relaxes the type > checking system. This is what I meant about lack of imagination. I dont see why you cant have strong typing AND variable paramter nos. The procedure definition must state the varaible parameter no.s are expected (intrinic type ParameterList?) and what types they are allowed to be so calling expressions can be checked at run time. The procedure passing will incur an overhead of passing a type identifier ONLY for variable lists, and there will also need to be an element for determining type. > Here is a nifty idea. Extend every language to have all of the features of C. > Add a type cast operator. Allow any operator to be overloaded, including the > dot and comma. Why not throw in those variable arguments. Maybe even change > the type system so it is unreadable by humans (like it is in C). Well, if you > add all of those features, you will be able to exploit the "real power" of > practically any C library. After all, the semantics of the languages will > practically be the same! While I appreciate the above isnt serious, I seriously do want much of the power of C in a readable expressive form, with strong typing. I dont appreciate being told you can either have the readability of Wirth's symbolics but with minimalism OR ghastly C with its attendent hassles. The search is for an enhanced expressive power in the M2/Pascal/oberon syntax. Consider complex no.s (I know they are proposed for the M2 standard bu that aside) I find a := b + c; much more reabable than AddComplex(a,b,c); { so whats being added to what? } If the loaded operator is imported from Module Complex and operator precedence maintained, then I dont see why it violates M2 concepts or couldnt be readily implemented. Phil
seurer+@rchland.ibm.com (Bill Seurer) (04/29/91)
Excerpts from netnews.comp.lang.modula2: 23-Apr-91 Op overloading/var. parms, .. mdlcpgs@lhn.dsir.govt.nz (2819) > I find > a := b + c; > much more reabable than > AddComplex(a,b,c); { so whats being added to what? } I agree that overloaded operators can be nice. However, they also can be easily abused. A popular one is to use + for string concatenation "'cause it's just like you're adding the two strings together." Well, you aren't adding them you are concatenating them. If "ab" + "cd" is "abcd" then 123 + 456 must =be123456, right? :-) And as for complex numbers, if you have a good compiler that allows any type to be returned as a function result then: a := Complex.Add(b,c); is much clearer than your example (though in this case still not as nice as a:=b+c). - Bill Seurer IBM: seurer+@rchland Prodigy: CNSX71A Rochester, MN Internet: seurer+@rchland.vnet.ibm.com