[M3devel] operator overloading?

[Tony Hosking]

On Nov 21, 2010, at 3:11 PM, Jay K wrote:

> > I'm now starting to wish that we had left LONGINT out,
> 
> 
> Just now? :)
> (This is another reason I'm somewhat open to tediously using Target.Int in frontend,
> in case we do lose LONGINT.)

What it really suggests is that we need a proper infinite precision integer library.  Do we have one somewhere already?

>  > ARRAY [1..2] OF INTEGER .. same representation as C "long long"
> 
> 
> These are potentially much different, e.g. when being returned from a function by value.
> NT/x86 returns them in the register pair edx:eax.
> Granted, it *might* also store small structs that way, but I'm not sure.
>    (you could bury the array in a struct then as well)
> But I guess a small special case would do.
> 
> 
> Why are sets in the language, with infix operators?
> Why floats? You know, historically, and still sometimes ("soft float"), floating point operations are function calls.
> 
> 
> If we had operator overloading then I'd be much closer to agreeing, aside from the representation issue.
> Since that is a generalization that supports LONGINT as it is today, and Target.Int, strings, matrices, vectors, etc.
> 
> 
> I have done a *little* bit of Scheme programming, so I at least was at some point
> sympathetic to the view of having no infix operators whatsoever.
> 
> 
> The story of the Dylan programming language is also interesting.
> It was originally prefix only but caved and went infix for the sake of
> programmer convenience.
> 
> 
>   - Jay
> 
> 
> > From: hosking at cs.purdue.edu
> > Date: Sun, 21 Nov 2010 15:04:09 -0500
> > To: mika at async.async.caltech.edu
> > CC: m3devel at elegosoft.com; jay.krell at cornell.edu
> > Subject: Re: [M3devel] operator overloading?
> > 
> > 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_--
> > 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20101121/4adef7e9/attachment-0002.html>