View mode: basic / threaded / horizontal-split · Log in · Help
July 01, 2005
Re: Immutable arrays for Walter and rest of us.
Regan,
Readonly flag is technicaly difficult and inefficient to implement.

Any access to the pointer(sic!) and array shall check first this flag
in runtime. Second problem is that you need to store somewhere
this bit. Where?

Proposed solution is just static (compile time)  test.

Moving conditions which can be checked in compile to runtime
is generally not a good idea - non-efficient and difficult
to verify in full.

To be short, in runtime you may get following:

<quote>
Ariane 5 Rocket Disaster

The Ariane 5 Rocket was made by the European Space Agency. In simple terms 
Navigational software was used from the Ariane 4 in the more powerful Ariane 
5. The computer was programmed with a safety feature which aborted the 
mission and caused the rocket to self destruct if it went off course.

Due to an error in the navigation calculations, however, the Arian 5 self 
destructed - even though it was on course to its planned destination.
Investigators later discovered that the cause of the Ariane 5 disaster was 
attributed to calculations based on the Ariane 4 dimensions and power.

</quote>

If it is possible to verify conditions in CT you'd better do it there.

PS: Ariane software is written in ADA, afaik.

Andrew.


"Regan Heath" <regan@netwin.co.nz> wrote in message 
news:opss7fh6dr23k2f5@nrage.netwin.co.nz...
> On Thu, 30 Jun 2005 11:19:38 -0700, Walter <newshound@digitalmars.com> 
> wrote:
>> What is the difference between that and C++'s const as a type modifier?
>>
>> C++:
>>     typename const *
>> Proposal:
>>     typename # *
>
> Nothing, which is why I prefer the idea I've been bandying (sp?) around 
> here for the past month. Please read carefully this is _not_ the same 
> thing.
>
> A readonly compile time, and perhaps also runtime (disabled for -release) 
> readonly bit flag for all variables.
>
> Initialised to 'false'.
>
> Set to 'true' in the presence of "readonly" as a type modifier.
>
> Set to 'true' when passed as an 'in' parameter.
>
> Compiler errors on all operations that mutate a readonly flagged variable.
>
> Example usage:
>
> class Foo {
>   char[] data;
>   readonly char[] get() { return data; }
> }
>
> void foo(inout char[] data) { data[0] = 'a'; }
>
> Foo f = new Foo();
> char[] p = f.get();
> p[0] = 'a'; //error cannot mutate readonly
> foo(p); //error passing readonly as mutable
>
> void foo(char[] data) { data[0] = 'a'; } //error cannot mutate readonly
>
> IMPORTANT: this does not create a seperate distinct type, "readonly 
> char[]" is not a different type to "char[]" it's the same type with it's 
> readonly flag set to 'true'.
>
> The reason this is important is that it stops this situation...
>
> char[] s;
> ..s used as temp var here..
> readonly char[] p = f.get();
> s = p; //error s is not readonly
>
> Which is just plain irritating. People typically solve the above by 
> casting the readonly away. Not good. In the above 's's readonly flag is 
> set on assignment, it becomes readonly.
>
> The readonly flag would be set to false when passed as 'out', or on 
> assignment to a rhs which has readonly=false (including null).
>
> A runtime flag is required for cases like:
>
> char[] p = test ? some_string : f.get();
> p[1] = 'd'; //is 'p' readonly if some_string isn't?
>
> where the compiler cannot tell at compile time.
>
> The runtime flag would be present in every single variable, disabled 
> y  -release and/or it's own compile time flag (perhaps disabled by default 
> like -unittest)
>
> Regan
July 01, 2005
Re: [$] Array Length Syntax (Was immutable arrays...)
On Fri, 1 Jul 2005 02:46:41 +0000 (UTC), AJG <AJG_member@pathlink.com>  
wrote:
> Awesome, thanks. I use length a lot, so $ is great.
>
> Anybody have any concerns about this usage?:
>
> // Easy way to get last element.
> int lastItem = someArray[--$];

And pull it off, so to speak (you're decrementing the length, or trying  
to).

Does that work? AFAIK you cannot say "--someArray.length" as length is a  
property i.e not an lvalue

I write someArray[$-1] to get the last element.

Regan

> Cheers,
> --AJG.
>
>
> In article <da1q3p$26jr$1@digitaldaemon.com>,
> =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...
>>
>> AJG wrote:
>>
>>> Oh, and what is [$]? I've never seen that one before...
>>
>> "length", for arrays. As in this "remove":
>> array = array[0 .. i-1] ~ array[i+1 .. $];
>>
>> --anders
>
> ========================
> if (!sin) throw rock[0];
July 01, 2005
Re: Immutable arrays for Walter and rest of us.
On Thu, 30 Jun 2005 19:52:53 -0700, Andrew Fedoniouk  
<news@terrainformatica.com> wrote:
> Readonly flag is technicaly difficult and inefficient to implement.

The runtime or the compile time one? (you seem not to realise I am talking  
about *both*)

> Any access to the pointer(sic!) and array shall check first this flag
> in runtime.

Yes. When you enable the runtime DBC feature you'll get this, just like  
array bounds checks.

> Second problem is that you need to store somewhere
> this bit. Where?

1 bit in every single variable.

> Proposed solution is just static (compile time)  test.

Mine is first a compile time suggestion, followed by a runtime one (as  
it's been shown that some cases exist where compile time check is  
impossible)

> Moving conditions which can be checked in compile to runtime
> is generally not a good idea - non-efficient and difficult
> to verify in full.

Like I said above, my primary suggestion is a compile time one, it has  
been shown not all cases can be verified at compile time, as such a  
runtime solution is required.

> To be short, in runtime you may get following:

<snip>

I can't see how this is even relevant.

Regan


> Andrew.
>
>
> "Regan Heath" <regan@netwin.co.nz> wrote in message
> news:opss7fh6dr23k2f5@nrage.netwin.co.nz...
>> On Thu, 30 Jun 2005 11:19:38 -0700, Walter <newshound@digitalmars.com>
>> wrote:
>>> What is the difference between that and C++'s const as a type modifier?
>>>
>>> C++:
>>>     typename const *
>>> Proposal:
>>>     typename # *
>>
>> Nothing, which is why I prefer the idea I've been bandying (sp?) around
>> here for the past month. Please read carefully this is _not_ the same
>> thing.
>>
>> A readonly compile time, and perhaps also runtime (disabled for  
>> -release)
>> readonly bit flag for all variables.
>>
>> Initialised to 'false'.
>>
>> Set to 'true' in the presence of "readonly" as a type modifier.
>>
>> Set to 'true' when passed as an 'in' parameter.
>>
>> Compiler errors on all operations that mutate a readonly flagged  
>> variable.
>>
>> Example usage:
>>
>> class Foo {
>>   char[] data;
>>   readonly char[] get() { return data; }
>> }
>>
>> void foo(inout char[] data) { data[0] = 'a'; }
>>
>> Foo f = new Foo();
>> char[] p = f.get();
>> p[0] = 'a'; //error cannot mutate readonly
>> foo(p); //error passing readonly as mutable
>>
>> void foo(char[] data) { data[0] = 'a'; } //error cannot mutate readonly
>>
>> IMPORTANT: this does not create a seperate distinct type, "readonly
>> char[]" is not a different type to "char[]" it's the same type with it's
>> readonly flag set to 'true'.
>>
>> The reason this is important is that it stops this situation...
>>
>> char[] s;
>> ..s used as temp var here..
>> readonly char[] p = f.get();
>> s = p; //error s is not readonly
>>
>> Which is just plain irritating. People typically solve the above by
>> casting the readonly away. Not good. In the above 's's readonly flag is
>> set on assignment, it becomes readonly.
>>
>> The readonly flag would be set to false when passed as 'out', or on
>> assignment to a rhs which has readonly=false (including null).
>>
>> A runtime flag is required for cases like:
>>
>> char[] p = test ? some_string : f.get();
>> p[1] = 'd'; //is 'p' readonly if some_string isn't?
>>
>> where the compiler cannot tell at compile time.
>>
>> The runtime flag would be present in every single variable, disabled
>> y  -release and/or it's own compile time flag (perhaps disabled by  
>> default
>> like -unittest)
>>
>> Regan
>
>
July 01, 2005
Re: Immutable arrays for Walter and rest of us.
"Regan Heath" <regan@netwin.co.nz> wrote in message 
news:opss7xxlgs23k2f5@nrage.netwin.co.nz...
> On Thu, 30 Jun 2005 19:52:53 -0700, Andrew Fedoniouk 
> <news@terrainformatica.com> wrote:
>> Readonly flag is technicaly difficult and inefficient to implement.
>
> The runtime or the compile time one? (you seem not to realise I am talking 
> about *both*)
>
>> Any access to the pointer(sic!) and array shall check first this flag
>> in runtime.
>
> Yes. When you enable the runtime DBC feature you'll get this, just like 
> array bounds checks.
>
>> Second problem is that you need to store somewhere
>> this bit. Where?
>
> 1 bit in every single variable.

The question is: where this bit is located?
array variable is 32bit ptr (64bit) and 32bit (64bit) length.
pointer variable is 32bit (64bit). So where is the place for it?
In additional machine word which will be assosiated with
each variable?

>
>> Proposed solution is just static (compile time)  test.
>
> Mine is first a compile time suggestion, followed by a runtime one (as 
> it's been shown that some cases exist where compile time check is 
> impossible)
>
>> Moving conditions which can be checked in compile to runtime
>> is generally not a good idea - non-efficient and difficult
>> to verify in full.
>
> Like I said above, my primary suggestion is a compile time one, it has 
> been shown not all cases can be verified at compile time, as such a 
> runtime solution is required.

Universal solution is to have opAssign, etc.
So extreme cases can be handled by declaring
your own structures/classes.
Having hidden bit (if it is possible at all) for only
arrays and pointers is little bit unnatural, imho.

>
>> To be short, in runtime you may get following:
>
> <snip>
>
> I can't see how this is even relevant.
>
> Regan
>
>
>> Andrew.
>>
>>
>> "Regan Heath" <regan@netwin.co.nz> wrote in message
>> news:opss7fh6dr23k2f5@nrage.netwin.co.nz...
>>> On Thu, 30 Jun 2005 11:19:38 -0700, Walter <newshound@digitalmars.com>
>>> wrote:
>>>> What is the difference between that and C++'s const as a type modifier?
>>>>
>>>> C++:
>>>>     typename const *
>>>> Proposal:
>>>>     typename # *
>>>
>>> Nothing, which is why I prefer the idea I've been bandying (sp?) around
>>> here for the past month. Please read carefully this is _not_ the same
>>> thing.
>>>
>>> A readonly compile time, and perhaps also runtime (disabled 
>>> or  -release)
>>> readonly bit flag for all variables.
>>>
>>> Initialised to 'false'.
>>>
>>> Set to 'true' in the presence of "readonly" as a type modifier.
>>>
>>> Set to 'true' when passed as an 'in' parameter.
>>>
>>> Compiler errors on all operations that mutate a readonly flagged 
>>> variable.
>>>
>>> Example usage:
>>>
>>> class Foo {
>>>   char[] data;
>>>   readonly char[] get() { return data; }
>>> }
>>>
>>> void foo(inout char[] data) { data[0] = 'a'; }
>>>
>>> Foo f = new Foo();
>>> char[] p = f.get();
>>> p[0] = 'a'; //error cannot mutate readonly
>>> foo(p); //error passing readonly as mutable
>>>
>>> void foo(char[] data) { data[0] = 'a'; } //error cannot mutate readonly
>>>
>>> IMPORTANT: this does not create a seperate distinct type, "readonly
>>> char[]" is not a different type to "char[]" it's the same type with it's
>>> readonly flag set to 'true'.
>>>
>>> The reason this is important is that it stops this situation...
>>>
>>> char[] s;
>>> ..s used as temp var here..
>>> readonly char[] p = f.get();
>>> s = p; //error s is not readonly
>>>
>>> Which is just plain irritating. People typically solve the above by
>>> casting the readonly away. Not good. In the above 's's readonly flag is
>>> set on assignment, it becomes readonly.
>>>
>>> The readonly flag would be set to false when passed as 'out', or on
>>> assignment to a rhs which has readonly=false (including null).
>>>
>>> A runtime flag is required for cases like:
>>>
>>> char[] p = test ? some_string : f.get();
>>> p[1] = 'd'; //is 'p' readonly if some_string isn't?
>>>
>>> where the compiler cannot tell at compile time.
>>>
>>> The runtime flag would be present in every single variable, disabled
>>> y  -release and/or it's own compile time flag (perhaps disabled by 
>>> default
>>> like -unittest)
>>>
>>> Regan
>>
>>
>
July 01, 2005
Re: Immutable arrays for Walter and rest of us.
On Thu, 30 Jun 2005 23:10:00 -0700, Andrew Fedoniouk  
<news@terrainformatica.com> wrote:
> "Regan Heath" <regan@netwin.co.nz> wrote in message
> news:opss7xxlgs23k2f5@nrage.netwin.co.nz...
>> On Thu, 30 Jun 2005 19:52:53 -0700, Andrew Fedoniouk
>> <news@terrainformatica.com> wrote:
>>> Readonly flag is technicaly difficult and inefficient to implement.
>>
>> The runtime or the compile time one? (you seem not to realise I am  
>> talking
>> about *both*)
>>
>>> Any access to the pointer(sic!) and array shall check first this flag
>>> in runtime.
>>
>> Yes. When you enable the runtime DBC feature you'll get this, just like
>> array bounds checks.
>>
>>> Second problem is that you need to store somewhere
>>> this bit. Where?
>>
>> 1 bit in every single variable.
>
> The question is: where this bit is located?
> array variable is 32bit ptr (64bit) and 32bit (64bit) length.
> pointer variable is 32bit (64bit). So where is the place for it?
> In additional machine word which will be assosiated with
> each variable?

If that is what is required, yes.

>>> Proposed solution is just static (compile time)  test.
>>
>> Mine is first a compile time suggestion, followed by a runtime one (as
>> it's been shown that some cases exist where compile time check is
>> impossible)
>>
>>> Moving conditions which can be checked in compile to runtime
>>> is generally not a good idea - non-efficient and difficult
>>> to verify in full.
>>
>> Like I said above, my primary suggestion is a compile time one, it has
>> been shown not all cases can be verified at compile time, as such a
>> runtime solution is required.
>
> Universal solution is to have opAssign, etc.

That doesn't give us immutable char[].

> So extreme cases can be handled by declaring
> your own structures/classes.
> Having hidden bit (if it is possible at all) for only
> arrays and pointers is little bit unnatural, imho.

Not just arrays and pointers, everything, even UDT's.

Regan
July 01, 2005
Re: Immutable arrays for Walter and rest of us.
"Regan Heath" <regan@netwin.co.nz> wrote in message 
news:opss714rpw23k2f5@nrage.netwin.co.nz...
> On Thu, 30 Jun 2005 23:10:00 -0700, Andrew Fedoniouk 
> <news@terrainformatica.com> wrote:
>> "Regan Heath" <regan@netwin.co.nz> wrote in message
>> news:opss7xxlgs23k2f5@nrage.netwin.co.nz...
>>> On Thu, 30 Jun 2005 19:52:53 -0700, Andrew Fedoniouk
>>> <news@terrainformatica.com> wrote:
>>>> Readonly flag is technicaly difficult and inefficient to implement.
>>>
>>> The runtime or the compile time one? (you seem not to realise I am 
>>> talking
>>> about *both*)
>>>
>>>> Any access to the pointer(sic!) and array shall check first this flag
>>>> in runtime.
>>>
>>> Yes. When you enable the runtime DBC feature you'll get this, just like
>>> array bounds checks.
>>>
>>>> Second problem is that you need to store somewhere
>>>> this bit. Where?
>>>
>>> 1 bit in every single variable.
>>
>> The question is: where this bit is located?
>> array variable is 32bit ptr (64bit) and 32bit (64bit) length.
>> pointer variable is 32bit (64bit). So where is the place for it?
>> In additional machine word which will be assosiated with
>> each variable?
>
> If that is what is required, yes.

So -release will have sizeof(void*) == 32
and otherwise sizeof(void*) == 64.

Do you *really* think this is a solution?



>
>>>> Proposed solution is just static (compile time)  test.
>>>
>>> Mine is first a compile time suggestion, followed by a runtime one (as
>>> it's been shown that some cases exist where compile time check is
>>> impossible)
>>>
>>>> Moving conditions which can be checked in compile to runtime
>>>> is generally not a good idea - non-efficient and difficult
>>>> to verify in full.
>>>
>>> Like I said above, my primary suggestion is a compile time one, it has
>>> been shown not all cases can be verified at compile time, as such a
>>> runtime solution is required.
>>
>> Universal solution is to have opAssign, etc.
>
> That doesn't give us immutable char[].

It will give you an option:

struct chars {
  private char[] data;
  bit mutableBit;

  void opAssign(chars rightSide)
  {
      if(!mutableBit)
         throw new WellKnownAndExpectedExceptionAndNotAnError;
      ...
  }

}


>
>> So extreme cases can be handled by declaring
>> your own structures/classes.
>> Having hidden bit (if it is possible at all) for only
>> arrays and pointers is little bit unnatural, imho.
>
> Not just arrays and pointers, everything, even UDT's.
>
> Regan
July 01, 2005
Re: Immutable arrays for Walter and rest of us.
On Fri, 1 Jul 2005 00:35:38 -0700, Andrew Fedoniouk  
<news@terrainformatica.com> wrote:
>>>> 1 bit in every single variable.
>>>
>>> The question is: where this bit is located?
>>> array variable is 32bit ptr (64bit) and 32bit (64bit) length.
>>> pointer variable is 32bit (64bit). So where is the place for it?
>>> In additional machine word which will be assosiated with
>>> each variable?
>>
>> If that is what is required, yes.
>
> So -release will have sizeof(void*) == 32
> and otherwise sizeof(void*) == 64.
>
> Do you *really* think this is a solution?

Yes.

Almost all cases are handled at *compile* time, there are very few cases  
which cannot be handled at compile time.

As such the runtime solution is a very small piece of the overall  
solution. It's optional, can be disabled by a switch, and would *only* be  
used during the design stage just like the other DBC features.

>>>>> Proposed solution is just static (compile time)  test.
>>>>
>>>> Mine is first a compile time suggestion, followed by a runtime one (as
>>>> it's been shown that some cases exist where compile time check is
>>>> impossible)
>>>>
>>>>> Moving conditions which can be checked in compile to runtime
>>>>> is generally not a good idea - non-efficient and difficult
>>>>> to verify in full.
>>>>
>>>> Like I said above, my primary suggestion is a compile time one, it has
>>>> been shown not all cases can be verified at compile time, as such a
>>>> runtime solution is required.
>>>
>>> Universal solution is to have opAssign, etc.
>>
>> That doesn't give us immutable char[].
>
> It will give you an option:
>
> struct chars {
>    private char[] data;
>    bit mutableBit;
>
>    void opAssign(chars rightSide)
>    {
>        if(!mutableBit)
>           throw new WellKnownAndExpectedExceptionAndNotAnError;
>        ...
>    }
>
> }

D does not need a string class.

Regan
July 01, 2005
Re: Immutable arrays for Walter and rest of us.
"Andrew Fedoniouk" <news@terrainformatica.com> wrote in message
news:da024r$65o$1@digitaldaemon.com...
> I would like to discuss one of my previous ideas again
> as it seems it was lost in the fire.

I've been discussing this issue with Andrei (of Modern C++ Design fame). He
points out that there are numerous different "const" semantics, each having
their uses and disadvantages. He suggests that all should be supported in
one way or another, and I agree that that would have some advantages.

One of my (several) dislikes with "const" is that most (90% ?) of a
function's parameters are likely to be "const". So one winds up with the C++
aesthetically ugly consequence of "const" here, there, everywhere. And you
can't use it casually here and there, once you start down the road of making
a few functions have "const" parameters, you've got to do it throughout the
program.

So perhaps one could turn that inside out, and make "const" the default for
function parameters. If the parameter was to be changed, it'd be explicitly
marked as "mutable" or some such.

But that runs into another problem. Function local variables, on the other
hand, one would want to be "mutable" by default. There's also the issue that
"const" already exists as a variable storage class.

So far, I haven't thought of anything that makes consistent sense, and
doesn't look like an ugly hack.

One thing I have thought of is a compromise. Change the semantics of
explicitly "in" parameters to be what Andrei calls "deep immutable". Deep
immutable parameters would have unchanging values for the scope of that
parameter, and also every sub-object reachable by that parameter would also
be unchangeable. The values wouldn't change even by another reference or
another thread. (This is quite unlike C++ "const".) "in" would be a promise
by the programmer, and could not be guaranteed by the compiler - but - the
optimizer can take advantage of this promise to generate perhaps
significantly better code. (With C++ "const", values can change at any momen
t by another reference or another thread, making optimizations based on
"const" impossible.)

C++ "const" is enforced by the compiler, but is useless semantic
information. "in" is not enforced by the compiler beyond the trivial, but is
useful semantic information.
July 01, 2005
Re: Immutable arrays for Walter and rest of us.
On Fri, 1 Jul 2005 01:34:31 -0700, Walter <newshound@digitalmars.com>  
wrote:
> But that runs into another problem. Function local variables, on the  
> other hand, one would want to be "mutable" by default.

By function local do you mean "a" or "b" below?

void foo(char[] a)
{
  char[] b;
}

Regan
July 01, 2005
Re: Immutable arrays for Walter and rest of us.
I think he means "b". As opposed to parameter in variables, like "a".
--AJG.

In article <opss8aohii23k2f5@nrage.netwin.co.nz>, Regan Heath says...
>
>On Fri, 1 Jul 2005 01:34:31 -0700, Walter <newshound@digitalmars.com>  
>wrote:
>> But that runs into another problem. Function local variables, on the  
>> other hand, one would want to be "mutable" by default.
>
>By function local do you mean "a" or "b" below?
>
>void foo(char[] a)
>{
>   char[] b;
>}
>
>Regan
1 2 3 4 5
Top | Discussion index | About this forum | D home