Infix syntax for DSSSL

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