Lambda the Ultimate

Maybe not just language fanatics... C++ programmers as well!

"computing... and the intentional sciences, as I've said, involve a dialectical interplay of mechanism with issues of meaning, interpretation, semantics, and the like. That is: they deal with issues of significance. Moreover, what computer science is, I believe - what history will recognise it's 20TH-century instantiation to have been - is an experimental, synthetic precursor to the emergence of this new theory: ie., something I call semiotic alchemy. Think of all those C++ and Java hackers, trying to turn web pages into gold!" p16. God, Approximately. Brian Cantwell Smith

Sorry, I keep referencing his papers - the language is so meaty and direct that for 2 or 3 pages at a time I almost understand.

Oh, I agree with that 100%.

Please observe that: since the only thing XML provides is a syntax, I think you have to swallow the argument that "syntax does matter" in order to swallow the argument that "XML is useful".

This may help to explain why XML advocates are so strident about syntax: if they were to admit the negation of the proposition "syntax does matter", then they would have to revise all the consequences of that proposition, on which the greatest part of their ideology is founded.

Of course, the same holds for me: I think the importance of syntax is dwarfed by the importance of semantics, and most of my ideology vis-a-vis PLs is founded on the fact.

However, no sane person would argue that XML is an ideal human-oriented format. So it was only a matter of time before it was applied to something where the format gets in the way. RDF just happens to be the first prominent example. To make it really usable, good tools will be needed to support pain-free RDF readability and writability for humans.

In the absence of those tools, I don't think you can really draw many conclusions about how much of a problem meta-thinking is. I think a lot of people want to meta-think, even if they're not good at it. Better tools might actually allow them to do it to a useful degree.

Sure, there are different XML vocabularies, but these are basically abstract syntax, and hence more closely tied to (though not uniquely determined by) the semantics.

RDF-over-XML looks like it's playing nice with XML only superficially, requires that existing XML-based vocabularies be changed, and is a headache to parse. There are many ways of saying the same thing, which is very confusing. People are asking themselves what they buy with having a syntax laid over another syntax. Currently the answer is "wait and see".

XML is not really interesting for this debate, beacuse it should really be an internal format, and when I say "syntax matters" it's a short hand for "syntax matters to human programmers."

You'd agree, I think, that being able to compile Haskell into machine language, shouldn't serve as an argument for or against list comprehensions. The same should hold for using XML as a straw man in the "does syntax matter" debate.

Please also note that by saying that syntax matter, I am not saying that I am in favour of all kinds of syntactic sugar.

This ia a bit ironic since (a) parsing techniques are well known and (b) parsing is really one of the easy problems most of these systems need to solve.

I'm not very concerned about the presence or absence of syntactic sugar. Sometimes there is no "best" syntax to assign to a feature, and in that case, for example, having sugar is fine.

What I am concerned about is the proliferation of programming languages who differ only in their concrete syntax. This would not be a problem if we could translate programs between them. But the focus on syntax discourages programming language designers from developing a usable semantics for their languages, and that makes translation difficult or impossible; at the very least it puts the burden of developing a semantics on the implementor of the translator.

This whole "syntax matters" business is so silly anyway, not only because syntax is really the part of a programming language which is the easiest to change and replace, but because it is such a shallow form of critique it borders on the irrelevant.

Consider, by analogy, book reviews. "This book is fabulous! I love the title, `Hamlet'; it just rolls of the tongue, doesn't it? And from the leather binding to the golf-leaf page edges, author William Shakespeare's expert craftsmanship shines through. The table of contents was thrilling; each act and scene is listed with a handy page number! And the quality of the text itself is really beyond compare; the 12 point Georgia font is remarkably easy to read, and I did not notice one dangling comma or widowed heading. But let us talk about the substance of the book. The characterizations are remarkable: Mr. Shakespeare clearly took great care here, because no two characters share the same name (which would make it difficult to follow the plot), and no character's name overflows a single line (necessitating ugly hyphens). The story itself rings true, except that I could not believe that Danes speak English, much less in iambic pentameter! (Mr. Shakespeare, you might consider fixing this issue in the next edition.) Finally, I was most impressed by the portrayal of the action. Let me give you an example: `Actors exeunt stage left.' Clear, concise and vivid! There were some major problems, however. The English was extremely convoluted and difficult to follow. (Please modernize it.) The action was somewhat drawn out and tedious: Hamlet's vacillating indecision was terribly nerve-wracking. (How about having him kill his stepfather earlier, say, in the first act?) And, worst of all, all of my favorite characters died in the end! (Please could we have a happier ending?!) Still, despite its flaws, `Hamlet' is a masterwork of our age. I hope Mr. Shakespeare will continue writing such beautiful stories. PS `Hamlet' would make a wonderful movie! Just think of what George Lucas and his special effects wizards could do to heighten the pace of this drama!"

I agree that smantics are more important. I guess I am not your ideal straw man. But I still think bad syntax can ruin a language, even when it has useful/interesting/expressive semantics.

Since you like analogies: Think of those web sites with tons of pop-ups, small fonts that can't be resized, etc. The content may be great, but who will go to the trouble of reading it?

Or think of APL (or even J).

Perhaps. But one of the points I was trying to get across in my last message was that we should speak about "the language" the same way we speak about "the book". When I say, "that book is good/bad", I'm talking about the content, not the presentation (the font, the binding, the cover art); similarly, when we say, "that language is good/bad" it should be understood that we mean the semantics not the syntax.

Since you like analogies: Think of those web sites with tons of pop-ups, small fonts that can't be resized, etc. The content may be great, but who will go to the trouble of reading it?

Sure, as I've said before, if you take it to an extreme you can make syntax an impediment. But the syntax and syntactic constructs which people regularly complain about as if they make a language unusable, for example, Ocaml's syntax, lack of line-terminating semicolons or conversely mandatory braces, "too many parentheses", etc., are pretty far from unusable extremes, as is evidenced from the number of programmers who successfully use such languages.

Indeed, I am more surprised at how many and how often programmers are willing to bend over backwards to accomodate some glaring semantic defect, say lack of type safety, yet complain long and loud about syntactic trivialities.

Or think of APL (or even J).

Or Forth.

I don't have any experience programming in APL, J or K, but I don't think I would like it. Still, I know that APL and Forth at least had/have a non-negligible user base, so evidently some people were/are able to cope with the syntax.

In summary, I'm not saying syntax has no role in programming language design. I'm just saying it's a role which is vastly overemphasized to the detriment of discussions on more substantial issues. More importantly, though, I think it is far better (and more useful and practical in the long run) to perhaps commit a minor evil by saying that "syntax doesn't matter" than it is to commit the greater evil and say that it does: in particular, you are far less likely to go wrong by doing the former than you are by doing the latter.

Well, there are ways of treating such things in a purely semantic fashion by exploiting initial algebra semantics or higher-order abstract syntax, but the way most people do it is by defining a "throw-away" concrete syntax which is in a one-to-one correspondence with the abstract syntax. In other words, it's understood that the throw-away syntax is for expository purposes only, because we all know it's easy to write parsers.

Anyway, scope is, IMO, a word which refers to a syntactic matter. For example, the scope of a variable in lambda-calculus is just a convenient way of representing in textual format the fact that there are two sorts of variables in a term: free and bound ones. In categorical and graph-theoretic presentations of lambda-calculus there is no notion of scope or binding. For example, in the latter, you have nodes for lambda, application and free variables, and the bound variables are represented by edges to their binder (a lambda node).

I think we are mostly in agrrement. It is just that I think that programmers tend to overemphasize syntax just like you say, while more experienced language designers and researchers tend to dismiss it as uninteresting.

There are cases where finding good syntax involves important cognitive and notational issues (for example, that's my concern with J's phrasal forms).

It is just that I think that programmers tend to overemphasize syntax just like you say, while more experienced language designers and researchers tend to dismiss it as uninteresting.

I agree with everything, except the use of the over prefix. Language designers should view programmers as their customers (well, if they want their languages to become widespread) and realize that syntax is something their customers actually care about.

To go back to the original issue, grossly speaking, I think a good analogy is that RDF is the "language", the RDF Model is the "semantics", and the RDF XML serialization format is the "syntax". As a would-be "programmer" in this arena, I (and others I've discussed it with) find the "syntax" (not the "semantics") quite uncomfortable.

(BTW, researchers may regard parsing a "solved problem"; in the commercial world, creating "yet another syntax" is more often than not the wrong solution. Witness the success of simplistic syntax formats: XML, CSV, INI files, etc.)