Janice Caron, el  4 de abril a las 19:47 me escribiste:
> On 04/04/2008, Janice Caron <caron800@googlemail.com> wrote:
> > On 04/04/2008, Simen Kjaeraas <simen.kjaras@gmail.com> wrote:
> >
> > >  Now to find a better name than paintable, and convincing Walter...
> >
> >
> > Actually, all fields are paintable by default. It's the /un/paintable
> >  ones that need a keyword. In C++, that keyword is "mutable", but
> >  that's inappropriate for D.
> 
> My favorite keyword for this purpose is "exotic". Exotic fields exhibit strange behavior - you can't paint them with constancy; they should take no part in opEquals() or opCmp() or hash(). Strange indeed. And while "unpaintable" is very useful as a description, it is a little on the long side for an actual keyword.

All you are describing is data that don't belong to the class, so why to insist in putting in it?

> That said, I'm with Stephen on this one. If we get the functionality, I won't be complaining about the keyword.

The functionality is already there!

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
FINALMENTE EL CABALLITO FABIAN VA A PASAR UNA BUENA NAVIDAD
	-- Crónica TV

Janice Caron wrote:

> On 04/04/2008, Jason House <jason.james.house@gmail.com> wrote:
>> Most of the later terms seem confusable with non-changing data instead of type. I like the term isolate the best.
> 
> Yeah, it's true - the thing that gets frozen is the /type/, not the /value/, so any word that is a synonym for const would be s-o-o-o-o confusing.
> 
> I recently suggested to Steve that we use an adverb instead of an adjective

What about always?  It's short and seems to work pretty well.

always invariant C x;
always const C y;
always C z;

My only concern is that stuff like "always int x = 5" could be confused as a constant.

On 05/04/2008, Jason House <jason.james.house@gmail.com> wrote:
>  My only concern is that stuff like "always int x = 5" could be confused as a
>  constant.

And let's not forget, the most common use is likely to be to make a mutable field, as in C++. Using a word that suggests const to make something permanently not-const is going to serious compromise the learning curve.

That's why I stuck with "unpaintable" for the description. It's a visual metaphor that's easy to picture. You can imagine mutable as white, invariant as grey, const as black, and operations like const(T) as going over T with a pot of black paint. Unpaintable fields are coated with varnish that paint won't stick to. It's not a bad metaphor, but, is "paint" the right verb for "change the constancy?" - I don't know.

I guess it's always indicative that an idea is generally liked, when people start arguing about what to call it, so that's great. What I would like to know, though, is this: Does anyone still think that this "breaks the const system"? Is there any reason to suppose that Steve and I missed something, and this will make the whole type system fall over? After all, Walter said, and here I quote word-for-word: "I suspect that logical const is like perpetual motion - if you think you've solved it, you've just made a mistake somewhere". So that's the question for me: is there a mistake somewhere? I can't see one, but I was wrong before so that doesn't mean anything.

On Fri, 04 Apr 2008 22:38:51 +0200, Knud Soerensen <4tuu4k002@sneakemail.com> wrote:

>
>> Walter said that having mutable fields breaks the whole const system. He may have been right - but having /unpaintable/ fields is just fine and dandy. Everything works. const(...) and invariant(...) will paint only the paintable fields with constancy, but those fields the paint recursively.
>> 
>> It just works.
>
>I like the idea. Here are some suggestion for a better name.
>isolate
>confine
>detach
>stable
>steady
>stationary
>fixed
>permanent

I'll throw these two suggestions into the mix.

	rigid
	stubborn

Gide

Janice Caron wrote:

> On 05/04/2008, Jason House <jason.james.house@gmail.com> wrote:
>>  My only concern is that stuff like "always int x = 5" could be confused
>>  as a constant.
> 
> And let's not forget, the most common use is likely to be to make a mutable field, as in C++. Using a word that suggests const to make something permanently not-const is going to serious compromise the learning curve.
> 
> That's why I stuck with "unpaintable" for the description. It's a visual metaphor that's easy to picture. You can imagine mutable as white, invariant as grey, const as black, and operations like const(T) as going over T with a pot of black paint. Unpaintable fields are coated with varnish that paint won't stick to. It's not a bad metaphor, but, is "paint" the right verb for "change the constancy?" - I don't know.

I personally really dislike bolting on the whole painting description into how D is explained just so that we can introduce a single keyword.

What I like about always is that it sort of implies its usage and could be placed into documentation with little additional description.  Maybe I'm strange, but "always C c" doesn't say immutable day to me.  It seems sufficiently different and easy enough to remember.  It also has the very nice feature of being short.

Other interesting alternative I thought of is "quarantine".  Walter might like that it'd claim the title of the longest keyword in D :)  If this stuff is impure and can't interact with pure code, it makes sense.

If long code for this funcitonality is ok, I've also wondered about some
kind of static if or version-like funcitonality that can explicity call out
what the type should be when the class is becomes const or invariant.


> I guess it's always indicative that an idea is generally liked, when
> people start arguing about what to call it, so that's great. What I
> would like to know, though, is this: Does anyone still think that this
> "breaks the const system"? Is there any reason to suppose that Steve
> and I missed something, and this will make the whole type system fall
> over?
> After all, Walter said, and here I quote word-for-word: "I
> suspect that logical const is like perpetual motion - if you think
> you've solved it, you've just made a mistake somewhere". So that's the
> question for me: is there a mistake somewhere? I can't see one, but I
> was wrong before so that doesn't mean anything.

I don't think of this stuff as logical const.  Logical const allows const functions to access mutable data.  As proposed, this does not allow that.

Of course, Walter has stayed out of this whole discussion, so we don't know his thoughts.  I get the impression, however, that Walter won't get drawn into design debates until he knows his opinion on it...  Meaning that he'll either argue adamantly against something and then reverse his opinion in a bombshell e-mail or stay quiet.  If only someone could find out what he and Andrei are thinking about this.

On 05/04/2008, Jason House <jason.james.house@gmail.com> wrote:
>  Other interesting alternative I thought of is "quarantine".  Walter might
>  like that it'd claim the title of the longest keyword in D :)

On that basis, let's call it supercalifragisticexpialidocious :-)

> I don't think of this stuff as logical const.  Logical const allows const
>  functions to access mutable data.

Like this, you mean?

    class C
    {
        supercalifragisticexpialidocious int x;

        int f() const
        {
            return ++x;
        }
    }

> As proposed, this does not allow that.

I think you'll find it does. :-)

Jason House wrote:
> Janice Caron wrote:
> 
>> On 05/04/2008, Jason House <jason.james.house@gmail.com> wrote:
>>>  My only concern is that stuff like "always int x = 5" could be confused
>>>  as a constant.
>> And let's not forget, the most common use is likely to be to make a
>> mutable field, as in C++. Using a word that suggests const to make
>> something permanently not-const is going to serious compromise the
>> learning curve.
>>
>> That's why I stuck with "unpaintable" for the description. It's a
>> visual metaphor that's easy to picture. You can imagine mutable as
>> white, invariant as grey, const as black, and operations like const(T)
>> as going over T with a pot of black paint. Unpaintable fields are
>> coated with varnish that paint won't stick to. It's not a bad
>> metaphor, but, is "paint" the right verb for "change the constancy?" -
>> I don't know.
> 
> I personally really dislike bolting on the whole painting description into
> how D is explained just so that we can introduce a single keyword.
> 
> What I like about always is that it sort of implies its usage and could be
> placed into documentation with little additional description.  Maybe I'm
> strange, but "always C c" doesn't say immutable day to me.  It seems
> sufficiently different and easy enough to remember.  It also has the very
> nice feature of being short.
> 
> Other interesting alternative I thought of is "quarantine".  Walter might
> like that it'd claim the title of the longest keyword in D :)  

I think "foreach_reverse" holds that claim to fame.  You won't unseat it with "quarantine".

> Of course, Walter has stayed out of this whole discussion, so we don't know
> his thoughts.  I get the impression, however, that Walter won't get drawn
> into design debates until he knows his opinion on it...  Meaning that he'll
> either argue adamantly against something and then reverse his opinion in a
> bombshell e-mail or stay quiet.  If only someone could find out what he and
> Andrei are thinking about this.

My guess is that if Walter is even aware of what the discussion is about, he's thinking "now is not the time".  Similar to what he said about pure recently.  His plan is to make it restrictive at first, and if that works out well, then perhaps gradually play around with lifting restrictions.  This is similar.  It doesn't require a fundamental redesign.  It can be bolted on later after the basics are all worked out as far as I can tell.

--bb

Janice Caron wrote:

> On 05/04/2008, Jason House <jason.james.house@gmail.com> wrote:
>>  Other interesting alternative I thought of is "quarantine".  Walter
>>  might like that it'd claim the title of the longest keyword in D :)
> 
> On that basis, let's call it supercalifragisticexpialidocious :-)

you'll really mess people up by spelling it wrong ;)
proper spelling: supercalifragilisticexpialidocious

> 
>> I don't think of this stuff as logical const.  Logical const allows const
>>  functions to access mutable data. As proposed, this does not allow that.
> 
> I think you'll find it does. :-)

Quoting your post that started this thread:

"For functional programming to work, you need one additional restriction: pure functions are only allowed to access fields which are either paintable or invariant. (In the current regime, all fields are paintable)."

Looking back, I guess I was mixing what should be done for const and what should be done for FP.  I think this mixing is too common in our threads and has led to tons of miscommunication.

It really unfortunate that we use FP as our justification for const stuff but then design const that really isn't useful for FP.

Janice Caron wrote:
> [...]

How about reusing volatile for the keyword?

Janice Caron Wrote:

...
> What we do is this: we classify every field of a class/struct/union as being either "paintable" or "unpaintable". (Fields which would be called "mutable" in C++ are called "unpaintable" here).
...

I'm not convinced that you and Steven are right about this, but this idea by itself seems interesting ... in a way, it seems like a way to parameterize a type on type modifiers, i.e. in the same way that templates currently can parameterize on types.

This might be interesting for a number of different applications.  If nothing else, it would be interesting if a function could do something like this:

int foo(typemod C1, typemod C2, T2)(C1 char[] a, C2 T2 b)
{
    // do something non-mutating with a and b.
}

This would allow parameterizing on (and maybe deduction of) type modifiers like const and volatile and permit code to be written with both invariant and non-invariant data, reducing code duplication.  Of course, some duplication could probably be removed now using mixins but its more complex.

Kevin