[M3devel] operator overloading?

[Jay K]

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


I believe m3-libs/arithmetic/src/basictypes/biginteger.
Though this arithmetic library is very large and I understand little of it.


 - Jay

From: hosking at cs.purdue.edu
Date: Sun, 21 Nov 2010 15:14:08 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] operator overloading?






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/84948556/attachment-0002.html>