<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style>
</head>
<body class='hmmessage'>
<div> > What it really suggests is that we need a proper infinite precision integer library. Do we have one somewhere already?<br><br></div><br>I believe m3-libs/arithmetic/src/basictypes/biginteger.<br>Though this arithmetic library is very large and I understand little of it.<br><br><br> - Jay<br><br><hr id="stopSpelling">From: hosking@cs.purdue.edu<br>Date: Sun, 21 Nov 2010 15:14:08 -0500<br>To: jay.krell@cornell.edu<br>CC: m3devel@elegosoft.com<br>Subject: Re: [M3devel] operator overloading?<br><br>
<meta http-equiv="Content-Type" content="text/html; charset=unicode">
<meta name="Generator" content="Microsoft SafeHTML"><br>
<br><div><div>On Nov 21, 2010, at 3:11 PM, Jay K wrote:</div><br class="ecxApple-interchange-newline"><blockquote><span class="ecxApple-style-span" style="border-collapse: separate; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; font-size: medium;"><div class="ecxhmmessage" style="font-size: 10pt; font-family: Tahoma;">> 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></div></span></blockquote><div><br></div><div>What it really suggests is that we need a proper infinite precision integer library. Do we have one somewhere already?</div><br><blockquote><span class="ecxApple-style-span" style="border-collapse: separate; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; font-size: medium;"><div class="ecxhmmessage" style="font-size: 10pt; font-family: Tahoma;"> > 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:<span class="ecxApple-converted-space"> </span><a href="mailto:hosking@cs.purdue.edu">hosking@cs.purdue.edu</a><br>> Date: Sun, 21 Nov 2010 15:04:09 -0500<br>> To:<span class="ecxApple-converted-space"> </span><a href="mailto:mika@async.async.caltech.edu">mika@async.async.caltech.edu</a><br>> CC:<span class="ecxApple-converted-space"> </span><a href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</a>;<span class="ecxApple-converted-space"> </span><a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a><br>> Subject: Re: [M3devel] operator overloading?<br>><span class="ecxApple-converted-space"> </span><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>><span class="ecxApple-converted-space"> </span><br>> On Nov 21, 2010, at 2:27 PM, Mika Nystrom wrote:<br>><span class="ecxApple-converted-space"> </span><br>> ><span class="ecxApple-converted-space"> </span><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>> ><span class="ecxApple-converted-space"> </span><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>> ><span class="ecxApple-converted-space"> </span><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>> ><span class="ecxApple-converted-space"> </span><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<span class="ecxApple-converted-space"> </span><br>> ><span class="ecxApple-converted-space"> </span><br>> > a OP b<br>> ><span class="ecxApple-converted-space"> </span><br>> > to<span class="ecxApple-converted-space"> </span><br>> ><span class="ecxApple-converted-space"> </span><br>> > OP(a,b)...<br>> ><span class="ecxApple-converted-space"> </span><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>> ><span class="ecxApple-converted-space"> </span><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.<span class="ecxApple-converted-space"> </span><br>> ><span class="ecxApple-converted-space"> </span><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>> ><span class="ecxApple-converted-space"> </span><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>> ><span class="ecxApple-converted-space"> </span><br>> > Mika<br>> ><span class="ecxApple-converted-space"> </span><br>> ><span class="ecxApple-converted-space"> </span><br>> ><span class="ecxApple-converted-space"> </span><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>> >><span class="ecxApple-converted-space"> </span><br>> >><span class="ecxApple-converted-space"> </span><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>> >><span class="ecxApple-converted-space"> </span><br>> >><span class="ecxApple-converted-space"> </span><br>> >> - Jay<br>> >><span class="ecxApple-converted-space"> </span><br>> >> From:<span class="ecxApple-converted-space"> </span><a href="mailto:hosking@cs.purdue.edu">hosking@cs.purdue.edu</a><br>> >> Date: Sun=2C 21 Nov 2010 13:33:31 -0500<br>> >> To:<span class="ecxApple-converted-space"> </span><a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a><br>> >> CC:<span class="ecxApple-converted-space"> </span><a href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</a><br>> >> Subject: Re: [M3devel] operator overloading?<br>> >><span class="ecxApple-converted-space"> </span><br>> >><span class="ecxApple-converted-space"> </span><br>> >><span class="ecxApple-converted-space"> </span><br>> >> Some of us find operator overloading anathema because it obscures the actua=<br>> >> l underlying<span class="ecxApple-converted-space"> </span><a href="http://code.It" target="_blank">code.It</a><span class="ecxApple-converted-space"> </span>certainly does not fit well with the design philosophy=<br>> >> of Modula-3.<br>> >><span class="ecxApple-converted-space"> </span><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>> >><span class="ecxApple-converted-space"> </span><br>> >>> From a user's point of view=2C I know it is very useful in certain situatio=<br>> >> ns.<br>> >><span class="ecxApple-converted-space"> </span><br>> >><span class="ecxApple-converted-space"> </span><br>> >> - Jay<br>> >><span class="ecxApple-converted-space"> </span><br>> >><span class="ecxApple-converted-space"> </span><br>> >><span class="ecxApple-converted-space"> </span><br>> >><span class="ecxApple-converted-space"> </span><br>> >><span class="ecxApple-converted-space"> </span><br>> >> =<br>> >><span class="ecxApple-converted-space"> </span><br>> >> --_e51b3849-e219-4308-9fbb-dcefa7ee3f15_<br>> >> Content-Type: text/html; charset="iso-8859-1"<br>> >> Content-Transfer-Encoding: quoted-printable<br>> >><span class="ecxApple-converted-space"> </span><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>> >><span class="ecxApple-converted-space"> </span><br>> >> --_e51b3849-e219-4308-9fbb-dcefa7ee3f15_--<br>><span class="ecxApple-converted-space"> </span><br></div></span></blockquote></div><br> </body>
</html>