• Nick Sabalausky (2/2) Nov 24 2009 I don't suppose there's any chance that ugly design will be getting clea...
• Jason House (2/4) Nov 24 2009 I'm with you, but you have quite an uphill battle. Both Andrei and Walte...
• bearophile (7/8) Nov 24 2009 Manifest constants defined with enum look a little ugly, and I too don't...
• yigal chripun (7/21) Nov 24 2009 Manifest constants reflect a toolchain problem and *not* a naming proble...
• Nick Sabalausky (32/49) Nov 25 2009 One idea I've had is to keep the feature mainly as-is, but acknowledge t...
• bearophile (6/20) Nov 25 2009 One not written rule of D design seems to be that it must require a simp...
• Nick Sabalausky (16/27) Nov 25 2009 True, but the metaprogramming, or at least the CTFE, would seem to be a
• bearophile (8/12) Nov 25 2009 I think this is not so easy to do.
• retard (9/21) Nov 25 2009 Why can't we just focus on getting D 2.0 done now. The D community seems...
• Leandro Lucarella (11/20) Nov 25 2009 OTOH, there is no virtual or inline keywork, so it's a little

"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? 

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.

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.


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

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.
 

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. 

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


 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

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

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

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

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.

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