<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
Yes we have some such libraries;<BR>
The "problem" is that libraries are inconvenient and in-fix operatores are convenient;<BR>
You either need to:<BR>
accept that and use what works<BR>
or make the language amenable to more convenient libraries<BR>
(i.e. provide for operator overloading in the language)<BR>
or make more stuff "built in" / "special"<BR>
<BR>
<BR>
We will probably just do the first.<BR>
LONGINT will probably just always be exactly 64bits, no more, no less,<BR>
and have the same overflow features as INTEGER;<BR>
<BR>
It'd be nifty for me if the frontend learned to do arbitrary precision<BR>
integer arithmetic, because then NT386 would get a working LONGINT that way;<BR>
But that's not a valid reason. :)<BR>
<BR>
- Jay<BR><BR><BR> <BR>> Date: Sat, 9 Jan 2010 13:50:25 -0600<BR>> From: rodney_bates@lcwb.coop<BR>> CC: m3devel@elegosoft.com<BR>> Subject: Re: [M3devel] Unbounded but finite LONGINT<BR>> <BR>> <BR>> <BR>> Tony Hosking wrote:<BR>> > On 8 Jan 2010, at 20:33, hendrik@topoi.pooq.com <BR>> > <mailto:hendrik@topoi.pooq.com> wrote:<BR>> > <BR>> >> On Fri, Jan 08, 2010 at 07:53:07PM -0500, Tony Hosking wrote:<BR>> >>> I think what you are advocating is Rodney's proposal + assignability<BR>> >>> of INTEGER and LONGINT + mixed arithmetic.<BR>> >><BR>> >> I thought Rodney's propsal still had the compiler impose a bound on the<BR>> >> size of LONGINT. Or did I miss something?<BR>> > <BR>> > Yes, it would.<BR>> > <BR>> >> I'm proposing to let the programmer use subranges of LONGINT that are as<BR>> >> long as he wishes. And if the computer runs out of virtual memory to<BR>> >> store one of the programmer's long integers, well, that's the computer<BR>> >> imposing the limit, not the language.<BR>> > <BR>> > But there is still the question as to what *representation* is used to <BR>> > decide the particular operation to apply.<BR>> > <BR>> > I suppose the compiler could choose a particular machine representation <BR>> > based on the range of values in the subrange (much as it does currently).<BR>> > But if you really want to have an arbitrary range type I would argue it <BR>> > is much better to implement it as a library than as a primitive type.<BR>> <BR>> This I agree with wholeheartedly. Don't we already have some math libraries<BR>> for things like this, or maybe rational arithmetic, etc?<BR>> <BR>> <BR>> > <BR>> > Just for fun, I suggest you take some time to watch the talk Growing a <BR>> > Language, by Guy Steele <BR>> > <http://video.google.com/videoplay?docid=-8860158196198824415><BR> </body>
</html>