Subject: Infix syntax for DSSSL From: Paul Prescod <papresco@xxxxxxxxxxxxxxxxxxxxxxxxx> Date: Tue, 20 May 1997 10:59:49 -0400 |
Here are my responses to the major issues that have been raised about my idea of an infix syntax for a DSSSL-based language. XML AS MARKETING ================ Netscape has been adamently against the very *concept* of SGML for years, without understanding it. Then we simplified it a little, put a Web "spin" on it and all of a sudden its the greatest thing since sliced bread. Microsoft may have come to XML honestly, having used and understood SGML before, but Netscape was actively *hostile* to the *concept* of generic markup until we put a different spin on it. SYNTAX CHANGES ARE COMMON ========================= Let me cite several precedents. * Two years ago Netscape was developing a language called "LiveScript". It was supposed to be a great tool for client-side scripting in end user products. Then the Java hype hit. "LiveScript" disappeared. A month later it was back, called "JavaScript" with exactly the same semantics but Java-syntax. * Java *itself* had a completely different syntax when it was called "oak" and was rewritten with C++ syntax to appeal to the programers of the day. * The same holds for Dylan: it was completely rewritten to get rid of the parentheses. I have an old Dylan book and the semantics are the same but ths syntax of the new and old languages are incomparable. * Liam Quinn has mentioned that SoftQuad has also had trouble "selling" parenthesized languages. So I'm not the only one with this crazy idea that syntax matters when you are trying to "sell" a language. Sun (Java), Netscape (JavaScript) and Apple (Dylan) all agree. IS SYNTAX A REAL CONCERN? ========================= Am I "anticipating" the concerns of users without real evidence? I have heard DSSSL attacked in MANY fora, from the SGML-TOOLS mailing list to SGML-oriented companies I have worked at, to the W3C hosted www-style mailing list. Everywhere I hear it attacked the charge I hear laid is: "It's really just LISP!" (or Scheme, if the person is a little better educated) I have no metric by which I can judge if these people are complaining about the parenthesis or the semantics, but I am quite confident that most of them have never *tried* DSSSL and have rejected it out of hand because of bad memories of a "comparative programming languages" course they took five years ago. I think a change of syntax would force those of them who have not heard of it to look at it with fresh eyes and *give it a chance*. I don't think that people should be thinking of DSSSL as a programming language and evaluating it based on their knowledge of programming languages. They should be using it as a *stylesheet language* and completely ignoring the expression language until they have to do something hard. But the usual effect is just the opposite: "Look at those parenthesis! Is this thing based on LISP???" That negative first impression is not serious in the world of SGML which is driven by standards and ideas, but it might be enough to kill it in the world of the web which is driven by hype. Sun, Netscape and Apple would not have changed the syntaxes of their respective languages if they thought that the previous syntaxes would "fly". Anyone who thinks that Netscape is not stupid enough to kill DSSSL because it "looks funny" has never had an email or newsgroup conversation with Marc Andreeson. I believe him to be stupid and stubborn enough to do so. We may be able to "sneak" an infix into Netscape because they are used to this concept of extending declarative languages with programmable extensions. But they have to believe that the programming language is an extension, and not at the "heart" of the language, which is what many people believe about DSSSL. If the language is like Java or JavaScript, we will probably have almost no difficulty sneaking it in (but we risk losing control, as Earl Hood pointed out). Example Quotes (from two different people on SGML-Tools mailing list): "Well, Scheme is not my ball-park, mainly because languages like this almost never leave the .edu domain and I sadly have to spend my time writing .com stuff ;-)" "My problem with DSSSL is that any Scheme-based tools are either a) slow (most Scheme interpreters) or b) produce huge object codes (as with "bigloo"). This makes distributing the translators difficult. Either you must distribute the Scheme interpreter, or you must distribute huge executables." IS THE SYNTAX DIFFICULT? ======================== No, of course the DSSSL syntax is not difficult. Syntax is just syntax. 100 more posts about how easy the syntax was to learn won't convince me, because I already believe this. But I *do* believe that the syntax is frightening off people who *could* learn the semantics. Almost everyone in this mailing list was motivated to learn DSSSL because it was an ISO standard. But DSSSL is moving into a world where people don't care about ISO standards. Hell, in the XML WG they are doing whatever they can to BREAK compatibility with the ISO standard (we're fightening them off, though!). Once you are motivated you can overcome your slight discomfort at a radically different (and initially inscrutable) syntax and get at the semantics. But you have to get to that point... DSSSL IS NOT ABOUT FUNCTIONAL PROGRAMMING ========================================= Let me address the complaint that the hard part about DSSSL is "functional programming." There is a hell of a lot that you can do in DSSSL without doing any recursion or higher order programming at all. What about simple things like this: element ITEM{ let parent-type = attribut_string( parent(), "TYPE"); switch( parent-type ){ case "ORDERED": return make( // numbered list // ); case "UNORDERED": return make( // bulleted list // ); } This is stone-cold ordinary. This type of thing is easy *even in CSS*. It doesn't require understanding "functional languages" or "higher order functions" or "side-effect free programming." It is a simple *expression* for controlling the output of the DSSSL stylesheet. I encourage everybody to download Richard Light's TEI-Lite stylesheet. You will find it to be a SUBSTANTIAL, LARGE, POWERFUL stylesheet that does not (from my persual) use recursion or higher-order functions except for two parts. The first is changing things from upper case to lower case (not necessary with James's proposal). The second is: (define (expt b n) (if (= n 0) 1 (* b (expt b (- n 1))))) I didn't know that exponents were so popular in stylesheets, but now that it is clear that they are, I think we can simply put in a built-in function for them. Jon Bosak's HTML stylesheet uses recursion in exactly the same two places. If we provide them as built-ins, the stylesheet would not need ANY knowledge of functional programming. I use recursion increasingly *infrequently* in my programs as I learn how to use other DSSSL features like modes. I also think that you can often avoid recursion by using "map" and "apply". I think we might even be able to wrap those up in Java-syntax and pass them off as loops: (apply string (map toupper (string->list (data)))) becomes: let letters = string->list( data()); for letter in letters { toupper( letter ); }; return apply( string, letter ); // converts list of chars to string (apply string-append (map string-append (lambda (x) (string-append "[" (number->string x) "]")) (element-number-list ...))) becomes let number_list = element-number-list( ... ); let string_list = for number in number_list{ string-append( "[" number->string( x) "]"); }; return apply( string-append, number_list ); I daresay that even to me the parallel-loop version looks clearer. Any recursive function that loops over a list or node-list and returns a list or node-list can be be converted into a parallel-loop version like this. Now that I know this "trick" there are substantial stylesheets I have written that do not require knowledge of how to "really" do iteration/recursion in DSSSL. I predict that 95% of all DSSSL-infix stylesheets would be written without any recursion/iteration except for "for". People using it would only have to be familiar with the concept of the "for" construct and the functions for turning things (e.g. strings and node-lists) into lists and back to things (e.g. strings and node-lists). Paul Prescod DSSSList info and archive: http://www.mulberrytech.com/dsssl/dssslist
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: SGML/XML syntax for DSSSL, Sebastian Rahtz | Thread | Re: Infix syntax for DSSSL, Sebastian Rahtz |
Re: SDATA entity mapping, Anders Berglund | Date | Re: SDATA entity mapping, Vivek Agrawala |
Month |