PEP0238 lament

[Stephen Horne]

On Mon, 23 Jul 2001 21:23:46 +0100, Gareth.McCaughan at pobox.com (Gareth
McCaughan) wrote:

>Steve Horne wrote:
>
>> I've had idle thoughts for some time about a language that would allow
>> you to define - within the language itself - the syntax and semantics
>> for sublanguages. Only the lexical rules would be fixed, though there
>> would need to be several built-in sublanguages - grammar and
>> translation definition, simple compile-time imperative and simple
>> run-time imperative being the obvious ones. The thought was originally
>> provoked by wanting to support many different paradigms efficiently
>> and concisely in the same language - if anyone comes up with a new
>> paradigm, they just create a library that defines a suitable grammar
>> and translation and, hey presto, anyone can use it without changing
>> languages, and without discarding code written for other paradigms.
>> 
>> It suddenly seems so much more like a practical idea.
>
>It's existed for years. It's called Lisp, and it's
>the reason why Python is only the second best programming
>language in the world <0.5 wink>.

I've used it, and it *isn't* what I'm thinking of - I want a human
readable language ;-)

As the saying goes, Lotsof-Infuriatingly-Stupid-Parentheses.

I'm thinking something that for the base languages specifies grammar
in a YACC-with-common-behaviour-helpers kind of way, which uses a
single imperative grammar, not too far from Python, but with two sets
of semantics - one compile-time, one run-time.

So you'd essentially define an simple grammar, and then define
compile-time-translations into run-time-implementations for the
semantics - and you'd be able to use tweaked or even completely
different semantics for the same grammar if necessary. And once the
basic sublanguages worked, new sublanguages could translate in stages
through existing sublanguages - so if you want a Prolog-like
sublanguage, you only need to translate it into the easiest existing
library sublanguage for your logical language to represent - not
*necessarily* straight to the imperative.

The fantasy says that, with that done, the community will set up a
small library for the useful paradigms, with perhaps
semantics-selection options for really controversial stuff like
division ;-)

The only big worry in principle is that I think a more
functional/logical style would be better for the compile-time language
- easier to work with for translation tasks - but I don't want that in
the default run-time sublanguage, yet I do want the compile-time and
run-time languages to have the same syntax and logical semantics (only
the execution time should change). Maybe I need to translate
compile-time sublanguages as well.