Re: Looking for papers/book on the art of language design

"Claus Reinke" <claus.reinke@talk21.com>
15 Mar 2006 22:12:16 -0500

          From comp.compilers

Related articles
Looking for papers/book on the art of language design kszabo@bcml120x.ca.nortel.com (2006-03-11)
Re: Looking for papers/book on the art of language design rjshaw@netspace.net.au (Russell Shaw) (2006-03-12)
Re: Looking for papers/book on the art of language design DrDiettrich@compuserve.de (Hans-Peter Diettrich) (2006-03-12)
Re: Looking for papers/book on the art of language design transp.3.kkoehne@spamgourmet.org (Kai Koehne) (2006-03-12)
Re: Looking for papers/book on the art of language design m_bibby@hotmail.com (Mike Bibby) (2006-03-14)
Re: Looking for papers/book on the art of language design claus.reinke@talk21.com (Claus Reinke) (2006-03-15)
Re: Looking for papers/book on the art of language design jthorn@aei.mpg.de (Jonathan Thornburg) (2006-04-08)
Re: Looking for papers/book on the art of language design slogan621@gmail.com (2006-04-09)
Re: Looking for papers/book on the art of language design kszabo@nortel.com (2006-04-16)
| List of all articles for this month |

From: "Claus Reinke" <claus.reinke@talk21.com>
Newsgroups: comp.compilers
Date: 15 Mar 2006 22:12:16 -0500
Organization: BT Openworld
References: 06-03-029 06-03-034
Keywords: design

There are many aspects of language design that are no longer art,
but craft. this is partially because language theory has evolved, but
partially because languages are now less restricted by implementation
considerations (you'll find that lots of early "language design" papers
were only concerned with implementation aspects; neither techniques
nor machines were up to implementing the ideas people had, and
"waste not, want not" was an important consideration). the latter
means that language design can now focus more on nice properties
and closeness to the application domain.


nowadays, keeping one or more semantics in mind can help a lot,
but implementation is only one of those (in the following, don't
interpret domain too strictly):


- analytic language design:
        map from the syntactic domain to a semantic domain, then use
        the latter to understand and criticize the former
        (the syntactic domain being your language as the representation
        of the things you're interested in, a semantic domain being
        anything with a useful theory that can represent substantial
        parts of your language)


- constructive language design:
        map from a semantic domain to a syntactic domain, ie. first
        find out what it is you want to represent, then construct a
        representation for it
        (this is particularly important for domain-specific languages:
        you're dealing with experts in some field, they tend to have
        very well-developed ideas and theories about their work;
        they may even have informal domain-specific notations;
        what they don't have is a consistent representation of all
        that domain expertise, specific enough that computers
        can do anything with it)


- pragmatic language design:
        still the most successful branch: find use cases, find ways
        to tackle them, collect results in a "language". the results
        are rarely nice, but often popular and useful.


        even if you are taking a more systematic approach, you
        need to keep an eye on pragmatics: your language users
        will repeat your design struggles in a general way (they
        will need to understand program representations in terms
        of their mental models, and they will need to be able find
        program representations for their problem/solution
        understandings)


traditionally, the pragmatic approach and the analytic approach
tend to be opposed, and often correspond to real-world vs
academic languages:-( but only the combination of all three
looks promising to me for the future.


one thing that may need pointing out: there is no "the"
semantics, and mathematical domains are not inherently
better than logical, or operational, or domain-specific
models, as long as they all have a useful theory (that is,
you not only have source code, but some ideas about
the properties of the programs it represents). imho, the
point of providing a semantics is not to define "the"
meaning of programs, but to give a meaning.


the real benefit of semantics for language design comes
from having more than one representation, and being able
to compare them:


- if you have a language feature with a really hairy
        semantics, you probably want to rethink that
        part of your language design;


- if you expect your language to have properties that
        simply aren't reflected in your current semantics,
        you'll need to keep searching for a better semantics;
        if you can't find any, there is probably something
        wrong with your intuition (part of the task of studying
        language design is to refine your intuition:-)


- if your semantics gives you nice properties that aren't
        reflected in your language, you probably want to make
        your language a better match for its semantics


- if your semantics are too far from the mental models
        your programmers like to use, your language will flop


cheers,
claus


ps long time ago, I collected a handful of references, but
        I guess all the links will be out of date, and the selection
        is rather tiny and old:
        http://www.cs.kent.ac.uk/~cr3/bib/bookshelf/Language_Design_Semantics.html


>> Does anyone have a reference to a tutorial or explanation of how a
>> modern language is designed; I'm specifically thinking of application
>> specific languages but pointers to discussions about designing general
>> purpose languages are welcome.


Post a followup to this message

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