[M3devel] INTEGER

[Jay K]

 > Modula-3 already uses floating point for this, which has the advantage
 > you don't need to worry what the base is. 

 

What do you mean not worry about the "base"?

I'm not a fan of floating point.

 

 

> support. The reason I don't like LONGINT as much is that it seems it's
> just a waste if we're all going to be using 64-bit machines anyhow.


 

Again, you might be right. C got 64bit integers ~18 years ago. We are late.

Do you think phones and embedded devices will move to 64bits soon too?

Are gaming consoles 64bits?

 

> I use the rdwrreset package under PM3

 

 

Probably we should plunder PM3 for anything we are missing.

 

 

> different from 32-bit INTEGER. ARRAY [0..1] OF INTEGER seems to be a
> candidate...


 

Again, aside, can such an array be made truly abstract?

   I'd like opaque data structures without forcing heap allocation.

Because, you know, it is somewhat tricky how to deal with, and people

will differ as to their assumptions of the order of the integers.

 

 

There is a bignum package, I haven't looked into it.

I find code quality tends to go down the higher level you look.

 e.g. libm3's socket stuff..

so I haven't looked at a lot, but I should.

 

 

 - Jay

 
> To: jay.krell at cornell.edu
> Date: Mon, 19 Apr 2010 15:31:52 -0700
> From: mika at async.async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] INTEGER
> 
> Jay K writes:
> ...
> >Let me suggest a small exercise though:
> >
> > I'm not going to do it.
> >
> > Write a program that copies files. Or just one file. "cp.exe".
> >
> > Have it print "progress feedback" to the user -- how many bytes and percen=
> >tage copied. Leave out "time estimation".
> >
> > And also write "ls.exe".
> >
> > And maybe one last program=2C like "dos2unix.exe" or "fix_nl.exe" that alt=
> >ers newlines. This program should work on files that don't fit in memory.
> >
> 
> I use the rdwrreset package under PM3. It solves the most glaring problems.
> But clearly the file sizes should be done with some sort of data structure
> different from 32-bit INTEGER. ARRAY [0..1] OF INTEGER seems to be a
> candidate...
> 
> ...
> >Also think about what an idea representation of time is.
> >
> >Isn't a 64bit integer number of units smaller than a second a very good one=
> >?
> 
> Modula-3 already uses floating point for this, which has the advantage
> you don't need to worry what the base is. 
> 
> >
> >And aren't infix operators darned nice?
> 
> I have mixed feelings about this. Yes, but... every infix operator takes
> several lines of language definition. Those lines can turn into ungodly
> amounts of code somewhere.
> 
> I actually do like Hendrik's idea of providing some sort of bignum
> support. The reason I don't like LONGINT as much is that it seems it's
> just a waste if we're all going to be using 64-bit machines anyhow.
> It's arbitrary to have two fixed-width types. Why not three or four?
> And why not 128 bits or 16 bits or 36 bits? If on the other hand
> you got something substantial out of it that might be another story.
> In that case, I would say LONGINT would be a reference type (much like
> TEXT) with its associated Longint interface, and infix operators (the
> way TEXT has &) per Jay's fondest dreams. Come to think of it, 
> TEXT and such a LONGINT would have a lot in common. 
> 
> Mika
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100419/096fa9e9/attachment-0002.html>