View mode: basic / threaded / horizontal-split · Log in · Help
September 10, 2007
Re: Const sucks
Jari-Matti Mäkelä wrote:
> Bill Baxter wrote:
>> Nathan Reed wrote:
>>> Carlos Santander wrote:
>>>> Walter Bright escribió:
>>>>> o  So, we still need a method to declare a constant that will not
>>>>> consume memory. We'll co-opt the future macro syntax for that:
>>>>>
>>>>>     macro x = 3;
>>>>>     macro s = "hello";
>>>> Am I the only one who doesn't like this syntax? I guess it kinda makes
>>>> sense, but I just don't like how it looks.
>>>>
>>> Seems to me like this unnecessarily departs from the macro syntax
>>> introduced at the conference:
>>>
>>> macro foo(e) { e = 3; }
>>>
>>> (On the other hand, in one of them the macro is for an expression while
>>> in the other one it's a sequence of declarations/statements.  So maybe
>>> it is reasonable to have the different syntax.)
>> It's not far off from things used in some functional programming
>> languages, so it doesn't look to bad to me.  The word 'macro' typically
>> implies a direct, maybe even textual, substitution.  It's also a lot
>> like #define, just with an '=' there which I think is an improvement
>> over #define.  '=' for the no-arg macros, '{ }' for the arg-ful macros.
>>   Seems ok to me.
> 
> And let's take another step forward (might scare off some old C farts,
> though, but I like it):
> 
> T sum(T)(T a, T b) = a + b;
> 
> For consistency's sake! :D

How about so?
T sum(T)(T a, T b) a + b;

This contains two things that I've feature requested before: implicit
return of the last expression in a function, and omitting { } for
one-statement functions.
My point being, it's somewhat closer to our current D than your
approach, in that it only requires two backwards-compatible extensions
instead of a whole new syntax :)

--downs
September 10, 2007
Re: Const sucks
Russell Lewis wrote:
> Walter Bright wrote:
>  > (snip)
>> o  static const/invariant means the initializer is evaluated at 
>> compile time. non-static const/invariant means it is evaluated at run 
>> time.
> 
> I'd like to suggest that we use some keyword other than "static."  Yeah, 
> I know that "static" can imply "static analysis" (compile time), but the 
> static modifier on a variable has a well-known meaning from C: it's not 
> exported.  I think that that was a poor design choice in C, but now 
> we're stuck with millions of programmers who expect it.
> 

No one cares (or at least, should care) what that means in C. That's 
ancient history. More important is the other meaning that 'static' in *D 
itself*: the meaning of "non-instance / unique" which is really 
unrelated to "compile-time".

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
September 10, 2007
Re: Const sucks
Janice Caron Wrote:

> On 9/10/07, Alexander Panek <a.panek@brainsware.org> wrote:
> > What exactly is the is the difference between head and tail const?
> 
> Suppose you have a pointer to pointer to pointer to pointer to pointer to int.
> (The length of this chain is irrelevant. I just threw lots in for the
> hell of it).
> 
> Head const would be
> const pointer to pointer to pointer to pointer to pointer to int.
> 
> Tail const would be
> pointer to const pointer to const pointer to const pointer to const
> pointer to const int.
> 
This highlights another source of confusion for me.  I assumed tail const
would be 

pointer to pointer to pointer .... to const int.

What you have described I would call "rest const" using naive intuition.

> Total const would be
> const pointer to const pointer to const pointer to const pointer to
> const pointer to const int.
> 
> i.e. head const and tail const both at the same time.
September 11, 2007
Re: Const sucks
Sean Kelly Wrote:

> Walter Bright wrote:
> > Bruce Adams wrote:
> >>>> o  So, we still need a method to declare a constant that will not
> >>>>  consume memory. We'll co-opt the future macro syntax for that:
> >>>>
> >>>> macro x = 3; macro s = "hello";
> >> I'm not clear why this is even needed. Surely "static const" implies
> >> some level of don't consume any memory by virtue of meaning
> >> "available at compile time". If you need more than that, rather than
> >> trusting the compiler then I second "inline" rather than macro, but
> >> honestly I can't think of an example where this will give you a
> >> worthwhile performance gain (unlike an inline function).
> > 
> > windows.h in all its terrifying glory has 10,000 macro declarations. If 
> > each one occupied 4 bytes of static data, there's 40K of bloat in every 
> > exe.
> 
> That sounds about right.  When we converted const values to enum values 
> in the Tango Win32 headers, app size dropped by roughly 46k.  But there 
> were issues with some of those enum values having the wrong type (-1 set 
> to int instead of uint), which led to a few strange bugs.
> 
> 
> Sean

I seek enlightenmnet for at least two problems with that explanation.

windows.h is a C binding not a D binding.
I'm not clear how one translates to the other yet as I've avoided bi-lingual stuff so far. Presumably the D binding is created using htod.

I thought D followed the you only pay for what you use philosophy.
So if I import my windows.d module I will only pay the cost of the
variables I actually use. My friendly neighbourhoold compiler, being clever, mightl also make an effort to minimise the cost of those too.

While we're on the subject of windows. 40K means nothing. In an embedded system yes. Windows is bloated to the point where 40K in a user application means de nada. (I shudder at the 4Gb games that follow in its wake too). I have know idea where the windows mobile / CE / pocket PC api falls here.

Regards,

Bruce.
September 11, 2007
Re: Const sucks
Bruno Medeiros wrote:
> As Regan asked before, and how would that work for classes? This is a 
> most fundamental issue that has not been mentioned. Without a way to 
> declare tail const/invariant, this design, no matter how simpler or more 
> understandable, is fundamentally *broken*.

What, exactly, is the use case that needs a solution?
September 11, 2007
Re: Const sucks
Walter Bright Wrote:

> Russell Lewis wrote:
> > Walter Bright wrote:
> >> What we are trying to achieve:
> >>
> >> a) utility for functional programming
> >> b) better modularity by self-documenting interfaces better
> >> c) be able to treat reference types as if they were value types (i.e. 
> >> strings should behave to the user like value types, even though they 
> >> are references)
> > 
> > Is there a way to express (for a pointer passed as a function parameter) 
> > "the callee is allowed to modify this object through the pointer, but 
> > the caller ensures that no other code will be modifying it at the same 
> > time"?   Sort of a "you have exclusive write access" modifier?  Is that 
> > a common enough case to even support?
> 
> That's sort of what the often proposed 'unique' type qualifier does. The 
> problem is, there's just no reasonable way to implement it in a 
> *checkable* manner. And if it ain't checkable, it's about as useful as 
> painting a black stripe across your lap when driving instead of wearing 
> a seatbelt.

I see a least two ways of interpreting it at run-time.
Acquire a lock before entering the function (or at least the parts where the value is modified) or in an STM atomic transaction roll-back and try again if the value is modified.
Being run-time only I suspect a function or template and lazy evaluation might suffice.

At compile time you could use it as a hint for 'linting' race conditions out of your code. That is a useful instrumentation to have.
(cyclist wearing a flourescent band as opposed to a black stripe)

These are just suggestions I wouldn't advocate anything without more thought. As I said on the next branch over this is off topic for a discussion about const.

Regards,

Bruce.
September 11, 2007
Re: Const sucks
Regan Heath wrote:
> In general is this correct for a class reference:
> 
> class Baz { int a; }
> const Baz b;  //neither b nor b.a can be changed

Yes.
September 11, 2007
Re: Const sucks
Jb wrote:
> Am I the only one who though it odd that the current documentation spends 
> twice as much time talking about C++ than it does about D?

Half of D programmers come from C++, and the easiest way to learn 
something new is to relate it to something already known.
September 11, 2007
Re: Const is NP Complete
There is no way to find an optimal const solution without trying every possible 
const solution.

(IIRC what "NP Complete" is, might be "NP really stinking hard" I'm thinking 
of <G>)
September 11, 2007
Re: Const sucks
Walter Bright wrote:
> Const, final, invariant, head const, tail const, it's grown into a
> monster. It tries to cover all the bases, but in doing so is simply not
> understandable.

I was going to say that, that D's const sucks, many months ago, but
didn't because I was afraid being regarded as a troll.

Its not that I like const-less languages like Java (in fact, I hate
them), but I think that C++'s const, with all its problems, was the
right answer (for that time). It fixes the problem without putting much
burden onto the programmer.

D's const puts way too much burden onto the programmer, and gives very
little back. Too many different combinations of const, final, invariant,
pointers and references (and the fact that in D you don't immediately
know if a type "T" is a reference of a value, specially while writing
templates, adds to this confusion) with confusing semantics when
combined (with a few special cases and lack of orthogonality).

When the new const was being designed, I told in this list: "Don't try
to fix what ain't broken". What I meant was: Don't try to do a new const
just because you want a better const than C++s. Many people dislike C++s
const, but are unable to point exactly why it is wrong. Most people
doesn't even understand C++'s const, and try to get more from it than it
was actually intended to provide (that is the whole point behind the new
D's invariant).

Sometimes people give use-cases to exemplify (STL's need for a
difference between iterator<> and const_iterator<> is the first thing
that comes to my mind), but then you ask what a language could provide
to fix this, they don't know. This is where you should aim first you laser.

When I first saw D, I was amazed with the possibilities. Now I'm
somewhat scared. Perhaps one of the things that are scaring me is just
like you said: there is a (at least one) monster in the language.

Just my two cents... I have no interest in trolling anyone.
1 2 3 4 5 6 7 8 9
Top | Discussion index | About this forum | D home