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

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

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

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

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

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.

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.

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

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

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>