[M3devel] Integer literals

[Tony Hosking]

No!  You're missing my whole point about representation.  With what you are proposing here for the float types you will end up with implicit conversion operations performed in the hardware.  The whole idea with explicit conversions is that programmers don't end up coding something that they have not transparently written.  That is a fundamental and highly-valued design principle with Modula-3.  We are not trying to reinvent C here.

On 10 Jan 2010, at 15:43, Jay K wrote:

> Seems fine either way.
> Assignability gives us, which we were missing before, VAR a:LONGINT := 0;
> 
> 
>  > (Yes, I know that the REAL/LONGREAL/EXTENDED literals are all distinct, but they really
>  > do have incompatible value representations).
>  
>  
> I keep seeing this and am surprised.
> Isn't it the case that REAL <= LONGREAL <= EXTENDED
> in terms of precision and range?
> LONGREAL can losslessly represent all the values that REAL can represent, and possibly more (yes);
> EXTENDED can losslessly representa ll the values that LONGREAL can represent, and possibly more (not);
>  
>  
> And then, if that is true, mixing should be allowed..widen any constituents
> in an expression to the widest type.
>  
>  
> I realize mixing floating point and integer is less natural, nothing about
> floating point is natural really, though on a 32bit platform
> LONGREAL can hold all INTEGERS..
> 
>  - Jay
> 
>  
> From: hosking at cs.purdue.edu
> Date: Sun, 10 Jan 2010 15:23:28 -0500
> To: m3devel at elegosoft.com
> Subject: [M3devel] Integer literals
> 
> One thing I've really struggled with over the introduction of LONGINT is the need for distinct literal forms.  This strikes me as odd, since literals are really just ways of writing values, rather than stating anything about how they should be represented.
> (Yes, I know that the REAL/LONGREAL/EXTENDED literals are all distinct, but they really do have incompatible value representations).
> 
> It strikes me that with checked assignability for INTEGER/LONGINT we could also potentially treat integer literals as essentially "untyped" (neither INTEGER nor LONGINT). (I still strongly resist going the route of having mixed type operands for arithmetic...)
> 
> Here's how things would work with subrange types.
> 
> A subrange written as currently
> 
> [lo .. hi]
> 
> would by default be assumed to have base type INTEGER.  The constants lo/hi must both be in range for INTEGER.
> 
> A subrange with base type LONGINT would be written explicitly:
> 
> [lo .. hi] OF LONGINT
> 
> The constants lo/hi must both be in range for LONGINT.
> 
> We could also support the form:
> 
> [lo .. hi] OF INTEGER
> 
> just for consistency though the "OF INTEGER" qualification would be unnecessarily verbose.
> 
> Here we are allowing the programmer to state explicitly what the base type of the subrange should be.
> 
> Literals would be be range-checked when used as arithmetic operands or in assignment, with compile-time checks that they are in range ("compatible") with the types of the other operands or the destination of the assignment.
> 
> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office  +1 765 494 6001  +1 765 494 6001 | Mobile  +1 765 427 5484  +1 765 427 5484
> 
> 
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100110/2a12f6e5/attachment-0002.html>