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