Re: language design implications for variant records in a pascal-like language

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>
Wed, 29 Dec 2010 10:30:44 +0100

          From comp.compilers

Related articles
[5 earlier articles]
Re: language design implications for variant records in a pascal-like DrDiettrich1@aol.com (Hans-Peter Diettrich) (2010-12-25)
Re: language design implications for variant records in a pascal-like gene.ressler@gmail.com (Gene) (2010-12-27)
Re: language design implications for variant records in a pascal-like bobduff@shell01.TheWorld.com (Robert A Duff) (2010-12-27)
Re: language design implications for variant records in a pascal-like noitalmost@cox.net (noitalmost) (2010-12-27)
Re: language design implications for variant records in a pascal-like cr88192@hotmail.com (BGB) (2010-12-27)
Re: language design implications for variant records in a pascal-like bobduff@shell01.TheWorld.com (Robert A Duff) (2010-12-28)
Re: language design implications for variant records in a pascal-like mailbox@dmitry-kazakov.de (Dmitry A. Kazakov) (2010-12-29)
Re: language design implications for variant records in a pascal-like bc@freeuk.com (BartC) (2010-12-29)
Re: language design implications for variant records in a pascal-like DrDiettrich1@aol.com (Hans-Peter Diettrich) (2010-12-29)
Re: language design implications for variant records in a pascal-like marcov@turtle.stack.nl (Marco van de Voort) (2010-12-30)
Re: language design implications for variant records in a pascal-like gneuner2@comcast.net (George Neuner) (2010-12-30)
Re: language design implications for variant records in a pascal-like gneuner2@comcast.net (George Neuner) (2010-12-30)
Re: language design implications for variant records in a pascal-like gneuner2@comcast.net (George Neuner) (2010-12-30)
[44 later articles]
| List of all articles for this month |

From: "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>
Newsgroups: comp.compilers
Date: Wed, 29 Dec 2010 10:30:44 +0100
Organization: cbb software GmbH
References: 10-12-040 10-12-045 10-12-046 10-12-051
Keywords: storage, design
Posted-Date: 29 Dec 2010 09:34:03 EST

On Mon, 27 Dec 2010 14:03:49 -0500, Robert A Duff wrote:


>>...Boolean lattice can be extended to tri-valued lattice,
>>...[etc]
>
> But not without breaking programs that use ifTrue:
> and whileTrue: and so forth (which is approximately
> 100% of them). ;-)


Right, the logical inference becomes different. You can execute


      while Condition loop
              ...
      end loop;


at the level of certain truth, and this would mean the third value
Uncertain treated as False. Or you can execute it gullibly continuing when
Uncertain.


BTW, specifically to Ada, it would not be a problem for if- or
while-statement, because Condition there has the type Boolean, not
Boolean'Class, so it cannot become Uncertain anyway. At best when doing
this:


      while Boolean (Get_User_Input) loop
              ...
      end loop;


here function Get_User_Input returns Boolean'Class, which might be
Tri_State_Logical. Then the required explicit conversion to Boolean would
raise Constraint_Error for Uncertain. And the programmer who writes the
program in the terms of the class rather the type Boolean must be prepared
to deal with any instance from the class. Otherwise, it is broken per
design.


But this issue is rather to be addressed to the illusions about
substitutability of types. Nothing is absolutely substitutable, not only
Tri_State_Logical for Boolean. Any extension or specialization potentially
breaks something. This sad fact cannot serve an argument against derivation
of new types from old ones.


--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.