[M3devel] 32bit host 64bit target TextLiteral recurring problem

Thu Jun 4 20:01:05 CEST 2015

  > Operator overloading is anathema to the Modula-3 design principles.  Use C++ if that is what you want. 

The combination of features I want hasn't been materialized.
Something like:
  1) operator overloading -- C++  
  2) templates with type deduction (i.e. C++ function templates, not just class templates or generic modules) -- C++  
  3) a small easy to understand language -- not C++, maybe Modula-3 
  4) a small easy to understand compiler (m3front I don't understand) -- nowhere 
  5) fast compilation -- Modula-3 
  6) optional safey -- Modula-3 
  7) multiple inheritance, at least of "interfaces" -- C++  
  8) optionally stack or inline allocation of "classes"/"objects" -- C++ 
  9) clear choice of build system -- Modula-3 perhaps  
  10) locals with destructors -- C++ 
  11) clear portable choice for remoting/RPC  -- Modula-3 perhaps  
  12) needs backend work -- Modula-3 perhaps
  13) a small easty to understand backend -- Modula-3 perhaps kinda sorta 
  14) ?safety w/o garbage collection? -- rust??
  15) static compilation for type checking -- C++, Modula-3, Java, Go, C#. Not Python/Perl/Ruby/Erlang/sh/Tcl.  
  16) static compilation to native code, maybe -- C++ and Modula-3!  Go? Net.Native? 
  17) non-virtual member functions -- not C or Modula-3 
  18) virtual member functions -- C++, Modula-3 
  19) safe numbers? Scheme?? C++ w/ library? (with operator overloading) 
  20) clear/portable choice for threads -- Modula-3, C++14? Java. Geez C++ was late here. 
  21) clear/portable choice for interlocked -- Win32, msvc gcc; Modula-3 and C are decades late. 
  22) good string library
  23) good regex library 

Basically, for now, I want static compilation to native code, fast compilation, optional safety.
That combination is rare.

Rust is unusual in safety w/o gc. Extended static lifetime analysis/verification...

 - Jay

Subject: Re: [M3devel] 32bit host 64bit target TextLiteral recurring problem
From: hosking at purdue.edu
Date: Thu, 4 Jun 2015 12:50:02 -0400
CC: rodney.m.bates at acm.org; m3devel at elegosoft.com
To: jay.krell at cornell.edu

On Jun 4, 2015, at 11:45 AM, Jay K <jay.krell at cornell.edu> wrote: How strongly preferred and why? 
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.
 good naturedly: 

  1) to cause me pain so that might give up?   2) to take more time so I don't muck with other stuff?    3) for compatibility with older releases?    4) for easier extension in future?    5) to cause me pain so I whine more about wanting operator overloading?  
Perhaps 3 & 4.
 I started this once and it going to be a pain.  LONGINT is probably much easier.  Maybe I have more patience now. 
:-)  Patience accrues with age…
Extension in the future could be addition of INTEGER128 to the language. :)And the 128 bit targets will initially have 64bit LONGINT limits, until we add INTEGER128and convert frontend to use it. Hypothetically. Perhaps before that happenswe'll have operator overloading. :) 
Operator overloading is anathema to the Modula-3 design principles.  Use C++ if that is what you want.

 - Jay

Subject: Re: [M3devel] 32bit host 64bit target TextLiteral recurring problem
From: hosking at purdue.edu
Date: Thu, 4 Jun 2015 11:32:48 -0400
CC: rodney.m.bates at acm.org; m3devel at elegosoft.com
To: jay.krell at cornell.edu

Again, TInt preferred. 

Sent from my iPhone
On Jun 4, 2015, at 11:08 AM, Jay K <jay.krell at cornell.edu> wrote:

When I proposed TInt I had actually forgotten about LONGINT!LONGINT is easier to code to (until/unless we get operator overloading...)
TInt is easier to extend, and is portable to before the current release.I think LONGINT is adequate.I did extent TInt to 72 bits I think.
 - Jay

> Date: Thu, 4 Jun 2015 09:37:06 -0500
> From: rodney_bates at lcwb.coop
> To: jay.krell at cornell.edu; hosking at purdue.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] 32bit host 64bit target TextLiteral recurring problem
> 
> 
> 
> On 06/03/2015 06:14 PM, Jay K wrote:
> > 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.
> > An array of chars? Probably has same problem.
> >
> >
> > Can I/we please LONGINT-ize the compiler now, for all type sizes and field offsets?
> >
> > - Jay
> >
> 
> I'm OK with doing it, but I thought you had been talking about using TInt.
> Would that be better? It would be more general. But LONGINT would be
> faster at compile time, and less work, since the arithmetic operators
> would not need to be changed to TInt function calls. There might
> be quite a lot of those I guess the compiler would be of about equal
> help in finding missed places to be changed, either way.
> 
> I just checked, and LONGINT is in the release compiler, contrary to
> my sense of relative history, so there would be no bootstrap barrier.
> 
> Either would allow a 32-bit hosted compiler (cross- or native-) to handle
> types whose byte-count approached 2^31, instead of just 2^23. With a
> 64-bit hosted compiler, TInt would handle 2^63 byte-sized objects,
> whereas LONGINT would only go to 2^55. Do we really care?
> 
> >
> >
> > ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> --
> > Subject: Re: [M3devel] 32bit host 64bit target TextLiteral recurring problem
> > From: hosking at purdue.edu
> > Date: Wed, 3 Jun 2015 14:07:02 -0400
> > CC: m3devel at elegosoft.com
> > To: jay.krell at cornell.edu
> >
> > It’s only TEXT /literals/ that are limited here. As in, what appears in a source program.
> >
> >
> -- 
> Rodney Bates
> rodney.m.bates at acm.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150604/283c28ce/attachment-0002.html>