On 02/03/2011 07:16 PM, Ulrik Mikaelsson wrote:
2011/2/3 "Jérôme M. Berger"<[email protected]>:
Then why has not Lisp won over all competition years ago?
Jerome
You mean why(not(has(won(lisp,all(competition)),years_ago))) ?
Jokes aside, I think people in language-debates often forget that
high-level languages are really just layers of syntactical sugar over
machine-code. ASM is syntactical sugar over machince-code, C is
syntactical sugar over ASM, and D is mostly syntactic sugar over C.
They are merely ways to streamline certain programming-models, into a
language that encourages those idioms and constructs. Just about
anything that can be written in D, can be written with equivalent
semantics in C, but the D-version is likely to be faster to write, and
faster to comprehend.
The first part of this paragraph says, imo, something different from the second
part.
I think there are two kinds of features over a core language: ones are as you
say plain sugar; others (let's call them conceptual) introduce new semantic
notions. To distingish those 2 kinds, one needs to observe how translation of
code involving a given feature into the core language is to be done:
* sugar features only require plain rewriting
* conceptual features require a transformation of the code
The purpose of PL design, imo, is to figure out what kinds of notions people
use to "model" and define them in the language. Then, expressing a model
holding such notions using this language is direct. If a given notion does not
exist in the language used, then one needs to transform the model before beeing
able to express it; then, the code does not look like what it means (or
should). This is what I call "semantic distortion" (and others conceptual
mismatch).
The above distinction of 2 kinds of features is taken from a document called
(IIRC) "Expressive power of Programming languages", which itself builds on a
similar distinction made in the field of logic formal languages.
The purpose of higher-level languages is to encourage "good"
programming style and readability. Period. The syntax is crucial here,
it determines which constructs will become readable, and which won't,
which in turn determines the mind-set of the programmer. Which is why
I consider syntactic sugar to be seriously under-appreciated and
undervalued in many language decisions.
Syntax & semantics play together in "linguistic" notions built into a language.
Sugar features are purely syntactic, library features purely
semantic/conceptual, linguistic features are both.
Trivial example: the notion of iteration expressed by 'foreach'. Why is it so
successful, while it's usually trivial to do without it? I guess the reason is
foreach expresses, as is, a notion that exists in the (mental) "language of
modelling". Without foreach, one needs to transform this notion into different
semantics, using a general purpose looping construct (while), also involving
elements that do not belong to the model (node pointer, ordinal index,...).
Since this is an extremely common idiom, we are used to decode it as
"iteration" at first sight. But the code does /not/ inherently express
iteration by itself:
foreach (node ; list) {
auto element = node.element;
doSomethingWith(element);
}
Node* node = list;
while (node) {
auto element = node.element;
doSomethingWith(element);
node = node.next;
}
Denis
--
_________________
vita es estrany
spir.wikidot.com
