[M3devel] BITSIZE on constants?

[Jay K]

I am NOT asking for untyped constants.
Constants are typed, and BITSIZE ought to work on them. That is what I am asking for:


  CONST a = 1;  
  CONST b = BITSIZE(a);  


 - Jay


> Date: Thu, 20 Dec 2012 16:34:07 -0600
> From: rodney_bates at lcwb.coop
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] BITSIZE on constants?
> 
> 
> 
> On 12/20/2012 02:50 PM, Jay K wrote:
> > I think go has untyped constants.
> 
> Ada has them too, but the rules for when they get implicitly converted to a runtime
> type are, well, IMO, bizarre.
> 
> Even if they were more straightforward, there is inevitably a lot of complexity here
> that few working programmers will learn or think about, instead hoping everything
> will "just work".  This can only be according their individual idea of how it
> should work, which is nowhere close to being either obvious or universal.  Thus
> do very subtle bugs occasionally occur, and cause grief all out of proportion to
> their frequency.
> 
> > But I think Modula-3 constants (expressions) always have a type independent of their use.
> 
> Yes.  All in 2.4.2:
> 
> You can give a constant a type explicitly:
> 
> CONST C : [ - 3 .. 0 ] = - 2;
> 
> in which case, the value must be a member of the type.
> 
> Or you can omit it, in which case, the type of the constant is the type
> of the _expression_.
> 
> CONST D = - 2;
> 
> There are many values that belong to more than one type (e.g., - 2
> belongs to any subrange of INTEGER that contains it).  But every
> expression has exactly one type.  In this case, the type of every
> integer literal is INTEGER.  And unary "-" applied to an INTEGER
> also has type INTEGER, which is the type of D.
> 
> BTW, this is why we need different spellings for INTEGER and
> LONGINT literals, e.g. 10 and 10L.  It avoids a morass of implied
> type conversion rules, etc., that the language already avoided
> before LONGINT.  In fact, the same idea is in the original
> language for the floating point literals, with "E". "D", or
> "X" in the literal spelling, to uniquely denote its type.
> 
> >
> >   - Jay
> >
> >
> >  > Date: Thu, 20 Dec 2012 13:08:08 -0500
> >  > From: hendrik at topoi.pooq.com
> >  > To: m3devel at elegosoft.com
> >  > Subject: Re: [M3devel] BITSIZE on constants?
> >  >
> >  > On Thu, Dec 20, 2012 at 11:16:32AM -0600, Rodney M. Bates wrote:
> >  > >
> >  > >
> >  > > On 12/19/2012 11:08 PM, Jay wrote:
> >  > > >Eh? isn't bitsize(type) valid? It is in C and seems confroversy-free.
> >  > >
> >  > > BITSIZE(type) (and BYTESIZE and ADRSIZE) is indeed valid on a _type_ in
> >  > > Modula-3. At the last paragraph of 2.6.13, it is defined as the size of a
> >  > > _variable_ of that type. The whole idea is that a compiler should not be
> >  > > obligated to store a constant in memory.
> >  > >
> >  > > Presumably, you know statically what the type of a CONST is, so can't you
> >  > > just use BITSIZE(TypeOfConst)? If you later changed the constant
> >  > > to a different type, it wouldn't self-adapt, but likely other places wouldn't
> >  > > either, or maybe would, but not correctly for your program.
> >  >
> >  > Consider BITSIZE(-3). Doesn't it make a difference whether this -3 is
> >  > to be considered as of type -3..0 or INTEGER, or even -3..-3? THis
> >  > isn't inherent in the constant, and might on some implementations give
> >  > BITSIZEs of 2, 64, or even 0, respectively, if meaningful.
> >  >
> >  > And if you were to change the language syntax so you'd always have to
> >  > write something like (-3..0)(-3) to be explicit you'd end up writing
> >  > everything you's write with BITSIZE(TypeOfConst) and more. What you
> >  > might gain is a static check that the constant isn't out of bounds.
> >  >
> >  > -- hendrik
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20121221/63955c9c/attachment-0002.html>