<div dir="ltr">You really should try writing your own language, it's really not that hard. M3 will never give you satisfaction. You've already implemented a C back end and no doubt have an idea of how a compiler works.<div><br></div><div>As for language features, I think we should be looking for features to remove.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 4, 2015 at 11:01 AM, Jay K <span dir="ltr"><<a href="mailto:jay.krell@cornell.edu" target="_blank">jay.krell@cornell.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div dir="ltr"><span class=""><div> > Operator overloading is anathema to the Modula-3 design principles. Use C++ if that is what you want. </div><div><br></div></span><div><br>The combination of features I want hasn't been materialized.<br>Something like:</div><div><br></div><div> 1) operator overloading -- C++ <br> 2) templates with type deduction (i.e. C++ function templates, not just class templates or generic modules) -- C++ <br> 3) a small easy to understand language -- not C++, maybe Modula-3 <br> 4) a small easy to understand compiler (m3front I don't understand) -- nowhere <br> 5) fast compilation -- Modula-3 <br> 6) optional safey -- Modula-3 <br> 7) multiple inheritance, at least of "interfaces" -- C++ <br> 8) optionally stack or inline allocation of "classes"/"objects" -- C++ <br> 9) clear choice of build system -- Modula-3 perhaps <br> 10) locals with destructors -- C++ <br> 11) clear portable choice for remoting/RPC -- Modula-3 perhaps <br> 12) needs backend work -- Modula-3 perhaps<br> 13) a small easty to understand backend -- Modula-3 perhaps kinda sorta <br> 14) ?safety w/o garbage collection? -- rust??<br> 15) static compilation for type checking -- C++, Modula-3, Java, Go, C#. Not Python/Perl/Ruby/Erlang/sh/Tcl. <br> 16) static compilation to native code, maybe -- C++ and Modula-3! Go? Net.Native? <br> 17) non-virtual member functions -- not C or Modula-3 <br> 18) virtual member functions -- C++, Modula-3 <br> 19) safe numbers? Scheme?? C++ w/ library? (with operator overloading) <br> 20) clear/portable choice for threads -- Modula-3, C++14? Java. Geez C++ was late here. <br> 21) clear/portable choice for interlocked -- Win32, msvc gcc; Modula-3 and C are decades late. <br> 22) good string library<br> 23) good regex library </div><div><br></div><div><br>Basically, for now, I want static compilation to native code, fast compilation, optional safety.<br>That combination is rare.</div><div><br></div><div><br></div><div>Rust is unusual in safety w/o gc. Extended static lifetime analysis/verification...</div><div><br></div><div><br> - Jay<br><br><br><br></div><div><span class=""><hr>Subject: Re: [M3devel] 32bit host 64bit target TextLiteral recurring problem<br>From: <a href="mailto:hosking@purdue.edu" target="_blank">hosking@purdue.edu</a><br></span>Date: Thu, 4 Jun 2015 12:50:02 -0400<span class=""><br>CC: <a href="mailto:rodney.m.bates@acm.org" target="_blank">rodney.m.bates@acm.org</a>; <a href="mailto:m3devel@elegosoft.com" target="_blank">m3devel@elegosoft.com</a><br>To: <a href="mailto:jay.krell@cornell.edu" target="_blank">jay.krell@cornell.edu</a><br><br><br></span><div><span class=""><blockquote><div>On Jun 4, 2015, at 11:45 AM, Jay K <<a href="mailto:jay.krell@cornell.edu" target="_blank">jay.krell@cornell.edu</a>> wrote:</div><br><div><div style="font:16px/normal Calibri;text-transform:none;text-indent:0px;letter-spacing:normal;word-spacing:0px;white-space:normal" dir="ltr"> How strongly preferred and why? </div></div></blockquote><div><br></div></span><div>TInt preferred because LONGINT is still a terrible hack, and I hate to see it pollute the system more than it already has. What’s more, the backends break on a number of operations for it. I now regret ever having introduced it, and would like to back it out. We would have been better to specialize 32-bit targets to treat 64-bit offsets as ARRAY [0..1] OF INTEGER, and then hidden manipulation of those offsets behind a clean interface, much as Tint does. I think the one use-case we had for it to allow interfacing directly to C functions that take offset_t arguments could have been finessed differently.</div><span class=""><br><blockquote><div style="font:16px/normal Calibri;text-transform:none;text-indent:0px;letter-spacing:normal;word-spacing:0px;white-space:normal" dir="ltr"><div> good naturedly: </div><div><br></div><div><br></div><div> 1) to cause me pain so that might give up? </div><div> 2) to take more time so I don't muck with other stuff? </div><div> 3) for compatibility with older releases? </div><div> 4) for easier extension in future? </div><div> 5) to cause me pain so I whine more about wanting operator overloading? </div></div></blockquote><div><br></div></span><div>Perhaps 3 & 4.</div><span class=""><br><blockquote><div style="font:16px/normal Calibri;text-transform:none;text-indent:0px;letter-spacing:normal;word-spacing:0px;white-space:normal" dir="ltr"><div> I started this once and it going to be a pain. </div><div> LONGINT is probably much easier. </div><div> Maybe I have more patience now. </div></div></blockquote><div><br></div></span><span class=""><div>:-) Patience accrues with age…</div><div><br></div></span><span class=""><blockquote><div style="font:16px/normal Calibri;text-transform:none;text-indent:0px;letter-spacing:normal;word-spacing:0px;white-space:normal" dir="ltr"><div>Extension in the future could be addition of INTEGER128 to the language. :)</div><div>And the 128 bit targets will initially have 64bit LONGINT limits, until we add INTEGER128</div><div>and convert frontend to use it. Hypothetically. Perhaps before that happens</div><div>we'll have operator overloading. :) </div></div></blockquote><div><br></div></span><span class=""><div>Operator overloading is anathema to the Modula-3 design principles. Use C++ if that is what you want.</div><br></span><blockquote><div style="font:16px/normal Calibri;text-transform:none;text-indent:0px;letter-spacing:normal;word-spacing:0px;white-space:normal" dir="ltr"><div><br><br><div><div class="h5"> - Jay<br><br><br><div><hr>Subject: Re: [M3devel] 32bit host 64bit target TextLiteral recurring problem<br>From: <a href="mailto:hosking@purdue.edu" target="_blank">hosking@purdue.edu</a><br>Date: Thu, 4 Jun 2015 11:32:48 -0400<br>CC: <a href="mailto:rodney.m.bates@acm.org" target="_blank">rodney.m.bates@acm.org</a>; <a href="mailto:m3devel@elegosoft.com" target="_blank">m3devel@elegosoft.com</a><br>To: <a href="mailto:jay.krell@cornell.edu" target="_blank">jay.krell@cornell.edu</a><br><br><div>Again, TInt preferred. <br><br>Sent from my iPhone</div><div><br>On Jun 4, 2015, at 11:08 AM, Jay K <<a href="mailto:jay.krell@cornell.edu" target="_blank">jay.krell@cornell.edu</a>> wrote:<br><br></div><blockquote><div><div dir="ltr">When I proposed TInt I had actually forgotten about LONGINT!<div>LONGINT is easier to code to (until/unless we get operator overloading...)</div><div><br></div><div>TInt is easier to extend, and is portable to before the current release.</div><div>I think LONGINT is adequate.</div><div>I did extent TInt to 72 bits I think.</div><div><br></div><div> - Jay<br><br><br><div>> Date: Thu, 4 Jun 2015 09:37:06 -0500<br>> From:<span> </span><a href="mailto:rodney_bates@lcwb.coop" target="_blank">rodney_bates@lcwb.coop</a><br>> To:<span> </span><a href="mailto:jay.krell@cornell.edu" target="_blank">jay.krell@cornell.edu</a>;<span> </span><a href="mailto:hosking@purdue.edu" target="_blank">hosking@purdue.edu</a><br>> CC:<span> </span><a href="mailto:m3devel@elegosoft.com" target="_blank">m3devel@elegosoft.com</a><br>> Subject: Re: [M3devel] 32bit host 64bit target TextLiteral recurring problem<br>><span> </span><br>><span> </span><br>><span> </span><br>> On 06/03/2015 06:14 PM, Jay K wrote:<br>> > sorry, I missed that it is literals...so I can convert a blueray movie into a source file containing the data all in a text? Far fetched.<br>> > An array of chars? Probably has same problem.<br>> ><br>> ><br>> > Can I/we please LONGINT-ize the compiler now, for all type sizes and field offsets?<br>> ><br>> > - Jay<br>> ><br>><span> </span><br>> I'm OK with doing it, but I thought you had been talking about using TInt.<br>> Would that be better? It would be more general. But LONGINT would be<br>> faster at compile time, and less work, since the arithmetic operators<br>> would not need to be changed to TInt function calls. There might<br>> be quite a lot of those I guess the compiler would be of about equal<br>> help in finding missed places to be changed, either way.<br>><span> </span><br>> I just checked, and LONGINT is in the release compiler, contrary to<br>> my sense of relative history, so there would be no bootstrap barrier.<br>><span> </span><br>> Either would allow a 32-bit hosted compiler (cross- or native-) to handle<br>> types whose byte-count approached 2^31, instead of just 2^23. With a<br>> 64-bit hosted compiler, TInt would handle 2^63 byte-sized objects,<br>> whereas LONGINT would only go to 2^55. Do we really care?<br>><span> </span><br>> ><br>> ><br>> > ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------<br>> --<br>> > Subject: Re: [M3devel] 32bit host 64bit target TextLiteral recurring problem<br>> > From:<span> </span><a href="mailto:hosking@purdue.edu" target="_blank">hosking@purdue.edu</a><br>> > Date: Wed, 3 Jun 2015 14:07:02 -0400<br>> > CC:<span> </span><a href="mailto:m3devel@elegosoft.com" target="_blank">m3devel@elegosoft.com</a><br>> > To:<span> </span><a href="mailto:jay.krell@cornell.edu" target="_blank">jay.krell@cornell.edu</a><br>> ><br>> > It’s only TEXT /literals/ that are limited here. As in, what appears in a source program.<br>> ><br>> ><br>> --<span> </span><br>> Rodney Bates<br>><span> </span><a href="mailto:rodney.m.bates@acm.org" target="_blank">rodney.m.bates@acm.org</a></div></div></div></div></blockquote></div></div></div></div></div></blockquote></div><br></div> </div></div>
</blockquote></div><br></div>