This site contains older material on Eiffel. For the main Eiffel page, see http://www.eiffel.com.

NICE Language Committee: vqmc

From neil@aldur.demon.co.uk Sat Feb 26 02:29:30 1994
Subject: Couple of suggestions
To: Bertrand Meyer 
Date: Sat, 26 Feb 1994 09:55:41 +0100 (GMT)
Reply-To: neil@booth.com
X-Mailer: ELM [version 2.4 PL21]
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 3208
Status: RO
X-Lines: 96

I hope the book writing has gone well and that you have time to look at a
couple of language suggestions I have for you.

The first is to do with constant attribute declarations specifically
validity codes VQMC and VQUI.

It seems strange to me that these codes are so restrictive, when such
a constant attribute definition is really only a shorthand for a once
function (as well as giving the compiler a few hints about possible
optimizations). VQMC is essentially a case statement and makes no provision
for manifest arrays.

My suggestion is to do away with these two codes and introduce a new VQMC
which uses the existing mechanism of conformance to check validity. My
draft goes like this:

	A declaration of a feature f declared as type T and introducing
	a manifest constant or unique identifier m is valid if and only
	if it is also valid as a once feature of the following
	structure:

		f: T is
		once
			Result := m
		end; -- f

	When m is 'unique', m shall be treated as an expression of type
	INTEGER whose value is a result of applying the unique
	declaration rule.

This new method generalizes the current system, allowing declarations such
as:

	Size: INTEGER_REF is 32_768

	Error: ANY is "Missing code"

all of which are nice shorthands for the once features you currently
have to declare. It also allows manifest_array declarations which for
some reason are missing from the current definition.

The other reason for the change is to ensure that the semantics of
constant attribute declarations are the same as a once feature. The
reason for this is assertions. When I effect a STRING feature with a
constant attribute under the proposed scheme I know that:

	alpha: STRING is "Hello"

 is a shorthand for the following:

	alpha: STRING is
	once
		Result := "Hello"
	end;

This is useful because sometimes I may want to weaken a pre-condition
at which point I am forced to use the longhand:

	alpha: STRING is
	require else
		true
	once
		Result := "Hello"
	end; -- alpha

Currently the link between once features and constant attributes is only
weakly implied and is easily overlooked. Eiffel/S (for example)
currently uses copy semantics for constant strings.


My second suggestion deals with variable attributes. Currently it is
impossible to alter the assertions around variable attribute declarations,
which is a real pain requiring either an 'interface' class or some fancy
coding to separate the implicit read-only function from the writable
attribute.

To allow assertions on variables I propose the following longhand version
of a variable attribute declaration f: T

		f: T is
			attribute
		end; -- f

Unfortunately this introduces another keyword. (I did think
of just allowing 'f:T is end', but it makes it too easy to accidentally
declare a variable, which didn't strike me as the Eiffel way).

I hope you'll see some merit in these suggestions. I believe they
enhance the consistency and power of the language and remove a couple of
anomalous situations.

Regards
--
Neil Wilson (neil@booth.com)				+44 532 832000 x2242
Computer Development, Booth & Co. Solicitors,	...Arrive without travelling,
PO Box 8, Sovereign House, Leeds, LS1 1HQ, UK	see all without looking...