NICE Language Committee: bit-unique
From swissoft.h.provi.de!eiffel@Hannover.POP.DE Sun Oct 15 14:49:56 1995
Date: 14 Oct 1995 15:22:00 +0200
To: bertrand@eiffel.com
Cc: tynor@atlanta.twr.com
Subject: VIP - two more questions
X-Mailer: XP v3.02 R/C4131
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Content-Length: 1768
Status: RO
X-Lines: 49
Dear Bertrand, dear Steve,
here are two minor points I'd like you to comment on:
1) BIT type declarations
A BIT type can be declared as
e : BIT constant
where 'constant' is a constant attribute of the class of type INTEGER
with positive value. Therefore it is allowed that 'constant' is itself
declared as
constant : INTEGER is unique
This is both perfectly legal and perfectly useless. It's impossible to
predict how many bits 'e' will have because the value of a unique
constant cannot be predicted (you only know that it's positive).
Even worse, the declaration is 'non-portable' in the sense that
different compilers will probably produce different values for the
same 'unique' constant. I therefore suggest that VTBT (page 210)
will be extended to exclude this particular case:
VTBT:
A Bit_type declaration is valid if and only if its Constant
is of type INTEGER, has a positive value and is not a constant
attribute of the class declared as unique.
2) Unique constants
I'd like to change the semantics slightly: it should be guaranteed that
if a class introduces unique constants c1, ..., cn - in that order -
then their values v1, ..., vn are consecutive. Currently this is
only true for unique constants introduced in the same feature
declaration section.
The reason I'm asking for this change is that the current rule makes
it impossible to have unique constants with different export status
which have consecutive values. Adopting this change cannot break
existing code and it's trivial to implement it (if it isn't already
implemented).
With best regards,
Michael
SwisSoft, Michael Schweitzer Geismar Landstr. 16 D-37083 Goettingen
Fax : +49 551 770 35 44 email : eiffel@swissoft.h.provi.de
From swissoft.h.provi.de!eiffel@Hannover.POP.DE Thu Oct 19 15:19:57 1995
Date: 19 Oct 1995 22:57:00 +0200
To: bertrand@eiffel.com
Cc: tynor@atlanta.twr.com
Subject: Re: VIP - some questions
X-Mailer: XP v3.02 R/C4131
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Content-Length: 1784
Status: RO
X-Lines: 59
Dear Steve, dear Bertrand,
Steve wrote:
> However, I'm having a hard time
> thinking of an example of where it would be semantically important
> that unique constants with different export status were related by
> value in any way whatsoever (other than being different from one
> another). Can you suggest an example?
Here's an example taken from ETL (slightly modified) :
feature {ANY} -- Public colors
Red : INTEGER is unique
Green : INTEGER is unique
Blue : INTEGER is unique
feature {NONE} -- Secret colors
Black : INTEGER is unique
White : INTEGER is unique
some_feature is
local
a : ARRAY [INTEGER]
do
-- Create array for all possible colors
!!a.make (Red, White)
...
end
True, it's artificial and I must admit that I don't have a better
example. The point is that it's no more difficult to guarantee a
little bit more. Since probably all implementations actually im-
plement the rule I proposed it would be strange to say 'yes, they
have consecutive values but you may not rely on this fact'.
'make_from_array':
I think it should be possible to have both semantics: shared and
non-shared. I feel that I'd probably use the non-shared version
more often than the shared version in order to avoid 'strange
behaviour'. But since it is possible to write
!!x.make_from_array (clone (a))
which has the effect that 'x' and 'a' do not share the representation,
'make_from_array' should have 'shared' semantics. I haven't considered
this possibility earlier - sorry.
With best regards,
Michael
SwisSoft, Michael Schweitzer Geismar Landstr. 16 D-37083 Goettingen
Fax : +49 551 770 35 44 email : eiffel@swissoft.h.provi.de
From rssleo!stynor@uu9.psi.com Wed Oct 18 07:04:16 1995
Subject: Re: VIP - two more questions
To: swissoft.h.provi.de!eiffel@atlanta.twr.com (Michael Schweitzer)
Date: Wed, 18 Oct 1995 08:37:59 -0500 (CDT)
Cc: tynor@twr.com, bertrand@eiffel.com
X-Mailer: ELM [version 2.4 PL22]
Content-Type: text
Content-Length: 1873
Status: RO
X-Lines: 52
>
> Dear Bertrand, dear Steve,
>
> here are two minor points I'd like you to comment on:
>
> 1) BIT type declarations
>
> A BIT type can be declared as
>
> e : BIT constant
>
> where 'constant' is a constant attribute of the class of type INTEGER
> with positive value. Therefore it is allowed that 'constant' is itself
> declared as
>
> constant : INTEGER is unique
>
> This is both perfectly legal and perfectly useless. It's impossible to
> predict how many bits 'e' will have because the value of a unique
> constant cannot be predicted (you only know that it's positive).
> Even worse, the declaration is 'non-portable' in the sense that
> different compilers will probably produce different values for the
> same 'unique' constant. I therefore suggest that VTBT (page 210)
> will be extended to exclude this particular case:
>
> VTBT:
> A Bit_type declaration is valid if and only if its Constant
> is of type INTEGER, has a positive value and is not a constant
> attribute of the class declared as unique.
>
> 2) Unique constants
>
> I'd like to change the semantics slightly: it should be guaranteed that
> if a class introduces unique constants c1, ..., cn - in that order -
> then their values v1, ..., vn are consecutive. Currently this is
> only true for unique constants introduced in the same feature
> declaration section.
>
> The reason I'm asking for this change is that the current rule makes
> it impossible to have unique constants with different export status
> which have consecutive values. Adopting this change cannot break
> existing code and it's trivial to implement it (if it isn't already
> implemented).
>
> With best regards,
> Michael
>
> SwisSoft, Michael Schweitzer Geismar Landstr. 16 D-37083 Goettingen
> Fax : +49 551 770 35 44 email : eiffel@swissoft.h.provi.de
>
>
From rssleo!stynor@uu9.psi.com Wed Oct 18 16:39:33 1995
Date: Wed, 18 Oct 95 17:56 CDT
To: eiffel@swissoft.h.provi.de (Michael Schweitzer)
Cc: bertrand@eiffel.com, tynor@atlanta.twr.com
Subject: VIP - two more questions
References: <5vpGPbszLdB@swissoft.h.provi.de>
Content-Length: 1440
Status: RO
X-Lines: 34
Michael Schweitzer writes:
| VTBT:
| A Bit_type declaration is valid if and only if its Constant
| is of type INTEGER, has a positive value and is not a constant
| attribute of the class declared as unique.
I would support this language modification. Surely, there's no
legitimate case where a programmer wants to specify a BIT size with an
"unknown" size.
| 2) Unique constants
|
| I'd like to change the semantics slightly: it should be guaranteed that
| if a class introduces unique constants c1, ..., cn - in that order -
| then their values v1, ..., vn are consecutive. Currently this is
| only true for unique constants introduced in the same feature
| declaration section.
|
| The reason I'm asking for this change is that the current rule makes
| it impossible to have unique constants with different export status
| which have consecutive values. Adopting this change cannot break
| existing code and it's trivial to implement it (if it isn't already
| implemented).
I'll ponder this. I think our current implementation does in fact
adhere to these additional guarantees. However, I'm having a hard time
thinking of an example of where it would be semantically important
that unique constants with different export status were related by
value in any way whatsoever (other than being different from one
another). Can you suggest an example?
Steve
(Still in Austin, but with more familiar mail software...)
From rssleo!stynor@uu9.psi.com Thu Oct 19 09:06:40 1995
Date: Thu, 19 Oct 95 09:19 CDT
To: swissoft.h.provi.de!eiffel@atlanta.twr.com (Michael Schweitzer)
Cc: tynor@atlanta.twr.com, bertrand@eiffel.com
Subject: Re: VIP - two more questions
References: <5w4GgJpULdB@swissoft.h.provi.de>
Content-Length: 1489
Status: RO
X-Lines: 31
Michael Schweitzer writes:
| thanks for your message. Curiously, you forwarded my own message to me
| without any comments (the one about BIT and unique constants). Anyway,
Sorry - I was struggling with some unfamiliar mail software...
| perhaps it's possible for you to talk with Bertrand about my questions
| at OOPSLA.
We talked a bit about the "three tenors" meeting, but didn't have an
opportunity to talk about anything too technical. Jim McKim and I
talked about ARRAY and a bit about STRING. I'm concerned about the
semantics of "make_from_array". Apparently Betrand wants to make it
share the "area", while you (and I) don't. I think we need to specify
one way or another -- the semantics of the two are vastly different
and the end user really needs to _know_ whether the representation is
shared or not. Perhaps this means that we need two different features
(one which shares and one which doesn't).
But more fundamentally, I'm having difficulty designing an
implementation that will implement the "sharing" case in the presense
of "resizable" arrays. Imagine that I have two arrays; one which was
created with the sharable "make_from_array". I then resize one of them
such that the lower bound changes. What is a reasonable
representation that will not cause the other array to know its area
was resized, realloated, or elements were shifted (any or all of which
may have been a side effect of changing the lower bound of the other
array handle). Bertrand?
Steve
|
