www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Non-enum manifest constants: Pie in the sky?

reply "Nick Sabalausky" <a a.a> writes:
I don't suppose there's any chance that ugly design will be getting cleaned 
up for D2 is there? Or maybe at least potentially on the table for D3? 
Nov 24 2009
next sibling parent reply Jason House <jason.james.house gmail.com> writes:
Nick Sabalausky Wrote:

 I don't suppose there's any chance that ugly design will be getting cleaned 
 up for D2 is there? Or maybe at least potentially on the table for D3? 

I'm with you, but you have quite an uphill battle. Both Andrei and Walter love it. IMHO, enum is a patchwork collection of features... manifest constants, enumerated lists, and bitmasks are all conflated into something rather ugly.
Nov 24 2009
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Jason House:

 IMHO, enum is a patchwork collection of features... manifest constants,
enumerated lists, and bitmasks are all conflated into something rather ugly.<

Manifest constants defined with enum look a little ugly, and I too don't like it, but it's not even a syntax problem, it's a naming problem, so we can survive with it. Do you have ideas for alternative design of manifest constants? (LDC may even not need manifest constants at all, especially when you use link-time optimization). The enumerated lists of D2 may enjoy to grow some built-in way to invert them, and little more. Regarding bitmasks, I don't like how they are implemented in C#. D can do better, while keeping things simple. Do you have ideas for a better design of those three things? (I don't want heavy Java-like enums). Bye, bearophile
Nov 24 2009
next sibling parent yigal chripun <yigal100 gmail.com> writes:
bearophile Wrote:

 Jason House:
 
 IMHO, enum is a patchwork collection of features... manifest constants,
enumerated lists, and bitmasks are all conflated into something rather ugly.<

Manifest constants defined with enum look a little ugly, and I too don't like it, but it's not even a syntax problem, it's a naming problem, so we can survive with it. Do you have ideas for alternative design of manifest constants? (LDC may even not need manifest constants at all, especially when you use link-time optimization). The enumerated lists of D2 may enjoy to grow some built-in way to invert them, and little more. Regarding bitmasks, I don't like how they are implemented in C#. D can do better, while keeping things simple. Do you have ideas for a better design of those three things? (I don't want heavy Java-like enums). Bye, bearophile

Manifest constants reflect a toolchain problem and *not* a naming problem. They exist only because the linker isn't smart enough to optimize immutable variables. LLVM should already have this implemented. regarding Java style enumarations, I disagree that they are too heavy. They are a *much* better design than the C/D/.. design. I think the C style use of enums to implement bit masks is the problem and not the enum itself. there are two better designs IMO: a) low level where you need manual control of the bit patterns - use ubyte/etc directly is more explicit andf therfore better. b) you don't care about the bits themselves and only want to implement OptionA | OptionB efficiently - bit patterns should *not* be exposed and should be encapsulated by a type. Java has a enumSet (I don't remember the exact name) that handles that efficently for you. either way, you shouldn't ever provide an interface for Option flags where the underlining implementation - the bit values are exposed to the user.
Nov 24 2009
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"bearophile" <bearophileHUGS lycos.com> wrote in message 
news:heiaea$1ocp$1 digitalmars.com...
 Jason House:

 IMHO, enum is a patchwork collection of features... manifest constants, 
 enumerated lists, and bitmasks are all conflated into something rather 
 ugly.<

Manifest constants defined with enum look a little ugly, and I too don't like it, but it's not even a syntax problem, it's a naming problem, so we can survive with it. Do you have ideas for alternative design of manifest constants? (LDC may even not need manifest constants at all, especially when you use link-time optimization). The enumerated lists of D2 may enjoy to grow some built-in way to invert them, and little more. Regarding bitmasks, I don't like how they are implemented in C#. D can do better, while keeping things simple. Do you have ideas for a better design of those three things? (I don't want heavy Java-like enums). Bye, bearophile

One idea I've had is to keep the feature mainly as-is, but acknowledge the fact that *actual* enumerations are just a subset of what "enum" does and that these real enumerations are really just multiple manifest constants of a common underlying type put together inside a single namespace that acts as a new type. So instead of having a so-called "enumeration" feature that also does manifest constants, we should have the naming reflect the fact that it's really just a souped-up manifest constant feature. In other words, just like you implied - give it a better name... Too bad "const" is already taken. What would ideally be nice is to rename the current "const" to "readonly" (since that's what it *really* is anyway, the current "const" is nearly as poorly-named as the current "enum"), and then change "enum" to "const". Or take a page from Java and use the word "final" ("final x = 7; final Color {Red, Green}"), which is already a keyword in D anyway. Although all of that would still maintain the oddity that enum, or whatever it's called, sometimes creates a new type and sometimes doesn't. Another good idea is like yigal said, just improve the optimizer so that any immutables whose value is known at compile-time ends up effectively being treated as a manifest constant. Then rip out enum's "enum x = 7;" syntax and be done with it. Yigal also brought up another good point that I had also alluded to recently in a different thread: We could really use a better way to handle lists of enum values that are implemented with bitmasks instead of arrays (and we would still need to maintain the ability to control what bit patterns are used for each option, of course). Currently, doing that requires bypassing the type system to a certain extent. So that really should be improved. Maybe a fix for that could overlap with an improved union, or an improved bit-field concept, maybe involving something like the excellent bit (un)packing syntax in Erlang: http://www.erlang.org/documentation/doc-5.4.12/doc/programming_examples/bit_syntax.html
Nov 25 2009
parent reply bearophile <bearophileHUGS lycos.com> writes:
Nick Sabalausky:

 rename 
 the current "const" to "readonly" (since that's what it *really* is anyway, 
 the current "const" is nearly as poorly-named as the current "enum"), and 
 then change "enum" to "const".

I like something like that. There's another couple of proposals. Let's see if Walter is willing to improve those names.
 Another good idea is like yigal said, just improve the optimizer so that any 
 immutables whose value is known at compile-time ends up effectively being 
 treated as a manifest constant. Then rip out enum's "enum x = 7;" syntax and 
 be done with it.

One not written rule of D design seems to be that it must require a simple and low-tech compiler. That's the only explanation I see for some of the D design decisions that look silly if you think about having a good compiler under it.
 Yigal also brought up another good point that I had also alluded to recently 
 in a different thread: We could really use a better way to handle lists of 
 enum values that are implemented with bitmasks instead of arrays (and we 
 would still need to maintain the ability to control what bit patterns are 
 used for each option, of course). Currently, doing that requires bypassing 
 the type system to a certain extent. So that really should be improved.

This problem may be fixed as bitfields, with a "good enough" mixin added to Phobos2 to define a bitmask. Anyone willing to write it? Bye, bearophile
Nov 25 2009
parent reply "Nick Sabalausky" <a a.a> writes:
"bearophile" <bearophileHUGS lycos.com> wrote in message 
news:hej7tb$k21$1 digitalmars.com...
 Nick Sabalausky:

 Another good idea is like yigal said, just improve the optimizer so that 
 any
 immutables whose value is known at compile-time ends up effectively being
 treated as a manifest constant. Then rip out enum's "enum x = 7;" syntax 
 and
 be done with it.

One not written rule of D design seems to be that it must require a simple and low-tech compiler. That's the only explanation I see for some of the D design decisions that look silly if you think about having a good compiler under it.

True, but the metaprogramming, or at least the CTFE, would seem to be a notable exception to that rule, and unless I'm missing something, that existing metaprogramming should be the only hard part needed for this immutable -> manifest constant idea. So since that metaprogramming is already in place, I would imagine it would be as simple as the compiler looking at any instances of "cast(immutable(Foo))blahExpression" or "immutable(Foo) foo = blahExpression" (and maybe even just "immutable foo = blahExpression;" allowing type inference?), then attempting to evaluate blahExpression at compile-time (which I believe it already does) and if it succeeds, then treat it as a manifest constant in any place where it's used (except for the places where it's pointer or reference is taken). (Or something like that, I admit I'm still a D1 guy and don't have any actual experience using immutable, so might be misunderstanding something about how it's currently used.)
Nov 25 2009
parent bearophile <bearophileHUGS lycos.com> writes:
Nick Sabalausky:

 then attempting to evaluate 
 blahExpression at compile-time (which I believe it already does) and if it 
 succeeds, then treat it as a manifest constant in any place where it's used 
 (except for the places where it's pointer or reference is taken).

I think this is not so easy to do. If the expression is a function the compiler has to be able to decide to see it as a compile-time function or as a normal function. Currently D2 never takes such choice, to keep the compiler simple, and the compilation time predictable and small. "except for the places where it's pointer or reference is taken": I think you meant "its". LLVM is able to do this when you use link-time optimization, but I think currently DMD isn't able to (unless some more logic is added to the middle layer of DMD. See the post of mine about D compiler layers that I'm about to post), so you will end with DMD managing all manifest constants as readonly variables, keeping them in the binary. The current design that tells apart read-only (single-assiment?) values from true (manifest) constants is simpler to implement and in practice does't look like a big burden for the programmer (it's just a little extra complexity), so I can live with it, even if it's something that a good compiler is supposed to do by itself. Manifest constants can even be deprecated in future, once a default implementation of D2 uses a better back-end like LLVM. But I'd like a better naming of those; this is doable and doesn't require lot of work (once the name change is done you can use a search&replace to fix Phobos). Half the battle was to use the "immutable" keyword instead of "invariant", but the work isn't finished yet :-) Bye, bearophile
Nov 25 2009
prev sibling parent retard <re tard.com.invalid> writes:
Wed, 25 Nov 2009 09:29:10 -0500, bearophile wrote:

 Nick Sabalausky:
 
 then attempting to evaluate
 blahExpression at compile-time (which I believe it already does) and if
 it succeeds, then treat it as a manifest constant in any place where
 it's used (except for the places where it's pointer or reference is
 taken).

I think this is not so easy to do.

Why can't we just focus on getting D 2.0 done now. The D community seems to mainly consist of people don't care about getting any work done or having a stable compiler unless it's faster than lightning.
 Manifest constants can even
 be deprecated in future, once a default implementation of D2 uses a
 better back-end like LLVM.

Digitalmars won't have a commercial D SDK product if they switch the backend. I don't think Walter wants to switch to another toolchain. Imagine, someone will gladly pay for fixing the dreaded optlink, but frankly no one will pay for updates to e.g. llvm or gnu gcc toolchain. Even though the quality of gnu toolchain is superior.
Nov 25 2009
prev sibling parent Leandro Lucarella <llucax gmail.com> writes:
bearophile, el 25 de noviembre a las 07:28 me escribiste:
 Another good idea is like yigal said, just improve the optimizer so that any 
 immutables whose value is known at compile-time ends up effectively being 
 treated as a manifest constant. Then rip out enum's "enum x = 7;" syntax and 
 be done with it.

One not written rule of D design seems to be that it must require a simple and low-tech compiler. That's the only explanation I see for some of the D design decisions that look silly if you think about having a good compiler under it.

OTOH, there is no virtual or inline keywork, so it's a little contradictory about this :P I think the specs are just too tied to DMD's capabilities, it's not that it requires a particularly dumb or smart compiler. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- 22% of the time a pizza will arrive faster than an ambulance in Great-Britain
Nov 25 2009