www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - unpaintable (the solution to logical const)

reply "Janice Caron" <caron800 googlemail.com> writes:
I was wrong. Stephen was right. (This is great, actually. I love being
wrong because every time I'm wrong, I learn something new. Plus, I
love the debate). Still, I must bow my head to the superior argument.

I'm pretty good at explaining stuff, once I understand it, so I'm
going to try to do that, right now.

The thing is, I didn't actually truly understand why I (and Walter)
was wrong until I made that post about "transitive" being the wrong
word, and "recursive" being the right word, to describe what the
const() operation does. I guess it's all about how you think about
stuff. Words are so important.

So let's reinvent "logical const" from scratch, in a way that will
work for D, if it were to be implemented. For the record, this is
Stephen's idea, not mine - I'm just rewording it - although I do make
/one/ new observation.

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).

When the type-constructor const(...) is applied to a type, all
paintable fields are recursively painted const. (Unpaintable fields
are left alone). That's it!

Similarly, when invariant(...) is applied to a type, all paintable
fields are recursively painted invariant. (And again, unpaintable
fields are left alone).

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).

Because you still have recursion, this buys you enough guarantees to
make D's const system work, to allow functional programming, etc..

One thing Steven /didn't/ think of (or at least, didn't tell us about)
is that it is perfectly possible for a field to be simultaneously both
paintable and invariant. (That's one reason why "mutable" is really
not a good word for "unpaintable"). For example:

    class C
    {
        T a;
        unpaintable T b;
        invariant(T) c;
        unpaintable invariant(T) d;
    }

If we paint this class const, with the const(...) type constructor, we
get a const(C) - the fields of which will look like this:

    // pseudocode
    class const(C)
    {
        const(T) a;
        unpaintable T b;
        const(T) c;
        unpaintable invariant(T) d;
    }

As you can see, the members a and c have been painted const, but the
members b and d have been left alone. They are untouched. They are
/unpainted/. That's what unpaintable means.

Now let's see what a pure function might be allowed to do in such a class:

    class C
    {
        T a;
        unpaintable T b;
        invariant(T) c;
        unpaintable invariant(T) d;

        pure void f() invariant
        {
            auto w = a; /* OK: "this" is invariant */
            auto x = b; /* ERROR: b is unpaintable and not invariant */
            auto y = c; /* OK: "this" is invariant */
            auto z = d; /* OK: d is invariant */
        }
    }

Words matter. What we call things matters. When we use the word
"mutable", it  becomes counterintuitive that a field could be both
mutable and invariant at the same time. But when we use the word
"unpaintable", the mental dichotomy disappears: of /course/ you can
have an invariant field cannot be painted const.

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.
Apr 04 2008
next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Janice Caron" wrote
I was wrong. Stephen was right. (This is great, actually. I love being
 wrong because every time I'm wrong, I learn something new. Plus, I
 love the debate). Still, I must bow my head to the superior argument.

 I'm pretty good at explaining stuff, once I understand it, so I'm
 going to try to do that, right now.
I'm not very good at it apparently :) Glad to see I finally did though...
 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).

 When the type-constructor const(...) is applied to a type, all
 paintable fields are recursively painted const. (Unpaintable fields
 are left alone). That's it!
I like the idea, but not the keyword. It is exactly what I was thinking. I don't like the keyword because it looks to me like pain-table and un-pain-table :)
 One thing Steven /didn't/ think of (or at least, didn't tell us about)
 is that it is perfectly possible for a field to be simultaneously both
 paintable and invariant.
From my original post: "mutable is used as the keyword in C++ to describe this type. However, I do not like this word..." "...We need a word that says "this isn't affected by const or invariant, but it could already be const or invariant". Something that is short and not heavily used in code. Mabye even some form of punctuation." So you must have missed it. It was at the bottom, I guess that should have been more prominent. -Steve
Apr 04 2008
parent reply BCS <BCS pathlink.com> writes:
Steven Schveighoffer wrote:
 
 I like the idea, but not the keyword.
 
every once in a while (about as often as I poke my head into one of these threads) I have the crazy idea that maybe we should just invent new words for the different flavors of const. words that have no connotations that people have to get around. My proposal for the five (?) different consts are: a9ae7ba0-456b-4c61-82f0-93e19802f99f ff535086-ec2c-44bb-90ea-20eb8a46efc3 f025566c-8dff-4f41-b891-f37d19b470bb a8d70a83-022e-43d9-b3a5-c799b86e34eb a491956a-023e-4a60-8eeb-7cb37ef80b13 I'm not sure how well those will parse with the "-"'s <G>
Apr 04 2008
parent Paul D Anderson <paul.d.anderson.removethis comcast.andthis.net> writes:
BCS Wrote:

 Steven Schveighoffer wrote:
 
 I like the idea, but not the keyword.
 
every once in a while (about as often as I poke my head into one of these threads) I have the crazy idea that maybe we should just invent new words for the different flavors of const. words that have no connotations that people have to get around. My proposal for the five (?) different consts are: a9ae7ba0-456b-4c61-82f0-93e19802f99f ff535086-ec2c-44bb-90ea-20eb8a46efc3 f025566c-8dff-4f41-b891-f37d19b470bb a8d70a83-022e-43d9-b3a5-c799b86e34eb a491956a-023e-4a60-8eeb-7cb37ef80b13 I'm not sure how well those will parse with the "-"'s <G>
Those all seem too much alike to me -- I'll probably use "f025566c-8dff-4f41-b891-f37d19b470bb" sometime by mistake when I reallly mean "a491956a-023e-4a60-8eeb-7cb37ef80b13". I suggest "wall", "spear", "rope", "fan" and "snake" I guess the day when we program in a natural language is still a ways off. Paul
Apr 04 2008
prev sibling next sibling parent reply Jason House <jason.james.house gmail.com> writes:
Janice Caron Wrote:

 I was wrong. Stephen was right. (This is great, actually. I love being
 wrong because every time I'm wrong, I learn something new. Plus, I
 love the debate). Still, I must bow my head to the superior argument.
I too like debate, but I almost felt like the thread Stephen started was extremely cyclical... To the point that I was barely reading anything you and Stephen said. Sort of a rhetorical question, but is there a method of debate that could have lead to a faster resolution? A lot of posts looked to be knee-jerk reactions, trying to defend a position rather than understanding what the other person was trying to say.
Apr 04 2008
parent "Janice Caron" <caron800 googlemail.com> writes:
On 04/04/2008, Jason House <jason.james.house gmail.com> wrote:
  Sort of a rhetorical question, but is there a method of debate that could
have lead to a faster resolution?  A lot of posts looked to be knee-jerk
reactions, trying to defend a position rather than understanding what the other
person was trying to say.
That's a misleading impression. We /didn't/ understand what each other was saying, but that's not because of entrenchment. In fact, I think it had a lot more to do with using different words for the same thing, and the same words for different things, and ... you know ... basically just not speaking the same language. But eventually, there's that "ping" moment when you "get it". You said the question was rhetorical, so I guess you know the answer's probably no. Nothing substitutes for debate, except debate. You have to argue, or you don't learn. You'll never find out you're wrong if you don't try to defend your case.
Apr 04 2008
prev sibling next sibling parent reply "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On Fri, 04 Apr 2008 14:11:53 +0200, Janice Caron <caron800 googlemail.com>  
wrote:

     class C
     {
         T a;
         unpaintable T b;
         invariant(T) c;
         unpaintable invariant(T) d;
     }

 If we paint this class const, with the const(...) type constructor, we
 get a const(C) - the fields of which will look like this:

     // pseudocode
     class const(C)
     {
         const(T) a;
         unpaintable T b;
         const(T) c;
         unpaintable invariant(T) d;
     }
What reason would exist for having an unpaintable invariant field? As far as I've understood, invariant is implicitly castable to const, and casting away const/invariant is a Bad Thing, so whether it is const or invariant does little difference, except for functions that demand invariant arguments. In the latter case, the field is in a way 'less constant' when cast to const than for a normal instance, if I have understood things correctly (invariant values will not change, const values might change underneath you).
Apr 04 2008
next sibling parent reply "Janice Caron" <caron800 googlemail.com> writes:
On 04/04/2008, Simen Kjaeraas <simen.kjaras gmail.com> wrote:
  What reason would exist for having an unpaintable invariant field? As far
 as I've understood, invariant is implicitly castable to const
So is mutable. I don't know what the uses would be. C++ doesn't have it. No language that I'm aware of has it. This is new. Like mixins - when they were first introduced, Walter said words to the effect of "I've no idea what these things will be used for, but they might be useful, so let's wait and see". No one is suggesting there is a specific need to create permanently invariant fields, but people /are/ suggesting we need logical const, and this is a solution (...and so far as we are aware, the /only/ solution...) that works. That it gives us unpaintable invariant fields as a side-effect is an interesting bonus.
 and casting
 away const/invariant is a Bad Thing,
Right - which is why this scheme specifically avoids any need to do that. Everything is tightly constrained.
 so whether it is const or invariant
 does little difference, except for functions that demand invariant
 arguments.
And there may well be those - especially when it comes to pure functions.
Apr 04 2008
parent reply "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On Fri, 04 Apr 2008 20:09:43 +0200, Janice Caron <caron800 googlemail.co=
m>  =

wrote:

 On 04/04/2008, Simen Kjaeraas <simen.kjaras gmail.com> wrote:
  What reason would exist for having an unpaintable invariant field? A=
s =
 far
 as I've understood, invariant is implicitly castable to const
So is mutable. I don't know what the uses would be. C++ doesn't have it. No language that I'm aware of has it. This is new. Like mixins - when they were first introduced, Walter said words to the effect of "I've no idea what these things will be used for, but they might be useful, so let's=
 wait and see".

 No one is suggesting there is a specific need to create permanently
 invariant fields, but people /are/ suggesting we need logical const,
 and this is a solution (...and so far as we are aware, the /only/
 solution...) that works. That it gives us unpaintable invariant fields=
 as a side-effect is an interesting bonus.

 and casting
 away const/invariant is a Bad Thing,
Right - which is why this scheme specifically avoids any need to do that. Everything is tightly constrained.
I agree on all points. At first I felt this whole idea was foolish, but = as = I read more and started groking it, I see it has its uses, and the = solution seems elegant.
 so whether it is const or invariant
 does little difference, except for functions that demand invariant
 arguments.
And there may well be those - especially when it comes to pure functio=
ns. It would appear I messed up some text in my post. I was thinking of = /paintable/ invariant fields. Unpaintable ones are ok. Paintable = invariants I'm not so sure of. Take the following example: class foo { invariant int bar; } int somePureFunction(invariant(foo) f) { return f.bar; } void main() { foo f =3D new foo(); auto a =3D somePureFunction(f); const foo g =3D new foo(); auto b =3D somePureFunction(g); // error here, due to g.bar being c= onst, = not invariant } Now to find a better name than paintable, and convincing Walter... -- Simen
Apr 04 2008
next sibling parent "Janice Caron" <caron800 googlemail.com> writes:
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.
Apr 04 2008
prev sibling parent reply "Janice Caron" <caron800 googlemail.com> writes:
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. That said, I'm with Stephen on this one. If we get the functionality, I won't be complaining about the keyword.
Apr 04 2008
parent Leandro Lucarella <llucax gmail.com> writes:
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
Apr 04 2008
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Simen Kjaeraas" wrote
 On Fri, 04 Apr 2008 14:11:53 +0200, Janice Caron
 wrote:

     class C
     {
         T a;
         unpaintable T b;
         invariant(T) c;
         unpaintable invariant(T) d;
     }

 If we paint this class const, with the const(...) type constructor, we
 get a const(C) - the fields of which will look like this:

     // pseudocode
     class const(C)
     {
         const(T) a;
         unpaintable T b;
         const(T) c;
         unpaintable invariant(T) d;
     }
What reason would exist for having an unpaintable invariant field? As far as I've understood, invariant is implicitly castable to const, and casting away const/invariant is a Bad Thing, so whether it is const or invariant does little difference, except for functions that demand invariant arguments. In the latter case, the field is in a way 'less constant' when cast to const than for a normal instance, if I have understood things correctly (invariant values will not change, const values might change underneath you).
I agree that there seems no reason to have an unpaintable invariant type. However, currently the compiler outputs this: class C { invariant(int)* i; } void f(const(C) c) { pragma(msg, typeof(c.i).stringof); } outputs: const(int)* Which seems to me like a mistake, but there is no harm done because you can't change i through a const reference. Having logical const would prevent the painting of i, and then it would remain as invariant(int)*. Having it be invariant always could potentially have some benefits, such as being able to call invariant versions of functions. -Steve
Apr 04 2008
prev sibling parent guslay <guslay gmail.com> writes:
Simen Kjaeraas Wrote:
 
 What reason would exist for having an unpaintable invariant field? As far  
 as I've understood, invariant is implicitly castable to const, and casting  
 away const/invariant is a Bad Thing, so whether it is const or invariant  
 does little difference, except for functions that demand invariant  
 arguments. In the latter case, the field is in a way 'less constant' when  
 cast to const than for a normal instance, if I have understood things  
 correctly (invariant values will not change, const values might change  
 underneath you).
Wow. I should have read this thread earlier today. I too don't see a reason for "unpaintable invariant". If you wrap a class in a const() or invariant(), the constness of its field should only be allowed to increase. c would have to remain invariant. We could define unpaintable/mutable as fields that escape constness promotion. In this scheme, "unpaintable const" would be possible (not sure if it would be meaningful). Such field would remain const in invariant(C). I feel that it would be a little bit complicated. I would stick to field being labeled: unlabeled - follow constness promotion const - at least const, might be promoted to invariant. invariant - never less than invariant unpaintable (mutable) - don't follow constness promotion For my part i like mutable. I think it would have in D the exact same meaning it has in C++. But that's a war that would never end.
Apr 04 2008
prev sibling next sibling parent reply Knud Soerensen <4tuu4k002 sneakemail.com> writes:
 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
Apr 04 2008
next sibling parent Paul D Anderson <paul.d.anderson.removethis comcast.andthis.net> writes:
Knud Soerensen 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
untouchable? impervious? invulnerable? unaffected? erudite? inflexible? unyielding? unreceptive? obdurate? adamant? incorruptible? It's hard to find a word that indicates "this is what I want, don't mess with it" without also evoking constancy. intentional? premeditated? calculated? purposeful? How about our old standy "final"? Paul
Apr 04 2008
prev sibling next sibling parent reply Russell Lewis <webmaster villagersonline.com> writes:
(sigh)  And so another Paint Shed Problem starts.

C'mon folks, everybody knows that the right syntax for this is actually:
	invariant(!const)

(removes tongue from cheek)
Apr 04 2008
parent "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On Fri, 04 Apr 2008 23:38:11 +0200, Russell Lewis  
<webmaster villagersonline.com> wrote:

 (sigh)  And so another Paint Shed Problem starts.

 C'mon folks, everybody knows that the right syntax for this is actually:
 	invariant(!const)

 (removes tongue from cheek)
Actually, seeing as it's the constancy of the variable that is const, we could use const(const) T x, const(invariant) T x, and const() T x. :p
Apr 04 2008
prev sibling next sibling parent reply Jason House <jason.james.house gmail.com> writes:
Most of the later terms seem confusable with non-changing data instead of type.
I like the term isolate the best.

Knud Soerensen 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
Apr 04 2008
parent reply "Janice Caron" <caron800 googlemail.com> writes:
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 - e.g. permanently T x; permanently invariant(T) x; However, neither of us really liked it that much. And then we decided we didn't care, coz what we care about is proving that the system works more than choosing a name for it. :-)
Apr 04 2008
next sibling parent Knud Soerensen <4tuu4k002 sneakemail.com> writes:
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.
What about "frozen" then.
Apr 04 2008
prev sibling parent reply Jason House <jason.james.house gmail.com> writes:
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.
Apr 04 2008
next sibling parent reply "Janice Caron" <caron800 googlemail.com> writes:
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.
Apr 04 2008
parent reply Jason House <jason.james.house gmail.com> writes:
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.
Apr 05 2008
next sibling parent reply "Janice Caron" <caron800 googlemail.com> writes:
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. :-)
Apr 05 2008
parent Jason House <jason.james.house gmail.com> writes:
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.
Apr 05 2008
prev sibling next sibling parent Bill Baxter <dnewsgroup billbaxter.com> writes:
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
Apr 05 2008
prev sibling parent reply "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On Sat, 05 Apr 2008 23:39:37 +0200, Jason House  
<jason.james.house gmail.com> wrote:

 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.
Agreed. 'always' says what I feel this should be. Though if we want a shorter word, what about 'ever'? -- Simen
Apr 06 2008
parent "Hans W. Uhlig" <huhlig clickconsulting.com> writes:
Simen Kjaeraas wrote:
 On Sat, 05 Apr 2008 23:39:37 +0200, Jason House 
 <jason.james.house gmail.com> wrote:
 
 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.
Agreed. 'always' says what I feel this should be. Though if we want a shorter word, what about 'ever'? -- Simen
Or perhaps something like mask a masked variable cannot be painted with any modifiers?
Apr 10 2008
prev sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Jason House wrote:
 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.
All of those suggestions suck :P ... By those, I mean 'allways', 'frozen', 'permanently', Knud's suggestions , Paul's suggestions , etc. Everything you are trying to describe is a *consequence* of the attribute you are trying to describe. (the consequence being that the type remains the same and is not affected by const/invariant of the owning class/struct) But it is not really the nature of attribute. What *really* describes the attribute we want here? 'external'! As in: external invariant C x; external const C y; external C z; The attribute readily describes that such member is not part of the logical state of the owning class/struct. (It may even be possible to reuse this for other things other than const/invariant.) I know that this issue is very subjective, but c'mon, doesn't it make much more sense than other suggestions? (and yes, if we're anal about keywords, we could use 'extern' instead of 'external') -- Bruno Medeiros - Software Developer, MSc. in CS/E graduate http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Apr 27 2008
prev sibling parent Gide Nwawudu <gide btinternet.com> writes:
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
Apr 05 2008
prev sibling next sibling parent Robert Fraser <fraserofthenight gmail.com> writes:
Janice Caron wrote:
 [...]
How about reusing volatile for the keyword?
Apr 05 2008
prev sibling parent Kevin Bealer <kevinbealer gmail.com> writes:
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
Apr 05 2008