[M3devel] range analysis?

[Daniel Alejandro Benavides D.]

Hi all:
well that said, please you may take a look at this manual (from p8):
http://research.microsoft.com/en-us/um/people/blampson/32a-CedarLang/32a-CedarLangOCR.doc

Modula-3 has an action semantics description (not very notorious):
http://www.dcs.gla.ac.uk/~daw/publications/M3AS.ps

And in the same way:
http://research.microsoft.com/en-us/um/people/blampson/48-POCScourse/48-POCS2006.pdf
page 24

Thanks in advance, hope it helps a bit

--- El mié, 25/5/11, Rodney M. Bates <rodney_bates at lcwb.coop> escribió:

> De: Rodney M. Bates <rodney_bates at lcwb.coop>
> Asunto: Re: [M3devel] range analysis?
> Para: m3devel at elegosoft.com
> Fecha: miércoles, 25 de mayo, 2011 10:55
> 
> 
> On 05/24/2011 03:21 PM, Mika Nystrom wrote:
> > "Rodney M. Bates" writes:
> > ...
> >>
> >> My first thought was that this argument is no more
> or less applicable to
> >> a procedure type containing a formal of empty type
> than to a record
> >> type containing a field (which is currently
> defined as a variable)
> >> of empty type.  Both are just types
> constructed from other type(s),
> >> to be maybe instantiated later.  In the case
> of the record, we now
> >> disallow the type to be constructed.  Your
> proposal would inconsistently
> >> allow the procedure type to be constructed but
> complain when an
> >> attempt is made to instantiate it (i.e., call it)
> later.
> >>
> >> My second thought was that a procedure type with
> empty-typed formal
> >> is not an empty type, because it contains the
> perfectly legitimate
> >> value NIL, which of course, you can't call anyway,
> thus avoiding the
> >> issue of instantiating the formal.  This is
> an essential difference
> >> that would justify doing it differently for
> records and procedures.
> >>
> >
> > By this logic, shoudln't you also allow such types to
> be fields
> > in OBJECT types?
> 
> Yes. But neither the language nor the compiler allow
> this.  The
> compiler gives no error on subsequent attempt to allocate
> such an object,
> but this is probably just secondary.
> 
> What about REF RECORD types?
> 
> REF EmptyType is OK, and the compiler allows it to be
> defined
> but not allocated.  But the only ways right now to get
> an empty
> type are an empty enumeration, empty subrange, or array of
> empty-typed elements.  Try to construct a record with
> an
> empty-typed field and the type definition fails.
> 
> I am doing more compiler experiments and language reading.
> It looks like we have some inconsistencies.
> 
> >
> >      Mika
> >
>