March 08, 2005
In article <d0ip9t$lmv$1@digitaldaemon.com>, Walter says...

>Good. To put it another way, anything labeled as 'const' could be burned into ROM without changing the meaning of the program. (This is also implies that const data must have initializers that can be evaluated at compile time.)
>
>> If you could provide a D mechanism for making scalar and vector data
>"appear" to
>> be fully constant (as in the storage class) to third-parties (think return
>> values), then we'd have the read-only enforcement so many of us are crying
>out
>> for. That could easily become a major advantage for D over other
>languages.
>>
>> In addition, the utility of a true storage-constant attribute (one that is
>also
>> supported via call-by-reference ~ inout obviously does not work) then that
>would
>> open up additional avenues for D.
>
>Fundamentally connected with this is the problem of aliased function parameters. Get it wrong, as C and C++ do, and you cannot build an optimizer that is competitive with FORTRAN optimizers.


Also agreed, 100%. It's just that we want that 'right' functionality,and preferably sooner rather than later :~)


March 08, 2005
"Kris" <Kris_member@pathlink.com> wrote in message news:d0ir8c$nlr$1@digitaldaemon.com...
> >Fundamentally connected with this is the problem of aliased function parameters. Get it wrong, as C and C++ do, and you cannot build an
optimizer
> >that is competitive with FORTRAN optimizers.
>
>
> Also agreed, 100%. It's just that we want that 'right' functionality,and preferably sooner rather than later :~)

Realistically, it's a 2.0 issue. I've promised Norbert I'd go through the array semantics with him for that.


March 08, 2005
OK. Appreciate you being up-front and candid about it.


Walter wrote:
> "Kris" <Kris_member@pathlink.com> wrote in message
> news:d0ir8c$nlr$1@digitaldaemon.com...
> 
>>>Fundamentally connected with this is the problem of aliased function
>>>parameters. Get it wrong, as C and C++ do, and you cannot build an
> 
> optimizer
> 
>>>that is competitive with FORTRAN optimizers.
>>
>>
>>Also agreed, 100%. It's just that we want that 'right' functionality,and
>>preferably sooner rather than later :~)
> 
> 
> Realistically, it's a 2.0 issue. I've promised Norbert I'd go through the
> array semantics with him for that.
> 
> 
March 08, 2005
Agreed, Kris.

A good, thought-provoking post.  Everybody should be considering these things.

Thanks,

- JJR

Kris wrote:
> Amen. 
> 
> It's exactly this kind of thing that has so often worn me down to the bone [and
> why my sometimes inappropriate commentary joins the party; for which I do
> apologize] 
> 
> I believe we should understand that D belongs to all of us. Everyone who has
> contributed in one form or another (through adopted ideas, through NG posts,
> through being a D evangelist, through writing supporting libraries, through
> examples, tutorials, and wiki's, through providing supporting web-services such
> as dsource.org and this NG, etc. etc.) *own* a piece of D. I don't think Walter
> could, or would, claim that D is his own thing at this time (in fact, our
> combined little bits of ownership probably amount to something rather
> significant). 
> 
> As such, we kinda' owe it to ourselves to ensure the development of "our"
> language is 'managed' more effectively. After all, D requires a grass-roots
> approach to language adoption (in contrast to the marketing and financial clout
> of a .NET approach); it's people like us who will ultimately push for adoption
> of D within our own spheres of influence.
> 
> 
> I'm noting this for three reasons: 
> 
> 1) you should realize that D is /your/ language ~ not someone else's. It will
> become mainstream not when D matures per se, but when each and all of us urge
> our development groups to consider adopting it. Walter has never spelt this out,
> but he's fully dependent upon each of us for the success of D (unless it's
> perhaps just a jolly wheeze instead). 
> 
> When I see people talking about "Walter's language" it suggests either "Walter
> is a shallow and hollow individual" or "I can't personally accept the
> responsibility for making this better". There's probably plenty of room between,
> but you get the drift? We, each of us, is expected to do the hard work of local
> adoption. So we should get used to the ownership idea.
> 
> 2) we deserve, and should expect more in terms of a transparent development
> process. Right now, it's almost completely opaque (save for the rare and
> occasional glimmer of a proactive request, such as the recent "$ or length?"
> topic initiated by Walter himself). I mean, at this point, a rational and
> constructive discourse over how to improve D in specific areas is the exception,
> rather than the norm. Instead, what's attached below typifies the reaction. This
> is surely a bad sign, and it is something that (IMO) Walter should reflect
> heavily upon. 
> 
> 3) Historically, there's been a lot of talk with very little action. For
> example, people have often lamented over the weaknesses of the D libraries.
> However, how many of you are willing to do something about changing that? We've
> got to take some responsibility ourselves to change things; be a bit more
> constructive and a lot more cooperative. Talk is cheap. There are perhaps one or
> two dozen people who are /really/ trying to contribute to D in this particular
> manner ... they can always use a bit of help! If you want good libraries for D,
> write them yourselves, or better, get some momentum going with others via the
> Ares project (over at dsource).
> 
> Something to think about.
> 
> - Kris
> 
> 
> (p.s. please forgive me for hijacking your post, Matthew; but for a moment there
> you sounded just like me)
> 
March 08, 2005
Walter,

Actually, I think you'll find that DCE invented IDL, and Microsoft just
ported it. Actually IDL originally targetted C, so I guess
the reference issue had no impact on its design. If you look at earliest
implementations of IUnknown, you'll notice that QueryInterface
(along with a lot of similar interfaces) uses a REFIID, which in C++ is
defined as an IID&, in C and IID*, so the issues really predate
COM even - blame DCE RPC for these ones.

Furthermore, IDL as originally conceived was designed to allow writing
proxy/stub implementations for Remote Procedure Calls, and
allows much more flexibility that are glossed over there - such as
implementing custom-marshalled types, etc.

Just to clear things up.

Again, with const I absolutely disagree - placing a const on a parameter
tells the compiler that the function called cannot modify the parameter, so
its free to make all sort of optimisations not otherwise possible
(especially with pointer parameters). Also, it can catch
many programmer errors at compile times (saving much more tedious runtime
error-hunting later). Finally, I believe it makes the contract
that much more explicit. In C++, the main undermining factor comes from
compatibility with pre-existing code (the desire for most correct C code to
be correct C++ code) - often a severe problem in C++. In particular, many
libraries/API's do not declare there parameters correctly, hence the need
for const_cast, these issues shouldn't really apply to D, where they can be
encapsulated at the interface, so I cannot see a good reason not to include
it.

As for the for_each problem, <algorithm> provides a nice solution called, wait for it, for_each. Given a container..

    vector<int> v;

    // ...

    for_each(v.begin(); v.end(), functor);

Doesn't look all that complex to me...

Rob


March 09, 2005
Note: in the following, I am referring to const as a type modifier, as distinct from const as a storage class. I find const as a storage class to be useful and desirable.


"Rob Grainger" <nospam@nospam.com> wrote in message news:d0le44$m64$1@digitaldaemon.com...
> Actually, I think you'll find that DCE invented IDL, and Microsoft just
> ported it. Actually IDL originally targetted C, so I guess
> the reference issue had no impact on its design.

But the issue of what's in, out, and inout did impact, and it's still why people need to use it.

> If you look at earliest
> implementations of IUnknown, you'll notice that QueryInterface
> (along with a lot of similar interfaces) uses a REFIID, which in C++ is
> defined as an IID&, in C and IID*, so the issues really predate
> COM even - blame DCE RPC for these ones.
>
> Furthermore, IDL as originally conceived was designed to allow writing
> proxy/stub implementations for Remote Procedure Calls, and
> allows much more flexibility that are glossed over there - such as
> implementing custom-marshalled types, etc.
>
> Just to clear things up.

Thanks.

> Again, with const I absolutely disagree - placing a const on a parameter tells the compiler that the function called cannot modify the parameter,
so
> its free to make all sort of optimisations not otherwise possible (especially with pointer parameters).

No, it can't. The optimizer can't make any use of const, because legal, standard conforming C++ code can modify const values. Similarly, multithreaded code cannot assume that const references remain constant. Does this happen in practice? It sure does, as I found out when adjusting the optimizer to take advantage of const. Lots of code breaks.

> Also, it can catch
> many programmer errors at compile times (saving much more tedious runtime
> error-hunting later).

That's the idea, but do such errors happen very often? Not in my experience, using it for years never found an actual bug (though it found a lot of const-correctness issues, none of them were actual bugs). The additional failure of const to provide any useful optimization opportunities kinda sealed its fate. Note that Matthew strongly disagrees with me on these points.

> Finally, I believe it makes the contract
> that much more explicit. In C++, the main undermining factor comes from
> compatibility with pre-existing code (the desire for most correct C code
to
> be correct C++ code) - often a severe problem in C++. In particular, many libraries/API's do not declare there parameters correctly, hence the need for const_cast, these issues shouldn't really apply to D, where they can
be
> encapsulated at the interface, so I cannot see a good reason not to
include
> it.

I've seen a lot of C++ code, and when the author of it has made the effort to make it const-correct, it's pretty loaded up with const keywords. I believe it adds a lot of visual complexity, without commensurate benefits. If const came with guarantees that the data would not be modified (unlike C++), then it might have value.

> As for the for_each problem, <algorithm> provides a nice solution called, wait for it, for_each. Given a container..
>
>     vector<int> v;
>
>     // ...
>
>     for_each(v.begin(); v.end(), functor);
>
> Doesn't look all that complex to me...

Try the following D code with C++'s std::for_each:

    foreach (int value; collection)
    {
        if (value == 6)
            return 3;
    }

Eric Niebler has gotten much further with for_each in C++ using complex macros, but I haven't studied his work.


March 09, 2005
"Walter" <newshound@digitalmars.com> skrev i en meddelelse news:d0lha7$p50$1@digitaldaemon.com...
> I've seen a lot of C++ code, and when the author of it has made the effort to make it const-correct, it's pretty loaded up with const keywords. I believe it adds a lot of visual complexity, without commensurate benefits. If const came with guarantees that the data would not be modified (unlike C++), then it might have value.

I'm also in the camp missing the 'const'. I easily see your point about it having no value to the compiler/optimizer, but that is not the only point. In this article:

    http://www.developerdotstar.com/mag/articles/reeves_design_main.html

the author argues that the code is the design, and coding is a design activity. He also argues that:

    "What we really need is more expressive programming languages.
    This is what led to my statement about C++ being a major advance
    in software design art. C++ is a more expressive programming
    language, which makes it a better software design tool."

'const' is one of those features that makes it a more expressive language and a better software design tool. Your point about it being useless to the compiler doesn't really matter in this respect.

Regards,
Martin


>
>> As for the for_each problem, <algorithm> provides a nice solution called, wait for it, for_each. Given a container..
>>
>>     vector<int> v;
>>
>>     // ...
>>
>>     for_each(v.begin(); v.end(), functor);
>>
>> Doesn't look all that complex to me...
>
> Try the following D code with C++'s std::for_each:
>
>    foreach (int value; collection)
>    {
>        if (value == 6)
>            return 3;
>    }
>
> Eric Niebler has gotten much further with for_each in C++ using complex macros, but I haven't studied his work.
>
> 


March 09, 2005
Walter wrote:

>>The only place for "const" seems to be protecting read-only attribute ?
> 
> I like "const" as meaning it really is constant. Read-only is a side effect
> of that. C++ const stuff may be read only, but it isn't constant. Other
> threads, and other references to the same data can change it at any time,
> which is why the C++ const is overrated.

This sounds a bit to me like how "typedef" and "alias" work, in D ?


Which means that if "const" ever surfaced in D, which seems to
be unlikely since it is so easy to cast away and be a Bad Boy,
it would probably be called "readonly" instead - to reflect use ?

Since "const" are reserved in D for things that are... well...
constant, and "typedef" are reserved for stuff that... errr...
actually define new types. Then "readonly" sounds approriate.

Or perhaps the write-once declaration of "final", that Java has.
(works a little like a CD-rom disc burner, doesn't it, where you
can write stuff to the disc only once - and then it's "constant")


I like D's const. Whether "readonly" is needed, remains to be seen...
(but it would probably have to be enforced with massive military force,
for instance like string literals on GCC that are placed in R/O memory?)

--anders
March 09, 2005
>> > Walter wrote:
>> >> As a *language*, what does C++ have over D?
>> >> Implicit function template instantiation. It's hard to find much else.
>>
>>     const
>
>Discussed in great depth elsewhere!
>
>>     references
>
>See my response to Anders on that.
>
>>     bool
>
>I'm not seeing it, Matthew!

Hmm... Using enum you can write your own bool.

>
>>     namespaces
>
>I really see nothing in C++ namespaces that has anything over D modules. Namespaces are a failed attempt to add module like semantics to C++, and I say failed because several experts told me that exported templates were needed in order to provide "coding hygiene", i.e. prevent the names in one source file from stepping on those in another. I found that interesting because that was exactly the problem that namespace was supposed to solve.

The header + translation unit system is crap, right. But namespaces aren't.


>>     compile-time testing (none of that hideous runtime generic comparison
>filth)
>
>?? D has static asserts.
>
>>     TMP
>
>??

Template-Meta-Programming. I never tried to do that in D, so I can't say anything usefull here.

>
>>     macro pre-processor

Matthew, do you realy want a C-like preprocessor? If D should get macros it should get powerfull Lisp-like macros!

>You can use the C preprocessor with D, if you want.
>
>>     'using'
>
>Replaced with 'alias'.
>
>>     operators that look like operators
>
>Sorry, but that's a bug in C++.

Sorry, I don't get it? Which operator doesn't look like an operator? "in"? D has almost the same operators as C++. Or are you talking about these strange names like "opAdd"?

>
>>     compilers that warn
>
>Thrashed that one to death <g>.
>
>>     proper cast operators,
>
>I know there's a thread on that, but I haven't gotten to it yet.

cast(Foo)bar looks cool at first, but you can't do something that looks like a cast on your own (e.g boost::lexical_cast looks like the other C++-cast). And the C++-Casts are more powefull. If you defenitly know that an object has the type you want to cast to, you can use a static cast, if you aren't sure, you can use a dynamic cast. In D you allways have to use a dynamic cast, which is far more expensive.


>
>> and the ability to fill the gaps in the spectrum with user defined types
>
>?? D has full UDT support.

D isn't very good at types with value semantics, while being good at types with reference semantics.

>
>>     support for shims (implicit template instantiation coupled with
>ability to manipulate names in global/specific
>> namespaces)
>
>Agreed.
>
>>     lack of GC
>
>Lack of GC is a feature? How? One can program D just like you can in C, strictly using malloc/free. Nary a GC object. D does not require GC.
>
>>     ability to produce extremely small applications (i.e. supports
>extremely low coupling, and allows one to dispense
>> with C/C++ Runtime Library)
>
>Phobos is a part of D, just like the C/C++ runtime library is a part of C/C++. In both languages, you can stub out what you don't want, or provide some minimal alternative. Phobos is certainly not a VM that must be dragged around for the trivialest apps.
>
>
>>     etc. etc. etc.
>
>? ? ?
>
>> (For the record, I'm writing std.openrj right now, in 100% D, and enjoying
>it for the most part. But it is *not* > unalloyed tra-la-la-ing in wonderland ...)
>
>I predict that once you write enough D code, you'll discover that C++ is the incomplete language <g>. Try supporting UTF in the C++ version of openrj.
>
>


March 09, 2005
[Chopped down from its original length]

In article <d0mrip$2656$1@digitaldaemon.com>, Matthias Becker says...
>
>>> > Walter wrote:
>>> >> As a *language*, what does C++ have over D?
>>> >> Implicit function template instantiation. It's hard to find much else.
>>
>>>     compilers that warn
>>
>>Thrashed that one to death <g>.
>>
>>>     proper cast operators,
>>
>>I know there's a thread on that, but I haven't gotten to it yet.
>
>cast(Foo)bar looks cool at first, but you can't do something that looks like a cast on your own (e.g boost::lexical_cast looks like the other C++-cast). And the C++-Casts are more powefull. If you defenitly know that an object has the type you want to cast to, you can use a static cast, if you aren't sure, you can use a dynamic cast. In D you allways have to use a dynamic cast, which is far more expensive.

Sorry to butt-into the discussion, but I have some insight to share with respect D's casting mechanism.

First off, one can accomplish a static-cast in D, although it looks a bit hackish:

> myvar = cast(MyVar)cast(void*)myothervar;

I assume that casting through "void*" is waved away by the compiler into something more succinct, so I wouldn't expect this to be any less efficient than C.

Secondly, one can also write their own cast routine from scratch, as I have done already:

http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/18665

.. which is a dynamic cast based on class/interface name.  D's built-in casting mechanism is based on typeinfo reference.

By this you get "dyn_cast!(Type)(arg)" which IMO, is no less a cast than
"boost::lexical_cast<Type>(arg)" since its still relying on a template.

The ABI documentation is out of date, but all one needs to do is poke around in phobos/object.d.  I would suspect that the future will bring an ABI that can be used to code any manner of runtime-type mechanisms.

So with respect to cast(), D is surely on the same footing as C/C++, if not on
higher ground.

- EricAnderton at yahoo