Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!ucbvax!VTVM1.BITNET!GRANGERG From: GRANGERG@VTVM1.BITNET (Greg Granger) Newsgroups: comp.lang.modula2 Subject: Re: Does Modula-2 have operator overloading? Message-ID: Date: 26 Jul 90 18:23:04 GMT References: Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: Modula2 List Organization: The Internet Lines: 79 On Thu, 26 Jul 90 16:01:58 GMT Preston Briggs said: >In article Modula2 List > 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