[M3devel] INTEGER
Mika Nystrom
mika at async.async.caltech.edu
Tue Apr 20 00:31:52 CEST 2010
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
More information about the M3devel
mailing list