<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">Hi all: I think if we are to type define initialization, we need a kernel to type more fun than rigid Modula-3 semantics: http://www.hpl.hp.com/techreports/Compaq-DEC/SRC-RR-95.pdf That said, we can define a m3kernel sort of type minimal abstraction of a Modula-3 Object, and built on top of that. Advantages are we can type theorize  in every wanted way with it and still protect us from incompatible type systems, by branding the type system to allow smooth transitions. Besides parallelization implicitly in the abstract machine (kernel) and check the type safety of it. Also rewrite the type system in terms of this kernel might get us to a new language in the sense of a language definition smoothly If someone steems this good I can make my try. Thanks in advance --- El vie, 6/7/12, Daniel Alejandro Benavides D.

 <i><dabenavidesd@yahoo.es></i></b> escribió:<br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"><br>De: Daniel Alejandro Benavides D. <dabenavidesd@yahoo.es><br>Asunto: Re: [M3devel] A question for our language lawyers<br>Para: m3devel@elegosoft.com, "Rodney M. Bates" <rodney_bates@lcwb.coop><br>Fecha: viernes, 6 de julio, 2012 14:17<br><br><div id="yiv1031876327"><table border="0" cellpadding="0" cellspacing="0"><tbody><tr><td style="font-family: inherit; font-style: inherit; font-variant: inherit; font-weight: inherit; font-size: inherit; line-height: inherit; font-size-adjust: inherit; font-stretch: inherit;" valign="top">Hi all:<br>English men say array is a sequence of elements (of a common type), and a BOOLEAN is an enumeration so you might attack that distinction to define what is an initialized boolean or array of boolean in common compilers, gcc javac, etc, which if is

 java-like is really undefined:<br> <br>http://www.drdobbs.com/architecture-and-design/the-humble-boolean-deserves-help/232900836?cid=DDJ_nl_upd_2012-05-02_h&elq=cef656ee4d6c4bca996b337620b98f85<br><br>So I prefer non-uniform rules for records different of Sets, Arrays, and records as that, note that NEW expression doesn't allow constructors to be used, so the only thing you can use is array of uninitialized variables (but current gcc or javac, etc are really wrong in that)<br><br>This means we need to address this by either a native backend (NT386) or by another language for that matter.<br><br>Thanks in

 advance for any comments you may have<br><br>--- El <b>vie, 6/7/12, Rodney M. Bates <i><rodney_bates@lcwb.coop></i></b> escribió:<br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"><br>De: Rodney M. Bates <rodney_bates@lcwb.coop><br>Asunto: Re: [M3devel] A question for our language lawyers<br>Para: m3devel@elegosoft.com<br>Fecha: viernes, 6 de julio, 2012 13:27<br><br><div class="yiv1031876327plainMail"><br><br>On 07/06/2012 04:23 AM, Dirk Muysers wrote:<br>> The report says (2.6.9)<br>> "The values in the array will be arbitrary values of their type."<br><br>> Now, ParseParams in its "init" method allocates an array of BOOLEANs<br>> and relies on the fact that it is supposedly initialised with FALSE values.<br><br>> At the other hand the report says (2.2.4)<br>> "The constant |default| is a default value used when a record is constructed or allocated"<br><br>> If I

 allocate an array

 of records, which statement is stronger:<br>> - the array contains arbitray record values ?<br>> - the array record fields will be initialised to their default values?<br><br>Admittedly unclearly if not misleadingly worded.  Better wording might be<br>to say each element is initialized as it would if it were a scalar variable<br>of its type.<br><br>I think the way to interpret this is that the array itself does not impose<br>any initialization, but this fact will not eliminate initialization<br>imposed by other rules, specifically, the type of the array's elements.<br><br>This is a language quirk that I have always been deeply ambivalent about.<br>The type safety would go down the drain if variables were not initialized<br>to a bit pattern that represents some value of the type, so we have to pay<br>the performance penalty of executing initialization code.  So why not define<br>which value of the type is initialized-to and get behavioral

 predictability<br>for free?  And further save redundant initialization in the likely event<br>that the compiler's chosen arbitrary value happens to match what the<br>programmer wants?<br><br>(OK, a smart enough optimizer might figure this out, but we could have<br>had it even with a naive compiler.)<br><br>The contrary case is a type whose compiler-chosen representation happens<br>to use every bit pattern in the allocated space for a value of the type.<br>Here, no compiler-generated runtime initialization is needed.<br><br>Also, the rule we have might sometimes encourage programmers to at least give a<br>millisecond's thought to whether they need to do some explicit initialization.<br><br><br>> The ParseParams "init" method is obviously erroneous and works only<br>> by virtue of a happy combination of circumstances.<br>> But how is the report to be interpreted in the second

 case?<br></div></blockquote></td></tr></tbody></table></div></blockquote></td></tr></table>