|Desrired Language Features email@example.com (1993-10-02)|
|Re: Desired Language Features firstname.lastname@example.org (1993-10-04)|
|Re: Desired Language Features email@example.com (1993-10-06)|
|Re: Desired Language Features firstname.lastname@example.org (1993-10-19)|
|Re: Desired Language Features email@example.com (1993-10-20)|
|Date:||Wed, 20 Oct 1993 16:11:43 GMT|
: firstname.lastname@example.org (Anthony Naggs)
: <5> Language support for testing input parameters, to replace the normal
: kludges of nested if's or 'do .. while (0)', etc... This is essential
: email@example.com (Rene Dekker) writes:
: Now, this is the more interesting stuff. Your require() and accept() ...
: firstname.lastname@example.org (Doug Merritt)
: [...] I did in fact put serious
: effort into designing a language that used *that* as its central paradigm.
: [...] I eventually decided that, to make parameter checking a "first class
: citizen" in the broadest sense, you'd end up writing your whole program as
: the the parameter-checker, and would have gained nothing at all.
I wonder. I think there can be a useful balance between checks that occur
as "parameter legality checks" and checks that are interwoven with the
rest of the code. Just as there can be a useful balance between what one
considers "syntax errors" vs "semantic errors" at compile time.
So, while it is true that in general, code is code, and moving code from a
main body into a validity checking routine doesn't intrinsically help
things, it still seems to me that factoring out some argument validity
checking is a good idea. This sort of thing exists in some form or
another in existing languages, such as preconditions, postconditions and
assertions in Eiffel, or even in the typechecking routines found in DG's
scripting language used in their mxdb debugger. It can often lead to
clearer code, just as factoring out general error recovery into "catch" or
"protect" clauses instead of intermixing it can lead to clearer code.
Further, as in the DG scripting language example I'm aware of, validity
checking can be associated directly with formal argument types, so that
one can specify the checking once, and then have the checks invoked
automagically by simply declaring the appropriate formal type.
True, this is just syntactic sugar for writing an explicit prolog which
explicitly invokes factored out common code, but it seems like
*wholesome*, *natural* syntactic sugar, more like syntactic honey. I
suppose the question then becomes one of whether one should use
general-purpose factoring capabilities of the language (subroutines,
macros, whatever) to factor out argument validation, or whether the sugar
involved in having a special-purpose capability for this in particular is
worthwhile. Similarly, should error handling use the general-purpose
control-flow capabilities of the language, or should there be a
special-purpose exception mechanim?
I don't think there are definitive answers to such questions.
Return to the
Search the comp.compilers archives again.