Robby Findler wrote:
> If you think you can accomplish such a thing for a non-trivial subset
> of the language, please do submit it to the editors.
Could you unpack that a little bit?
I'm not sure if you are trying to say that the math is too hard
or the required labor too great.
My capacity to crank lots of material of the sort I'm describing
exists -- but it isn't something I can do very quickly. So,
if you are just throwing up the usual "open source" dismissal
of "code talks....", I don't think we are communicating very
effectively.
The points I was trying to point at, so to speak, include:
1. Denotational semantics, its "least fixpoint" approach,
is the best account we have of meaning, in programming
languages. Yet, it is difficult to teach that mathematical
theory armed only with a "New Math"-ish, and usually
poorly founded account of set theory. A little bit of
exposure to so-called constructivist or intuitionist approach
to mathematical foundations seems to me to go a long way
in easing the path, especially when these studies are motivated
by contemplation of paradoxes and their resolutions most
often identified with Russel, Turing, Goedel, etc.
2. A good account of program (and programming language)
meaning is vital to comprehending the design space of programming
languages. A lot can be accomplished (e.g., the C programming
language) taking a naively operational, pragmatic approach to
language design -- regarding the design space as what one can figure
out how to implement, mediated by cultural wisdom about "what
works in practice". Yet, the mathematical exposure of the design
space is quite illuminating.
3. The operational and denotational approaches to programming
language design seem to converge, in interesting ways, when
contemplating the "lisp tradition" (which we need never *perfectly*
define). In particular, lisp systems are traditionally systems in
which the programmer, faced with a task to accomplish, is competent
to, permitted to, and effective when hacking at all levels of the
system. Write macros to extend the language, sure -- but if it makes
sense, don't hesitate to drop down and change the language at the
interpreter level. That tradition implies that, in some vague sense
at least, no account of the meaning of any lisp program is ever
final -- there is always the possibility of extension. Lisp programs
are, sort of, equivalences classes of sentences about incompletely
specified proper classes in a very general syntax, using just a minimal
meaningful interpretation as the definition of "a portable program".
This has implications, such as whether or not a standard should
ever enumerate all of the permitted values of a given type or
whether any procedure should be required to be total in all
possible values.
Creating a looser, open-ended, completely extensible semantics
such as I'm suggesting is tricky on two fronts: what, in the end,
do portable programs mean? and how, in the end, can we be sure
that we've spec'ed out something that can be implemented?
----------------
The focus of R6RS seems to me to be strongly influenced by
the goal of some to have compilers that implement the complete
language, and by the strong and easy-to-understand desire of the
Scheme community to have a language that is more commercially
relevant. There is a spirit around that it is really time to nail
down the language in very pragmatic ways (I agree) -- but even
at the cost of forgetting the more libertarian aspects of "the
lisp tradition" (which I find to be a bit of a bummer).
-t
>
> Robby
>
> On 2/25/07, Thomas Lord <lord_at_emf.net> wrote:
>>
>> R6RS should have both, with a consistency proof, page count
>> be damned.
>>
>> A conservative denotational as "must" and a usable
>> operational as "for example".
>>
>> -t
>>
>>
>> _______________________________________________
>> r6rs-discuss mailing list
>> r6rs-discuss_at_lists.r6rs.org
>> http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
>>
>
Received on Sun Feb 25 2007 - 21:08:28 UTC