<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
> Modula-3 already uses floating point for this, which has the advantage<BR> > you don't need to worry what the base is. <BR>
<BR>
What do you mean not worry about the "base"?<BR>
I'm not a fan of floating point.<BR>
<BR>
<BR>
> support. The reason I don't like LONGINT as much is that it seems it's<BR>> just a waste if we're all going to be using 64-bit machines anyhow.<BR><BR>
<BR>
Again, you might be right. C got 64bit integers ~18 years ago. We are late.<BR>
Do you think phones and embedded devices will move to 64bits soon too?<BR>
Are gaming consoles 64bits?<BR>
<BR>
> I use the rdwrreset package under PM3<BR>
<BR>
<BR>
Probably we should plunder PM3 for anything we are missing.<BR>
<BR>
<BR>
> different from 32-bit INTEGER. ARRAY [0..1] OF INTEGER seems to be a<BR>> candidate...<BR><BR>
<BR>
Again, aside, can such an array be made truly abstract?<BR>
I'd like opaque data structures without forcing heap allocation.<BR>
Because, you know, it is somewhat tricky how to deal with, and people<BR>
will differ as to their assumptions of the order of the integers.<BR>
<BR>
<BR>
There is a bignum package, I haven't looked into it.<BR>
I find code quality tends to go down the higher level you look.<BR>
e.g. libm3's socket stuff..<BR>
so I haven't looked at a lot, but I should.<BR>
<BR>
<BR>
- Jay<BR><BR> <BR>> To: jay.krell@cornell.edu<BR>> Date: Mon, 19 Apr 2010 15:31:52 -0700<BR>> From: mika@async.async.caltech.edu<BR>> CC: m3devel@elegosoft.com<BR>> Subject: Re: [M3devel] INTEGER<BR>> <BR>> Jay K writes:<BR>> ...<BR>> >Let me suggest a small exercise though:<BR>> ><BR>> > I'm not going to do it.<BR>> ><BR>> > Write a program that copies files. Or just one file. "cp.exe".<BR>> ><BR>> > Have it print "progress feedback" to the user -- how many bytes and percen=<BR>> >tage copied. Leave out "time estimation".<BR>> ><BR>> > And also write "ls.exe".<BR>> ><BR>> > And maybe one last program=2C like "dos2unix.exe" or "fix_nl.exe" that alt=<BR>> >ers newlines. This program should work on files that don't fit in memory.<BR>> ><BR>> <BR>> I use the rdwrreset package under PM3. It solves the most glaring problems.<BR>> But clearly the file sizes should be done with some sort of data structure<BR>> different from 32-bit INTEGER. ARRAY [0..1] OF INTEGER seems to be a<BR>> candidate...<BR>> <BR>> ...<BR>> >Also think about what an idea representation of time is.<BR>> ><BR>> >Isn't a 64bit integer number of units smaller than a second a very good one=<BR>> >?<BR>> <BR>> Modula-3 already uses floating point for this, which has the advantage<BR>> you don't need to worry what the base is. <BR>> <BR>> ><BR>> >And aren't infix operators darned nice?<BR>> <BR>> I have mixed feelings about this. Yes, but... every infix operator takes<BR>> several lines of language definition. Those lines can turn into ungodly<BR>> amounts of code somewhere.<BR>> <BR>> I actually do like Hendrik's idea of providing some sort of bignum<BR>> support. The reason I don't like LONGINT as much is that it seems it's<BR>> just a waste if we're all going to be using 64-bit machines anyhow.<BR>> It's arbitrary to have two fixed-width types. Why not three or four?<BR>> And why not 128 bits or 16 bits or 36 bits? If on the other hand<BR>> you got something substantial out of it that might be another story.<BR>> In that case, I would say LONGINT would be a reference type (much like<BR>> TEXT) with its associated Longint interface, and infix operators (the<BR>> way TEXT has &) per Jay's fondest dreams. Come to think of it, <BR>> TEXT and such a LONGINT would have a lot in common. <BR>> <BR>> Mika<BR> </body>
</html>