[dylan] type checking errors related to raw values

Greeting to all,
and especially to Hannes,


My thoughts here are triggered by Hannes's "random notes". Hannes wrotes
that
Dylan provides <top> as general head of the type system
>
>  Let's approach from another end:
>   <raw-machine-word> -> <raw-object> -> <top> 
>        (see modeling/raw-types and raw-type-macros)  
>   <object> -> <top> 
>        (see modeling/objects)
>
>  Also, in modeling/raw-types, 
>     ^subtype? of  <&raw-type> and <&class>, 
>         as well as <&class> and <&raw-type> 
>    is defined to be false .
----     Which tells us, neither &raw-types nor &class 
----     is a subtype from the other 
> - hold on - we have <class> -> <type> -> <object> -> <top>
>
> And ^subtype? being defined on <&type>, <&type> - whereas <object> is no
type.


My thoughts may be turn into a DEP in the future
So I used the DEP format (without any validation) below.

I hope, I met the topic

 Greetings, 

   pet-ro (Peter Robisch)





============================================================================
=====

Abstract
========= 

 * This DEP-draft provides first hints how to model the Dylan language in
the 
   MetaData format of the EMCA-335 Standard. 

 * In this light it recommends a change to the Open Dylan type hierarchy

Specification
=============

This DEP-draft uses the rational section below to discuss: 

* How to model the dylan language in the MetaData format of the EMCA-335
Standard?
  
This DEP-draft specifies with the help of these rationales:


 #. Rational: How to model the type hierarchy of Open Dylan? 

    We focus on two branches of that hierarchy:
   
    *  <class> -> <type> -> <object> -> <top>

    *  <raw-machine-word> -> <raw-object> -> <top>

    Based on the related rational section below, this specification
    suggests to change the type hierarchy of dylan to the following

    *                           <class> -> <object-type> -> <type> ->
<object> -> <top>
    
    * <raw-machine-word> -> <raw-object> -> <value-type> -> <type> ->
<object> -> <top>

    With this rearrangement one might skip <top>.

    This suggestion is based on the consense that

      *  An instance of  <object-type> is a *self-describing type*, which
         means that the value of the instance carries some denotation
         of the *exact type* of the value

      *  A value type aggregates the one or more values of an
*non-self-describing type*.
         Each value is nothing more than a bunch of bits.
      
      *  Each value type has an associated *boxed type*.

      *  <value-type> does not reflect a value type, but a *boxed
value-type*.

      *  A *boxed value-type* is still a *non-self-describing type* as any
value-type.
         But it carries type information with the value
	

     Therefore this suggestion assumes that the <raw-object> type of Open
Dylan can be interpreted as a boxed value types.
             
     What is specified for Common Language Runtime of .NET might also be
good in Open Dylan

      *  Value Types cannot be further extended, therefore type are sealed
   
         * Does the Open Dylan compiler ensure this for a <raw-object>?



Motivation
==========

Modeling the dylan language via the MetaData format of EMCA-335 is helpful,
because:

 * This opens the door to .PDB, the Portable Debug format. The .PDB format
   is the default format for MS Visual Studio compilers.

   * The Common Compiler Infrastructure (CCI), once writen by Microsoft
Research,
     is able to generate a .PDB file based on the Metadata. It seems
Microsoft provides
     a PDB Writer, a COM library,  with each Common Language Runtime (CLR).
     
     * Source: `Discussions under PDB Writer @ CCI`_
..   _ Discussions under PDB Writer @ CCI:
http://ccimetadata.codeplex.com/discussions/topics/4674/pdb-writer?searchTex
t=PDB Writer

 * This opens the door to support WinRT. The Language Projection feature of
   WinRT is based on the MetaData Format of EMCA-335.

A Note:
  * The current version of the EMCA-335 describes a debugging format, but
that *not* the .PDB format.
    (That's my understanding, feel free to prove that I'm wrong.)



Rational
========

General note:
 
 * A rationale should provide evidence of consensus within the
   community and discuss important objections or concerns raised
   during discussion.



Rational 1: How to model the type hierarchy of Open Dylan? 
----------------------------------------------------------

Our focus here is on these two branches of the Open Dylan type hierarchy.
The current dylan implementation *Open Dylan* uses <top> as root for its
type hierarchy.
   
    *  <class> -> <type> -> <object> -> <top>

       * (see modeling/raw-types and raw-type-macros)  

    *  <raw-machine-word> -> <raw-object> -> <top>
 
       * (see modeling/objects)

An overview over the content of rational 1:

 * Consensus relevant terms
 * Compare terms from DRM, OD and EMCA-335


Consensus relevant terms
^^^^^^^^^^^^^^^^^^^^^^^^

Here we provide consensus relevant terms based on the *CLI-Annotated*. 

*CLI-Annotated* refers to

 * *The Common Language Infrastructure (CLI) Annotated Standard*
   which is a printed and annotated version of the 
   Standard ECMA-335, 2nd Edition (December 2002)

   * `CLI-Annotated @
Amazon<http://www.amazon.com/Common-Language-Infrastructure-Annotated-Standa
rd/dp/0321154932>`
   * `Standard ECMA-335, 2nd Edition, PDF format @ EMCA.org`
   * 

During DEP writing the current Standard EMCA-335, 6nd Edition (June 2012) is
the current. 

  * `Standard ECMA-335, 6nd Edition, Current Version in Feb 2013 <
http://www.ecma-international.org/publications/standards/Ecma-335.htm >`_  



*Objects* are values and it *is always possible* to determine their exact
types
from the value. Exact types of objects are also called *object types*. 
(CLI-Annotated, p.30)

CLI-Annotated describes the MetaData Logical Format in Section 21. 
The TypeDef is described in 21.34. There you can read (CLI-Annotated, p.
397)

  * Any type shall be one, and only one, of

    * Class, derived ultimately from System.Object (EMCA-335, p. 398)
    * Interface
      An interface type is always a partial description of a value,
potentially 
      supported by many object types. (EMCA-335, pp. 27)
      
    * Value type, derived from System.ValueType 
      (And System.ValueType is derived from System.Object)
      Value Types are described values that are represented as sequences of
bits (EMCA-335, p. 27).
      Is is *never* possible to determine the exact type of a value of a
Value Type (EMCA-335, p. 30).



System.ValueType is derived from System.Object. That's not conform with how
Objects and Value Types 
are defined in CLI-Annotated before. Is this legitimated in the context of
providing a MetaData Logical Format 
to freely interpret the CLI-Annotated? 

Enlightment is given by 
       John Gough
       Compiling for the .NET
       Common Language Runtime (CLR)
       Prentice Hall, 2002

                                                                          
       See page 57.

What I learnt from page 57 is written down in the *Specification* section
above.
_______________________________________________
hackers mailing list
[email protected]
https://lists.opendylan.org/mailman/listinfo/hackers