View mode: basic / threaded / horizontal-split · Log in · Help
June 26, 2007
Re: D const design rationale
Walter Bright skrev:
> OF wrote:
>> Walter Bright Wrote:
>>
>>> BLS wrote:
>>>> I am afraid you will not like this idea, but not afraid enough. <g>
>>>>
>>>> Why not using a single keyword "const_" adding a number 1, 2, 3 to 
>>>> represent :
>>>> invariant, final, readonlyview.
>>>> the higher the number the higher (the stronger) the const.
>>>> means : const_3 == invariant;
>>>> At least a mental help, IMO; somehow borrowed from Modula 2 processes.
>>> You're right, I don't like the idea <g>.
>>
>> I'm curious. Was 'readonly'
> 
> readonly is a synonym for const, so no improvement there.

Read-only isn't synonymous with constant. The etymology of constant is 
from latin constare, which means "to stand firm". The most common 
meaning of 'constant' is 'unchanging'. It also has a well defined 
mathemathical meaning that is quite far from read-only.

It is perfectly valid to talk about read-only access, read-only 
registers, read-only properties, read-only pins, etc without any of them 
being considered constant. In all those cases, D 2.0's current 'const' 
fits perfectly.

Some examples:

A A/D unit on a device may be read by reading a io mapped memory 
register. The register is certainty read-only, but no one would call it 
constant.

The Instruction Counter on may microprocessors can be read but may 
seldom be written to directly. It is certainly read-only, but definitely 
not constant.

You may only be allowed a read-only view of a file. Other processes can 
modify the file so it can't be considered constant (unchanging).

> readonlyview is too long.

Agreed.

/Oskar
June 26, 2007
Re: D const design rationale
Oskar Linde wrote:
> Walter Bright skrev:
>> OF wrote:
>>> Walter Bright Wrote:
>>>
>>>> BLS wrote:
>>>>> I am afraid you will not like this idea, but not afraid enough. <g>
>>>>>
>>>>> Why not using a single keyword "const_" adding a number 1, 2, 3 to 
>>>>> represent :
>>>>> invariant, final, readonlyview.
>>>>> the higher the number the higher (the stronger) the const.
>>>>> means : const_3 == invariant;
>>>>> At least a mental help, IMO; somehow borrowed from Modula 2 processes.
>>>> You're right, I don't like the idea <g>.
>>>
>>> I'm curious. Was 'readonly'
>>
>> readonly is a synonym for const, so no improvement there.
> 
> Read-only isn't synonymous with constant.

Consider ROM, i.e. "Read Only Memory".
June 26, 2007
Re: D const design rationale
On Tue, 26 Jun 2007 11:46:30 -0700, Walter Bright wrote:

> Oskar Linde wrote:
>> Walter Bright skrev:
>>> OF wrote:
>>>> Walter Bright Wrote:
>>>>
>>>>> BLS wrote:
>>>>>> I am afraid you will not like this idea, but not afraid enough. <g>
>>>>>>
>>>>>> Why not using a single keyword "const_" adding a number 1, 2, 3 to 
>>>>>> represent :
>>>>>> invariant, final, readonlyview.
>>>>>> the higher the number the higher (the stronger) the const.
>>>>>> means : const_3 == invariant;
>>>>>> At least a mental help, IMO; somehow borrowed from Modula 2 processes.
>>>>> You're right, I don't like the idea <g>.
>>>>
>>>> I'm curious. Was 'readonly'
>>>
>>> readonly is a synonym for const, so no improvement there.
>> 
>> Read-only isn't synonymous with constant.
> 
> Consider ROM, i.e. "Read Only Memory".

Which is obviously misnamed. It should be more like Write-Once memory <G>
If it were truely *always* read-only then nothing would ever be written to
it, thus it is not constant as its state has changed at least once.


-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
June 26, 2007
Re: D const design rationale
Derek Parnell wrote:
> Which is obviously misnamed. It should be more like Write-Once memory <G>
> If it were truely *always* read-only then nothing would ever be written to
> it, thus it is not constant as its state has changed at least once.

Technically, ROMs are actually manufactured that way, there never was a 
write to them.

You're thinking of PROMs ("programmable read only memory"), and EPROMs 
("Erasable Programmable Read Only Memory") and EEPROMs ("Electrically 
Erasable ...").
June 26, 2007
Re: D const design rationale
Walter Bright skrev:
> Oskar Linde wrote:
>> Walter Bright skrev:
>>> OF wrote:
>>>> Walter Bright Wrote:
>>>>
>>>>> BLS wrote:
>>>>>> I am afraid you will not like this idea, but not afraid enough. <g>
>>>>>>
>>>>>> Why not using a single keyword "const_" adding a number 1, 2, 3 to 
>>>>>> represent :
>>>>>> invariant, final, readonlyview.
>>>>>> the higher the number the higher (the stronger) the const.
>>>>>> means : const_3 == invariant;
>>>>>> At least a mental help, IMO; somehow borrowed from Modula 2 
>>>>>> processes.
>>>>> You're right, I don't like the idea <g>.
>>>>
>>>> I'm curious. Was 'readonly'
>>>
>>> readonly is a synonym for const, so no improvement there.
>>
>> Read-only isn't synonymous with constant.
> 
> Consider ROM, i.e. "Read Only Memory".

Yes, there are cases where the meaning of read-only and constant 
overlap. You could even argue that the overlapping meanings are large 
enough to make the words synonymous, but that is irrelevant to the 
discussion.

What is relevant is which word does best describe the properties the 
D2.0 'const' has? IMHO, read-only wins by a large margin. Read-only 
describes everything 'const' is, while the generally accepted meaning of 
constant is a poor fit.

This has been irking me for quite some time, and I believe it is the 
reason the final-const-invariant thing feels so awkward (to me). The 
design has been carefully considered and is quite likely the best 
possible given the requirements. However, the use of "const" to mean 
read-only sticks out like a turd in a punch bowl (pardon the expression).

People argue that of the different meanings of "const" in C++ (that you 
like to point out), the non-constant meaning is the worst and most 
confusing. Still, the only meaning for "const" that D inherit from C++ 
is that one.

<parenthesis>
I've never heard anyone complain about "const" as a "storage class", 
like in:

const double e = 2.7182818284590452354;
const double pi = 3.14159265358979323846;
<parenthesis>

I believe *many* people would be *much* less confused and have a *much* 
easier time acceping and grasping the D const behavior if better 
keywords were used. "What? Const means it can change???"

So I plead: Please reconsider the keywords. The implications of not 
doing that are severe. The publics acceptance of D is at stake.

What if you could say, "Look: We fixed C++'s const. Const now really 
means constant -- not could-actually-change and you will be damned if 
you assume anything else". This is a hypothetical scenario of changing 
final-const-invariant -> final-readonly-const. There could possibly be 
even better choices of keywords.

Apologies for being so harsh (and hyperbolic), but I feel this is (as 
strange as it may sound) a quite important issue.

/Oskar
June 26, 2007
Re: D const design rationale
Bill Baxter wrote:
> Walter Bright wrote:
>> No, FORTRAN does not have array operations out of the box. It has no 
>> more mathematical operations than C does (in fact, it has fewer).
> 
> Hmm, maybe I'm thinking of Fortran 90 then.
> This doc seems to be saying that F90 has array ops
> http://www.ibiblio.org/pub/languages/fortran/ch1-2.html
> "Fortran 90 supports an array notation that allows operations on array 
> sections, and using vector indices."

I quit using FORTRAN before F90 <g>.

> And from that page, Fortran has an efficient built-in exponentiation 
> operator, which sounds to me like one more operation than C has.  But I 
> guess C has all the += type things, which I don't think Fortran has.  So 
> I guess you could argue that C has more than F77 at least.

I'd forgotten about the exponentiation operator.

> That's all true but at the same time Java on embedded systems is pretty 
> popular from what I understand, and Google is a big user of Python.

Google extensively uses C++. A lot of people use Python, and are forced 
to mix in C++ to speed up the slow parts. It would be much simpler for 
them if they could use the same language for both.
June 26, 2007
Re: D const design rationale
Reply to Bill,

> I guess we're just quibbling over the definition of the "often" in
> your statement "Optimization often makes the difference between a
> successful project and a failure."

That reminds me of a thought I had a while ago: compilers are interesting 
beasts because they are a program that deals with programs. Not only that, 
but a compiler must be written to handle anything that is allowable, not 
just stuff that is a good idea (as opposed to the compiler that should be 
written only with code that is a good idea). This starts looking like the 
point that if a compiler is going to be used by some market where a few people 
need something, then the compiler needs it even if most people in the market 
don't need it.

I'm not sure if this is even remarkable but I though it was kind of interesting.
June 26, 2007
Re: D const design rationale
BCS wrote:
> Reply to Bill,
> 
>> I guess we're just quibbling over the definition of the "often" in
>> your statement "Optimization often makes the difference between a
>> successful project and a failure."
> 
> That reminds me of a thought I had a while ago: compilers are 
> interesting beasts because they are a program that deals with programs. 
> Not only that, but a compiler must be written to handle anything that is 
> allowable, not just stuff that is a good idea (as opposed to the 
> compiler that should be written only with code that is a good idea). 
> This starts looking like the point that if a compiler is going to be 
> used by some market where a few people need something, then the compiler 
> needs it even if most people in the market don't need it.
> 
> I'm not sure if this is even remarkable but I though it was kind of 
> interesting.

It's the same thing with library API design, too.  A good library needs 
to consider all possible use cases, even the ones that are wacky. 
Probably same thing with all code. Haven't you ever been at that point 
where you find yourself writing way too much code to handle some case 
that probably won't even come up?  It's just a result of not knowing 
what your input will be in advance.

--bb
June 26, 2007
Re: D const design rationale
Walter Bright wrote:
> ... A lot of people use Python, and are forced
> to mix in C++ to speed up the slow parts. It would be much simpler for
> them if they could use the same language for both.

I'll have to disagree on this.  I used Python for my third year
comp.sci. group project, and it made things a hell of a lot easier.
Most of the code was dealing with the GUI, with only a few math-heavy
parts written by myself.

Using Python for the mathy parts made them so much easier to debug it
wasn't funny, and I've never seen anything that could touch Python for
writing sane GUI code.

In the end, I had to convert some of the slower code from Python to C,
but that was basically a trivial exercise.  Pyrex allows you to write
"Python-like" code that compiles directly to C that makes writing the
native module wrapping C code a non-issue.

If I'd used just C++, the GUI coding would have driven me completely
insane.  If I'd been restricted to an interpreted language, our app
would have been slow as molasses.  By using Python, we got the best of
both worlds :)

In a wacky kind of way, one of the reasons I chose Python was *because*
it could be easily optimised.  True, it had to be done in a different
language, but there was almost no effort required to do so, so I never
had to fear hitting a performance ceiling.

	-- Daniel
June 26, 2007
Re: D const design rationale
Daniel Keep wrote:
> 
> Walter Bright wrote:
>> ... A lot of people use Python, and are forced
>> to mix in C++ to speed up the slow parts. It would be much simpler for
>> them if they could use the same language for both.
> 
> I'll have to disagree on this.  I used Python for my third year
> comp.sci. group project, and it made things a hell of a lot easier.
> Most of the code was dealing with the GUI, with only a few math-heavy
> parts written by myself.
> 
> Using Python for the mathy parts made them so much easier to debug it
> wasn't funny, and I've never seen anything that could touch Python for
> writing sane GUI code.
> 
> In the end, I had to convert some of the slower code from Python to C,
> but that was basically a trivial exercise.  Pyrex allows you to write
> "Python-like" code that compiles directly to C that makes writing the
> native module wrapping C code a non-issue.
> 
> If I'd used just C++, the GUI coding would have driven me completely
> insane.  If I'd been restricted to an interpreted language, our app
> would have been slow as molasses.  By using Python, we got the best of
> both worlds :)

Everyone knows that C++ sucks for writing GUIs, I hope to do much better 
with D.

> 
> In a wacky kind of way, one of the reasons I chose Python was *because*
> it could be easily optimised.  True, it had to be done in a different
> language, but there was almost no effort required to do so, so I never
> had to fear hitting a performance ceiling.

But you did hit a performance ceiling. You had to convert the 
bottlenecks to C. Wouldn't it be nice not to have to do that? <g>
7 8 9 10 11 12 13
Top | Discussion index | About this forum | D home