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

Thu Jun 4 20:32:17 CEST 2015

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.

As for language features, I think we should be looking for features to
remove.

On Thu, Jun 4, 2015 at 11:01 AM, Jay K <jay.krell at cornell.edu> wrote:

>   > 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 INTEGER128
> and convert frontend to use it. Hypothetically. Perhaps before that happens
> we'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/b9b84410/attachment-0002.html>