[M3devel] Unbounded but finite LONGINT

[Jay K]

Yes we have some such libraries;

The "problem" is that libraries are inconvenient and in-fix operatores are convenient;

You either need to:

   accept that and use what works

   or make the language amenable to more convenient libraries

    (i.e. provide for operator overloading in the language)

   or make more stuff "built in" / "special"

 

 

We will probably just do the first.

LONGINT will probably just always be exactly 64bits, no more, no less,

and have the same overflow features as INTEGER;

 

It'd be nifty for me if the frontend learned to do arbitrary precision

integer arithmetic, because then NT386 would get a working LONGINT that way;

But that's not a valid reason. :)

 

 - Jay


 
> Date: Sat, 9 Jan 2010 13:50:25 -0600
> From: rodney_bates at lcwb.coop
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Unbounded but finite LONGINT
> 
> 
> 
> Tony Hosking wrote:
> > On 8 Jan 2010, at 20:33, hendrik at topoi.pooq.com 
> > <mailto:hendrik at topoi.pooq.com> wrote:
> > 
> >> On Fri, Jan 08, 2010 at 07:53:07PM -0500, Tony Hosking wrote:
> >>> I think what you are advocating is Rodney's proposal + assignability
> >>> of INTEGER and LONGINT + mixed arithmetic.
> >>
> >> I thought Rodney's propsal still had the compiler impose a bound on the
> >> size of LONGINT. Or did I miss something?
> > 
> > Yes, it would.
> > 
> >> I'm proposing to let the programmer use subranges of LONGINT that are as
> >> long as he wishes. And if the computer runs out of virtual memory to
> >> store one of the programmer's long integers, well, that's the computer
> >> imposing the limit, not the language.
> > 
> > But there is still the question as to what *representation* is used to 
> > decide the particular operation to apply.
> > 
> > I suppose the compiler could choose a particular machine representation 
> > based on the range of values in the subrange (much as it does currently).
> > But if you really want to have an arbitrary range type I would argue it 
> > is much better to implement it as a library than as a primitive type.
> 
> This I agree with wholeheartedly. Don't we already have some math libraries
> for things like this, or maybe rational arithmetic, etc?
> 
> 
> > 
> > Just for fun, I suggest you take some time to watch the talk Growing a 
> > Language, by Guy Steele 
> > <http://video.google.com/videoplay?docid=-8860158196198824415>
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100109/3432e1d0/attachment-0002.html>