Re: Desired Language Features

doug@netcom.com (Doug Merritt)
Tue, 19 Oct 1993 04:25:22 GMT

          From comp.compilers

Related articles
Desrired Language Features amn@ubik.demon.co.uk (1993-10-02)
Re: Desired Language Features dekker@dutiag.twi.tudelft.nl (1993-10-04)
Re: Desired Language Features henry@zoo.toronto.edu (1993-10-06)
Re: Desired Language Features doug@netcom.com (1993-10-19)
Re: Desired Language Features throop@aurw44.aur.alcatel.com (1993-10-20)
| List of all articles for this month |

Newsgroups: comp.compilers
From: doug@netcom.com (Doug Merritt)
Keywords: design, errors
Organization: Netcom Online Communications Services
References: 93-10-021 93-10-024
Date: Tue, 19 Oct 1993 04:25:22 GMT

amn@ubik.demon.co.uk (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


dekker@dutiag.twi.tudelft.nl (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
pattern.


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
--
Doug Merritt doug@netcom.com
--


Post a followup to this message

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