cfoughty@digi.lonestar.org (Cy Foughty) (07/26/90)
The subject says it all. The operator overloading I would like to see is like that of (Gasp) C++. In that NEWLY created data types can have the operations for "+", "-", etc. defined in the implementation module. Example: TYPE String = ARRAY[1..1000] OF CHAR ; (* Implementation code here*) Then in application code: VAR str1 : String ; str2 : String ; str3 : String ; str1 := "This is" ; str2 := " a test" ; str3 := str1 + str2 ; "str3" would then contain "This is a test". -- Cy Foughty DSC Communications, Inc. 1000 Coit Rd., Plano,TX 75075 Work:214.519.4237 La Casa:214.578.8837 Don't compromise your compromises.
pattis@cs.washington.edu (Richard Pattis) (07/26/90)
Just look at the arithmetic operators: they have various type profiles (for integers, reals, sets). But a programmer has no ability to extend operator overloadings. Rich Pattis
GRANGERG@VTVM1.BITNET (Greg Granger) (07/26/90)
On Wed, 25 Jul 90 18:31:35 GMT Cy Foughty said: >The subject says it all. The operator overloading I would like to >see is like that of (Gasp) C++. In that NEWLY created data types can have >... >-- >Cy Foughty >DSC Communications, Inc. 1000 Coit Rd., Plano,TX 75075 >Work:214.519.4237 La Casa:214.578.8837 >Don't compromise your compromises. Nope, but I like to see that too (with uniary/binary operations, commutative and precedence control on both new and existing types, and generic type determinable parameters to procedures and static vars, and variable width bit fields and *optional* garbage collection and stardard bit ordering access and exception handling and ....) But it just ain't there and isn't likely to be added anytime soon (as there is not yet a 'true standard' published/accepted). Till then we'll just have to repair our tricorders with stone knives and bearskins. Greg
preston@titan.rice.edu (Preston Briggs) (07/26/90)
In article <INFO-M2%90072611375987@UCF1VM.BITNET> Modula2 List <INFO-M2%UCF1VM.BITNET@jade.berkeley.edu> writes: >Nope, but I like to see that too (with uniary/binary operations, >commutative and precedence control on both new and existing types, >and generic type determinable parameters to procedures and static vars, >and variable width bit fields and *optional* garbage collection and >stardard bit ordering access and exception handling and ....) You don't want much I guess. Try Ada maybe, or Clu, Russell, ML, ... More to the point, try to define a language with all that stuff. Then try to implement it. Then try to use it. *I* certainly don't want to maintain programs that redefine precedence of existing operators. The other features sound (more or less) ok when considered alone; building a complete language that has all the neat features you like is hard work. Of course, people DO work on these things all the time. The results are often interesting and exciting. On the other hand, one of the attractions of Modula-2 (and Oberon) is the minimalism. These are languages I can hope to understand, in toto. Regarding all the bit field stuff, I often use bitsets for such things. -- Preston Briggs looking for the great leap forward preston@titan.rice.edu
GRANGERG@VTVM1.BITNET (Greg Granger) (07/27/90)
On Thu, 26 Jul 90 16:01:58 GMT Preston Briggs said: >In article <INFO-M2%90072611375987@UCF1VM.BITNET> Modula2 List > <INFO-M2%UCF1VM.BITNET@jade.berkeley.edu> writes: > >>Nope, but I like to see that too (with uniary/binary operations, >>... > >You don't want much I guess. Try Ada maybe, or Clu, Russell, ML, ... Not not much just 7/8th of the cake :-) > >More to the point, try to define a language with all that stuff. >Then try to implement it. Then try to use it. I think it would be easier to define than to implement. Some things could be implemented now via a preprocessor approach, similar to early C++ implementations. Using it would certainly be the easiest part :-) Yes, you are right it's not a overnight/week/month project, but if I didn't sit around thinking about things like this I'd probably be out on the street getting in trouble facing a long spiral decent into a evil life that would eventually 'lead to no good'. >Then try to implement it. Then try to use it. >*I* certainly don't want to maintain programs that redefine >precedence of existing operators. The other features sound You have a good point there. The reason I included existing operators was to prevent 'wrapping' and allow such things as the definition of a CARDINAL (operator) INTEGER operation (for convenience). I think that defining the precedence of operators is a good compliment to op overloading. I could live without redefining the existing operators. I agree that such features can open a BIG CAN'O WORMS for programmers responsible for maintaining such code, but so can features like pointers, co-routines and absolute memory addressing. The fact that features/extentions 'can' be abused is not reason to eliminate them. >(more or less) ok when considered alone; building a complete language >that has all the neat features you like is hard work. >Of course, people DO work on these things all the time. >The results are often interesting and exciting. True, but some people have more time than ideas, others more ideas than time (I'm one of the fortunate few who is burdened with either ideas or time ;-) May some bright hard working person will 'get hold' of this and Modula-2++ (with x cheese) will be born. With the right subset of features a compiler could be bootstrapped with out 'much' superhuman effort. BTW, bless the 'peoples' that work on these things, they really do make a better world (or at least a better virtual world). > >On the other hand, one of the attractions of Modula-2 (and Oberon) is the >minimalism. These are languages I can hope to understand, in toto. > >Regarding all the bit field stuff, I often use bitsets for >such things. I was thinking more in terms of PACKed arrays, more for saving core or addressing devices. BITSETs seem to me to be a afterthought. I'd like to be able to have a multi-dimensional array of 4 bit units (actually I like to be able to handle dynamic bit field widths as in LZW encoding, but I can't think of a 'good' way to implement it). Course I'd like to be able to treat these nybbles as a new data type and apply op overloading to them. > >-- >Preston Briggs looking for the great leap forward >preston@titan.rice.edu Greg
preston@titan.rice.edu (Preston Briggs) (07/27/90)
In article <INFO-M2%90072615091342@UCF1VM.BITNET> Modula2 List <INFO-M2%UCF1VM.BITNET@jade.berkeley.edu> writes: >On Thu, 26 Jul 90 16:01:58 GMT Preston Briggs said: >>*I* certainly don't want to maintain programs that redefine >>precedence of existing operators. The other features sound > >You have a good point there. The reason I included existing >operators was to prevent 'wrapping' and allow such things as the >definition of a CARDINAL (operator) INTEGER operation >(for convenience). I think that defining the precedence of operators >is a good compliment to op overloading. I could live without >redefining the existing operators. The approach used by Clu (or at least explain in the reference manual) is pretty cool. They define many operators and their precedence and associativity (I don't know about commutivity). I believe these properties are fixed, as is the set of operators. Therefore, you and I and the parser can look at the program and all parse it identically. However, things get more interesting. "x + y" is transformed into the function invocation "sometype$plus(x, y)" where sometype is the type of x and $ is the selection symbol. This happens with all the operators, including "." and "[ ... ]". So it's fairly easy to define something like "+" as string concatenation. You add a function "plus" to the cluster defining strings and the parser will fix you up. I should apologize to Clu hackers for mangling the explanation of their language! My other arguments related to difficulties in defining the language. I still hold that it's a tough job. It's quite difficult to get a set of features to work together well. I can pick nits over lots of unimportant things, but getting the big picture right is probably harder than implementation. -- Preston Briggs looking for the great leap forward preston@titan.rice.edu