|Desrired Language Features firstname.lastname@example.org (1993-10-02)|
|Re: Desired Language Features email@example.com (1993-10-04)|
|Re: Desired Language Features firstname.lastname@example.org (1993-10-06)|
|Re: Desired Language Features email@example.com (1993-10-19)|
|Re: Desired Language Features firstname.lastname@example.org (1993-10-20)|
|From:||email@example.com (Doug Merritt)|
|Organization:||Netcom Online Communications Services|
|Date:||Tue, 19 Oct 1993 04:25:22 GMT|
firstname.lastname@example.org (Anthony Naggs) writes:
><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() ...
I came in on this late, it would seem, but I'll comment that I was so
intrigued by this idea some years back that I did in fact put serious
effort into designing a language that used *that* as its central paradigm.
I was eventually discouraged, because if it's going to be the central
paradigm, you first want pattern matching, like (for purpose of
discussion) adding to Lisp the insistence that some function's parameter
S-expression match something like (* . (*.*)), to make sure that all of
car, cdr, cadr, and cddr will work just spiffy when called internal to
that function, that on entry checked the parameter against that guard
However, this quickly leads to complications...what about circular or
otherwise recursive structures? So I tried adding tags to the
specification pattern guards.
But this is roughly regular-expression level...you then start to want more
powerful grammatical constructs...LALR(1)-parameter-checking...etc.
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. It's
like Sutherland's "great wheel of incarnation". All the smarts ooze out of
the primary and into the secondary, and then the cycle begins anew.
On the other hand, despite that experience, I still like the general idea.
I think I just took the wrong fork in the road. A better approach might be
to pick the language paradigm first, and then allow parameter guarding to
use that paradigm, whatever it is.
Therefore everything I just said may be considered a digression. But I
hope it's a mildly interesting one. :-)
Doug Merritt firstname.lastname@example.org
Return to the
Search the comp.compilers archives again.