Re: Heresy? Re: DSSSL WWW Enhancements

[Paul Prescod <papresco@xxxxxxxxxxxxxxxxxxxxxxxxx>]

Dave Love wrote:
> For instance: you probably don't want to make whitespace significant
> and you probably want infix arithmetic.  Now you need a way to square
> the presence of `-' in names in the standard with its use as an
> operator; 

You're right. Thanks for raising these issues. As you mention, we would
have to map DSSSL identifiers into the character-space of the infix
language. Luckily underscores cannot go inside DSSSL identifiers (though
they can start or end them) and `-' cannot go at the start or end (but
can go inside).

> you probably also need a syntax for representing the value
> of the symbol formerly known as `-' to be able to use it in higher
> order functions.  Etc.

Is that a big problem?

foo( a, b - c, d, e);

 vs.

foo( a, b, - ,c , d, e );

Even in C you can use function names as parameters without ambiguity.
 
> Obviously you can hack round this, perhaps by defining `_' to have the
> normal meaning of `-' in the right context but, unless I've missed
> tricks, you're probably defining a language which is non-trivially
> different from the base expression language.  


Non-trivially different in syntax of semantics? I think that the goal is
to making something with a non-trivially different syntax. 

> Would application as juxtaposition à la ML and Haskell be good for the
> masses?  (I don't know, but suspect the Dylan route is better.)  If
> so, there are probably extra issues there.

I think we would just stick to C/C++/Perl/JavaScript style parenthesized
function application.
 
> Another significant point is that if you're talking about a
> translation between two different syntaxes, possibly mixed, there are
> probably significant issues when it comes to debugging (which is
> already hard enough already, at least in current Jade, no whinge
> intended).

That's something to keep in mind. I'm not sure if there is sufficient
benefit to the layered approach to make it worthwhile unless the DSSSL
implementation were being built on top of an existing Scheme
implementation without source coude available. Implementors who want to
support both syntaxes and want to allow debugging of both syntaxes would
have to implement two parsers. This shouldn't be a big deal unless you
can't change your Scheme implementation.

 Paul Prescod



 DSSSList info and archive:  http://www.mulberrytech.com/dsssl/dssslist