[M3devel] A question for our language lawyers

[Jay K]

I quite like the idea that all heap and stack is initialized by zeroing. This is I believe stronger/safer than Modula-3, at least for stack. Anyone want to measure the change? I'd also like to see stack zeroed upon function return, so GC is easier to implement/understand...

From: dmuysers at hotmail.com
To: dabenavidesd at yahoo.es; m3devel at elegosoft.com; rodney_bates at lcwb.coop
Date: Fri, 6 Jul 2012 21:54:54 +0200
Subject: Re: [M3devel] A question for our language lawyers






Daniel, with my apologies, sometimes I wonder if you do it 
on purpose.




From: Daniel Alejandro Benavides D. 
Sent: Friday, July 06, 2012 9:17 PM
To: m3devel at elegosoft.com ; Rodney M. Bates 
Subject: Re: [M3devel] A question for our language 
lawyers



  
  
    Hi all:
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:

http://www.drdobbs.com/architecture-and-design/the-humble-boolean-deserves-help/232900836?cid=DDJ_nl_upd_2012-05-02_h&elq=cef656ee4d6c4bca996b337620b98f85

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)

This means 
      we need to address this by either a native backend (NT386) or by another 
      language for that matter.

Thanks in advance for any comments you 
      may have

--- El vie, 6/7/12, Rodney M. Bates 
      <rodney_bates at lcwb.coop> escribió:

      
De: 
        Rodney M. Bates <rodney_bates at lcwb.coop>
Asunto: Re: [M3devel] 
        A question for our language lawyers
Para: 
        m3devel at elegosoft.com
Fecha: viernes, 6 de julio, 2012 13:27


        

On 07/06/2012 04:23 AM, Dirk Muysers 
        wrote:
> The report says (2.6.9)
> "The values in the array 
        will be arbitrary values of their type."

> Now, ParseParams in 
        its "init" method allocates an array of BOOLEANs
> and relies on 
        the fact that it is supposedly initialised with FALSE 
        values.

> At the other hand the report says (2.2.4)
> 
        "The constant |default| is a default value used when a record is 
        constructed or allocated"

> If I allocate an array of records, 
        which statement is stronger:
> - the array contains arbitray 
        record values ?
> - the array record fields will be initialised to 
        their default values?

Admittedly unclearly if not misleadingly 
        worded.  Better wording might be
to say each element is 
        initialized as it would if it were a scalar variable
of its 
        type.

I think the way to interpret this is that the array itself 
        does not impose
any initialization, but this fact will not eliminate 
        initialization
imposed by other rules, specifically, the type of the 
        array's elements.

This is a language quirk that I have always 
        been deeply ambivalent about.
The type safety would go down the drain 
        if variables were not initialized
to a bit pattern that represents 
        some value of the type, so we have to pay
the performance penalty of 
        executing initialization code.  So why not define
which value of 
        the type is initialized-to and get behavioral predictability
for 
        free?  And further save redundant initialization in the likely 
        event
that the compiler's chosen arbitrary value happens to match 
        what the
programmer wants?

(OK, a smart enough optimizer might 
        figure this out, but we could have
had it even with a naive 
        compiler.)

The contrary case is a type whose compiler-chosen 
        representation happens
to use every bit pattern in the allocated 
        space for a value of the type.
Here, no compiler-generated runtime 
        initialization is needed.

Also, the rule we have might sometimes 
        encourage programmers to at least give a
millisecond's thought to 
        whether they need to do some explicit initialization.


> 
        The ParseParams "init" method is obviously erroneous and works 
        only
> by virtue of a happy combination of circumstances.
> 
        But how is the report to be interpreted in the second 
      case?

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120707/43b9f3ed/attachment-0002.html>