Path: utzoo!attcan!uunet!lll-winken!ncis.llnl.gov!helios.ee.lbl.gov!nosc!ucsd!rutgers!rochester!pt.cs.cmu.edu!sei!sei.cmu.edu!firth
From: firth@sei.cmu.edu (Robert Firth)
Newsgroups: comp.lang.misc
Subject: Re: What is B&D? (Re: Bondage and Discipline Languages)
Message-ID: <8282@aw.sei.cmu.edu>
Date: 20 Jan 89 13:35:20 GMT
References: <8784@megaron.arizona.edu>
Sender: netnews@sei.cmu.edu
Reply-To: firth@bd.sei.cmu.edu (Robert Firth)
Organization: Carnegie-Mellon University, SEI, Pgh, Pa
Lines: 62

In article <8784@megaron.arizona.edu> gudeman@arizona.edu (David Gudeman) writes:

>The question is _how_ you do it.  You have to use variant records in
>Pascal and Modula-2 and unchecked_conversion in Ada.  This is because
>the designers of Pascal, Modula-2, and Ada thought that sort of thing
>was dangerous, and wanted to make it inconvenient to do.  The
>inconvenience was supposed to discourage such practices, and the extra
>syntax was supposed to make sure it didn't happen by accident.

The designer of Pascal and Modula-2 can speak for himself.

As the person who designed the unchecked programming features of
Ada, however, please let me state that the above speculation does
not accurately represent my thinking or my intention.

1. There must be a means to convert a value of one type into a value
   of another type without change of representation.  This is necessary,
   for example, if one wishes to write a storage allocator, to compute
   the checksum of a datagram, or to manipulate the components of a
   floating-point number.  These examples are used in my lecture in
   the 'IBF on Ada' course, which stresses the point that any systems
   programming language must include features sometimes called "low level"
   or "machine dependent".

2. As will be evident from the above, this feature is 'dangerous' only
   if misused, as is the case for almost any other programming language
   feature.  However, it does give the designer some problems.  The
   main problem is one of program management and maintenance:

   . the code might not be portable.  non-portable code should be easy
     to find

   . the code will need more careful validation, since one cannot rely
     on the type checking of the compiler.  such code should alert the
     program tester or maintainer to its presence

   . many programming methodologies prescribe some form of automatic
     (or at least cheap) mechanism for detecting and controlling the
     use of non portable or otherwise special code.

   The best solution to this problem is therefore to require any package
   that does these things to import something explicitly: this is a simple
   cue to the maintainer and is susceptible to automatic management (as
   is done by Alsys 'Adaprobe', for example)

   Again, these concerns are stated explicitly in my lecture, in most
   books on Ada (such as Barnes' 'Programming in Ada'), and in the Ada
   Rationale.

3. Given a language with user-defined types, it is necessary to make the
   conversion mechanism as general as possible, so that it can be
   applied to new types as well as old ones.  The solution in Ada is
   to use generics, and the generic actually defined is the simplest
   that will work.

There was no intention to make it costly to use unchecked conversion;
indeed, the cost is no more than that of doing I/O: one line of code
to import the facility and one line of code to do the required generic
instantiation.  This is the essential cost of any type-parameterised
library unit.

Robert Firth