[M3devel] operator overloading?

[Tony Hosking]

I'm now starting to wish that we had left LONGINT out, and simply come up with some new (builtin) long integer interface that treated integer arithmetic over a representation based on ARRAY OF INTEGER.  It would have been trivial enough to make ARRAY [1..2] OF INTEGER be the same representation as C "long long", and would generalize much better in future.  It would have had the advantage of leaving the core language untouched.

On Nov 21, 2010, at 2:27 PM, Mika Nystrom wrote:

> 
> I don't like changes in Modula-3, on principle.  I have a lot of code
> that is over ten years old and that I never look at, and I never want
> to look at, despite the fact that things that I do depend on computers
> that execute probably billions of instructions in this code every day.
> 
> Now I depend on such code that depends on being able to parse
> Modula-3 itself, so the language, I feel should stay both forward-
> and backward-compatible.  (I really don't like LONGINT for that
> reason.)
> 
> But that being said, operator overloading seems relatively harmless.
> It changes the meaning only of executable code, not interfaces, and unless
> you are writing a compiler, there isn't much reason to be processing
> the executable code.  This is all assuming you do it right.  And there
> must be some way of calling the overloaded operators using functional
> notation so that generated code can get at them.
> 
> What has always bugged me about operator overloading in C++ is just
> what an unabashed hack it is.  You can use the operators from C,
> but no others?  And they have to have the same associativity and
> commutativity rules as in C?  And they can be only unary or binary?
> Does anyone do this better?  Is it even possible?  I suppose the main
> thing is to specify a rule for converting 
> 
> a OP b
> 
> to 
> 
> OP(a,b)...
> 
> What does C++ do?  Make it a.OP(b)?  The asymmetry is really ugly.  And
> then the associativity rules... is addition left- or right-associative?
> Who remembers that..? now *that* is obscure.  And it won't work on RECORDs
> or ARRAYs or SETs, which don't have methods...
> 
> Would it be possible to write a pre-processor using m3tk that would
> implement the entirety of operator overloading?  I think that would
> be an elegant solution, but I've never used m3tk on implementations...
> The reason I am saying this is that judging from the syntax equations
> in the Green Book, it is possible that m3tk might accept a program using
> overloaded operators, and only semantic analysis on the parsed structure
> would uncover the overloaded operators and flag them as semantic errors
> (in standard Modula-3).  But I might be wrong.  And m3tk might have
> broken code in it.  
> 
> When we were designing async. hardware with Modula-3 we had a thing
> called "m3texthack" that would let you do special kinds of macros in
> Modula-3 code.  Your source file would be Module.c3, which would
> be pre-processed into Module.m3 by m3texthack (all handled by m3build/cm3
> of course).
> 
> In any case, an m3tk solution rather than a Modula-3 solution would easily
> allow you to specify different rules for different types, or even for
> different source files, rather than being tied to something nailed down
> in the language spec.
> 
>     Mika
> 
> 
> 
> Jay K writes:
>> --_e51b3849-e219-4308-9fbb-dcefa7ee3f15_
>> Content-Type: text/plain; charset="iso-8859-1"
>> Content-Transfer-Encoding: quoted-printable
>> 
>> 
>> "Obscures the underlying code" is true of so many things.
>> Exceptions. Garbage collection. Objects. Nested functions. Function calls! =
>> Default parameters. Generics. Pickles. RPC.
>> It is a matter of degree=2C cost=2C value though=2C granted.
>> The runtime cost of operating overloading is zero=2C at least.
>> And the unobscured code is horrible to read and write actually (which is =
>> the reason for many features).
>> This is case where "obscure" is clearly good=2C and not obscure.
>> But it is a matter of degree. I should probably try implementing it befor=
>> e I ask for it too strongly.
>> 
>> 
>> - Jay
>> 
>> From: hosking at cs.purdue.edu
>> Date: Sun=2C 21 Nov 2010 13:33:31 -0500
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] operator overloading?
>> 
>> 
>> 
>> Some of us find operator overloading anathema because it obscures the actua=
>> l underlying code.It certainly does not fit well with the design philosophy=
>> of Modula-3.
>> 
>> On Nov 21=2C 2010=2C at 1:10 PM=2C Jay K wrote:Is it really so difficult to=
>> add operator overloading to the language?
>> 
>>> From a user's point of view=2C I know it is very useful in certain situatio=
>> ns.
>> 
>> 
>> - Jay
>> 
>> 
>> 
>> 
>> 
>> 		 	   		  =
>> 
>> --_e51b3849-e219-4308-9fbb-dcefa7ee3f15_
>> Content-Type: text/html; charset="iso-8859-1"
>> Content-Transfer-Encoding: quoted-printable
>> 
>> <html>
>> <head>
>> <style><!--
>> .hmmessage P
>> {
>> margin:0px=3B
>> padding:0px
>> }
>> body.hmmessage
>> {
>> font-size: 10pt=3B
>> font-family:Tahoma
>> }
>> --></style>
>> </head>
>> <body class=3D'hmmessage'>
>> "Obscures the underlying code" is true of so many things.<br>Exceptions. Ga=
>> rbage collection. Objects. Nested functions. Function calls! Default parame=
>> ters. Generics. Pickles. RPC.<br>It is a matter of degree=2C cost=2C value =
>> though=2C granted.<br>&nbsp=3B The runtime cost of operating overloading is=
>> zero=2C at least.<br>&nbsp=3B And the unobscured code is horrible to read =
>> and write actually (which is the reason for many features).<br>&nbsp=3B Thi=
>> s is case where "obscure" is clearly good=2C and not obscure.<br>&nbsp=3B B=
>> ut it is a matter of degree. I should probably try implementing it before I=
>> ask for it too strongly.<br><br><br>&nbsp=3B - Jay<br><br><hr id=3D"stopSp=
>> elling">From: hosking at cs.purdue.edu<br>Date: Sun=2C 21 Nov 2010 13:33:31 -0=
>> 500<br>To: jay.krell at cornell.edu<br>CC: m3devel at elegosoft.com<br>Subject: R=
>> e: [M3devel] operator overloading?<br><br>
>> <meta http-equiv=3D"Content-Type" content=3D"text/html=3B charset=3Dunicode=
>> ">
>> <meta name=3D"Generator" content=3D"Microsoft SafeHTML">Some of us find ope=
>> rator overloading anathema because it obscures the actual underlying code.<=
>> div>It certainly does not fit well with the design philosophy of Modula-3.<=
>> br><div><br><div><div>On Nov 21=2C 2010=2C at 1:10 PM=2C Jay K wrote:</div>=
>> <br class=3D"ecxApple-interchange-newline"><blockquote><span class=3D"ecxAp=
>> ple-style-span" style=3D"border-collapse: separate=3B font-family: Helvetic=
>> a=3B font-style: normal=3B font-variant: normal=3B font-weight: normal=3B l=
>> etter-spacing: normal=3B line-height: normal=3B text-indent: 0px=3B text-tr=
>> ansform: none=3B white-space: normal=3B word-spacing: 0px=3B font-size: med=
>> ium=3B"><div class=3D"ecxhmmessage" style=3D"font-size: 10pt=3B font-family=
>> : Tahoma=3B">Is it really so difficult to add operator overloading to the l=
>> anguage?<br><br>From a user's point of view=2C I know it is very useful in =
>> certain situations.<br><br><br>&nbsp=3B- Jay<br><br><br><br><br></div></spa=
>> n></blockquote></div><br></div></div> 		 	   		  </body>
>> </html>=
>> 
>> --_e51b3849-e219-4308-9fbb-dcefa7ee3f15_--