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) |
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 |
Posted-Date: | 15 Mar 2006 22:12:16 EST |
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.
Return to the
comp.compilers page.
Search the
comp.compilers archives again.