Ramifications of const

[Bent Rasmussen]

The nice thing about D is that it is a multi paradigm language*, but in 
order to remain relevant in the future it has to cater for parallelism - if 
not, I suspect noone will be interested in how fast its programs run on a 
single-core processor when they have massively parallel many-core processors 
with 200 cores or more. Now maybe automatic parallelization is going to be 
sufficient, and maybe local or parameter constness is not a big issue, I 
don't know, but there is also some merrit to the disclipline and clarity of 
constness. In "unpure" functional languages like *ML, there's a ref (If I 
recall correctly) that denote variables and a val for constants, which is 
the norm. Types are inferred and life is good. There is no shame in being 
inspired, as long as it doesn't opens up a major crack of inconsistency in 
the language.

My cent.

Bent

* The same could be said of O'Caml of course, with its objects.


"eao197" <eao197 at intervale.ru> wrote in message 
news:op.ttvbwaemsdcfd2 at eao197nb2.intervale.ru...
> On Wed, 13 Jun 2007 17:30:27 +0400, Don Clugston <dac at nospam.com.au> 
> wrote:
>
>>>> It might be useful to have "does chanege its arguments" as a flag 
>>>> which can quickly be checked during compilation, even if it is 
>>>> deducable from the argument declarations. This may speed things up. 
>>>> But the *more* important flag would be whether the function may change 
>>>> "external" things. This is hard to see without a flag in the signature.
>>>  I think if someone want to have 'pure functions' then it is better to 
>>> look to functional programming languages.
>>
>> And it's one of the good ideas from functional programming languages.
>> Note that any pure function is a candidate for CTFE (if called with 
>> constant arguments), so it's becoming useful for D.
>
> But why trying to transform D to a functional language instead of use one 
> of such languages?
>
> -- 
> Regards,
> Yauheni Akhotnikau