Comment Representation is the easy part (Score 1) 438
I would say that at the very highest level (specifically the first paragraph or so), this article has got the right idea. Then it takes a bad idea and runs around like a headless chicken with it.
They talk about the fact that computer programs are represented by 'collections of arbitrary ASCII tokens' as if it is impossible to discern the meaning of the program. Er, that's what parsers are for. They parse 'collections of arbitrary ASCII tokens' into data structures. Incredibly, those data structures look a lot like their XML structure. Except, if one wishes and is clever, you can do fun things with those arbitrary data structures that are hard to do in XML (e.g. turn them into graphs vs. XML's trees). You manipulate the data structure, serialize it into text and save it. And you're done. Simple. Their problem is a non-problem.
There is also a serious lack of understanding of the term 'semantics' in this document. They are *not* representing the programs semantics in XML, they are merely storing its abstract syntax as opposed to its concrete syntax. Giving things a bunch of XML tags does not infer semantics - those semantics are defined and implemented elsewhere.
In my opinion, there are several factors that have held back so-called 'extensible programming'. Here's a couple that spring to mind. Firstly is the sheer awfulness of most parser generators. They're fiddly to use, and accept laughably limited forms of grammars. This dates back to when parsing was a very processor intensive job - these days, however, Earley parses and the like can cope with any grammar you chuck at them in comparable time to e.g. yacc. Secondly, most languages don't have macro languages, and those that do (like C) tend to do it at the token level, which lacks power and is prone to disaster unless the programmer is incredibly careful. Those that operate at the syntax level (basically LISP) work with languages whose syntax is so restricted that it's difficult to generalize to modern languages. However, I feel that Template Haskell provides a solid indication as to how modern languages can incorporate macro powerful and practical systems. And, before anyone dismisses this reccomendation, I'm *not* a functional programming fan - I just think that TH approaches the problem in a way that can be applied to other languages.
They talk about the fact that computer programs are represented by 'collections of arbitrary ASCII tokens' as if it is impossible to discern the meaning of the program. Er, that's what parsers are for. They parse 'collections of arbitrary ASCII tokens' into data structures. Incredibly, those data structures look a lot like their XML structure. Except, if one wishes and is clever, you can do fun things with those arbitrary data structures that are hard to do in XML (e.g. turn them into graphs vs. XML's trees). You manipulate the data structure, serialize it into text and save it. And you're done. Simple. Their problem is a non-problem.
There is also a serious lack of understanding of the term 'semantics' in this document. They are *not* representing the programs semantics in XML, they are merely storing its abstract syntax as opposed to its concrete syntax. Giving things a bunch of XML tags does not infer semantics - those semantics are defined and implemented elsewhere.
In my opinion, there are several factors that have held back so-called 'extensible programming'. Here's a couple that spring to mind. Firstly is the sheer awfulness of most parser generators. They're fiddly to use, and accept laughably limited forms of grammars. This dates back to when parsing was a very processor intensive job - these days, however, Earley parses and the like can cope with any grammar you chuck at them in comparable time to e.g. yacc. Secondly, most languages don't have macro languages, and those that do (like C) tend to do it at the token level, which lacks power and is prone to disaster unless the programmer is incredibly careful. Those that operate at the syntax level (basically LISP) work with languages whose syntax is so restricted that it's difficult to generalize to modern languages. However, I feel that Template Haskell provides a solid indication as to how modern languages can incorporate macro powerful and practical systems. And, before anyone dismisses this reccomendation, I'm *not* a functional programming fan - I just think that TH approaches the problem in a way that can be applied to other languages.
