digitalmars.D - unpaintable (the solution to logical const)
- Janice Caron (79/79) Apr 04 2008 I was wrong. Stephen was right. (This is great, actually. I love being
- Steven Schveighoffer (15/29) Apr 04 2008 I like the idea, but not the keyword. It is exactly what I was thinking...
- BCS (12/15) Apr 04 2008 every once in a while (about as often as I poke my head into one of
- Paul D Anderson (5/23) Apr 04 2008 Those all seem too much alike to me -- I'll probably use "f025566c-8dff-...
- Jason House (3/6) Apr 04 2008 I too like debate, but I almost felt like the thread Stephen started was...
- Janice Caron (11/12) Apr 04 2008 That's a misleading impression. We /didn't/ understand what each other
- Simen Kjaeraas (10/27) Apr 04 2008 What reason would exist for having an unpaintable invariant field? As fa...
- Janice Caron (15/22) Apr 04 2008 So is mutable.
-
Simen Kjaeraas
(31/54)
Apr 04 2008
On Fri, 04 Apr 2008 20:09:43 +0200, Janice Caron
- Janice Caron (4/5) Apr 04 2008 Actually, all fields are paintable by default. It's the /un/paintable
- Janice Caron (8/13) Apr 04 2008 My favorite keyword for this purpose is "exotic". Exotic fields
- Leandro Lucarella (11/28) Apr 04 2008 All you are describing is data that don't belong to the class, so why to
- Steven Schveighoffer (19/48) Apr 04 2008 I agree that there seems no reason to have an unpaintable invariant type...
- guslay (10/19) Apr 04 2008 Wow. I should have read this thread earlier today.
- Knud Soerensen (9/16) Apr 04 2008 I like the idea. Here are some suggestion for a better name.
- Paul D Anderson (19/36) Apr 04 2008 untouchable?
- Russell Lewis (4/4) Apr 04 2008 (sigh) And so another Paint Shed Problem starts.
- Simen Kjaeraas (4/8) Apr 04 2008 Actually, seeing as it's the constancy of the variable that is const, we...
- Jason House (2/20) Apr 04 2008
- Janice Caron (11/12) Apr 04 2008 Yeah, it's true - the thing that gets frozen is the /type/, not the
- Knud Soerensen (2/9) Apr 04 2008 What about "frozen" then.
- Jason House (7/17) Apr 04 2008 What about always? It's short and seems to work pretty well.
- Janice Caron (22/24) Apr 04 2008 And let's not forget, the most common use is likely to be to make a
- Jason House (23/50) Apr 05 2008 I personally really dislike bolting on the whole painting description in...
- Janice Caron (12/17) Apr 05 2008 Like this, you mean?
- Jason House (13/23) Apr 05 2008 you'll really mess people up by spelling it wrong ;)
- Bill Baxter (11/46) Apr 05 2008 I think "foreach_reverse" holds that claim to fame. You won't unseat it...
- Simen Kjaeraas (6/12) Apr 06 2008 Agreed. 'always' says what I feel this should be. Though if we want a
- Hans W. Uhlig (3/18) Apr 10 2008 Or perhaps something like mask a masked variable cannot be painted with
- Bruno Medeiros (23/43) Apr 27 2008 All of those suggestions suck :P ... By those, I mean 'allways',
- Gide Nwawudu (6/22) Apr 05 2008 I'll throw these two suggestions into the mix.
- Robert Fraser (2/3) Apr 05 2008 How about reusing volatile for the keyword?
- Kevin Bealer (17/20) Apr 05 2008 ...
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
"Janice Caron" wroteI 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
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
BCS Wrote:Steven Schveighoffer wrote: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. PaulI 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
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
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
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
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 constSo 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
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:s =What reason would exist for having an unpaintable invariant field? A=far as I've understood, invariant is implicitly castable to constSo 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.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.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.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... -- Simenso 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=
Apr 04 2008
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
On 04/04/2008, Janice Caron <caron800 googlemail.com> wrote:On 04/04/2008, Simen Kjaeraas <simen.kjaras gmail.com> wrote: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.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
Janice Caron, el 4 de abril a las 19:47 me escribiste:On 04/04/2008, Janice Caron <caron800 googlemail.com> wrote:All you are describing is data that don't belong to the class, so why to insist in putting in it?On 04/04/2008, Simen Kjaeraas <simen.kjaras gmail.com> wrote: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.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.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
"Simen Kjaeraas" wroteOn Fri, 04 Apr 2008 14:11:53 +0200, Janice Caron wrote: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. -Steveclass 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
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
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
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 permanentuntouchable? 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
(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
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
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
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
Janice Caron wrote:On 04/04/2008, Jason House <jason.james.house gmail.com> wrote:What about "frozen" then.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.
Apr 04 2008
Janice Caron wrote:On 04/04/2008, Jason House <jason.james.house gmail.com> wrote: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.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
Apr 04 2008
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
Janice Caron wrote:On 05/04/2008, Jason House <jason.james.house gmail.com> wrote: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.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.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
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
Janice Caron wrote:On 05/04/2008, Jason House <jason.james.house gmail.com> wrote:you'll really mess people up by spelling it wrong ;) proper spelling: supercalifragilisticexpialidociousOther 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 :-)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.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. :-)
Apr 05 2008
Jason House wrote:Janice Caron wrote:I think "foreach_reverse" holds that claim to fame. You won't unseat it with "quarantine".On 05/04/2008, Jason House <jason.james.house gmail.com> wrote: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 :)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.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
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
Simen Kjaeraas wrote:On Sat, 05 Apr 2008 23:39:37 +0200, Jason House <jason.james.house gmail.com> wrote:Or perhaps something like mask a masked variable cannot be painted with any modifiers?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 10 2008
Jason House wrote:Janice Caron wrote: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#DOn 04/04/2008, Jason House <jason.james.house gmail.com> wrote: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.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
Apr 27 2008
On Fri, 04 Apr 2008 22:38:51 +0200, Knud Soerensen <4tuu4k002 sneakemail.com> wrote:I'll throw these two suggestions into the mix. rigid stubborn GideWalter 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 05 2008
Janice Caron wrote:[...]How about reusing volatile for the keyword?
Apr 05 2008
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