[stringtemplate-interest] String manipulations

[Zenaan Harkness]

> > > The other question was how does ;format interact with
> > ;separator. Or more
> > > general how do all the options interact. I'm not sure but I
> > think the order
> > > should be ;null, ;separator, ;format. I don't know where wrap
> > and anchor fit
> > > in.
> > >
> > >
> > > > How about these:
> > > >
> > > > /* add separator after each name: */
> > > > $names:separator=","$
> > >
> > > No the : operator is used to apply templates so this would be confusing.
> >
> > Could not 'separator' (in the context of a separator after EACH
> > item), be written simply as a template anyway, in which case this
> > is semantically consistent? (not that I can imagine a general use
> > for separator AFTER EACH item anyway... but I'm just thinking of
> > semantic consistency here)
> 
> If separator was a template the syntax would look like
>  $names:separator()$
> what is not clear is how to pass in the separator text. Possibly like this
>  $names:separator(sep=",")$
> 
> But if separator is a special template then it polutes the namespace - the
> template writer can't create a template with the name separator.
> 
> You can always create your own separator template
> separator() ::= "$it$,"
> 
> and use it as above.

As a general principle, the fewer "special cases" that a language (ST)
has, the easier it is to learn, and the greater the flexibility.

If "everything's a template" (or possible to be written as a template)
then special cases simply are optimizations, either for performance and/
or for syntactic clarity (an optimization of syntax).

So does it make sense for separator to be defined, at the language-
definition level, as merely a template utilizing standard (more basic/
fundamental) language features? Even the "between each item" version
could be defined using "allButLast" and "last" components of the list
being iterated (with separators being inserted).  ??

In this way, a particular implementation may override, or create as a
built-in, particular "de facto standard templates" such as separator
(which may as well be defined as part of the language, as a standard
library of sorts), for reasons of performance.

There's something nice about being able to use :separator(",") as a
simple template, and then, given the language-defined canonical
definition of the separator template, one can extend, learn, write
and alternative (eg "appender(...)") or whatever.

If it makes sense, why NOT have everything be a template?

I'm reminded of a commend last year reflecting on how the
languages are steadily moving closer and closer to being lisp
machines, or at least, having the various lisp features
(recursion, completions, etc).

> > > Also it is not needed because one can always add the extra , at the end
> > > $names;separator=","$,
> > > If there is a chance names could be empty then use
> > > $names;separator=","$$if(names)$,$endif$
> > >
> > > > /* add separator after all but last name: */
> > > > $names;separator=","$
> > >
> > > This is what we already have. It puts the separator between the
> > elements.
> > >
> > > >
> > > > $names:{$i$. <b>$it$</b>}:format="upperCase"$
> > > > ...
> > > > $(names:{$i$. <b>$it$</b>});format="initialCaps"$
> > > >
> > > > ??
> > >
> > > Again the :format syntax is confusing.

If we have two language concepts, and 'format' really is a
different concept, then yes I agree, it is confusing.

I am advocating for minimizing the number of language concepts.

If you've read Hans Reiser's documents on namespace
simplification, you will see where I'm coming from.

The fewer the namespaces, the more combinations of concepts one
has, the more flexibility to combine elements of your language
and/ or library, and the more you facilitate as-yet-unthought-of
cool things by the users of your language.

> > > The ;format syntax is something I am in favor of as long as the format
> > > string (upperCase) for example specifies a method to call and
> > not a string
> > > to pass to a method.
> >
> > If this is to be the outcome, then does it make most sense to
> > remove the double quotes? eg. ;format=toUpper ??
> 
> The syntax is not ;option="value" but ;option=expr
> 
> ;format=toUpper means to take the name of the format from an attribute
> called toUpper

Of course. Thank you. Still getting up to speed...

Regards
Zen

-- 
Free Australia - www.UPMART.org
Please respect the confidentiality of this email as sensibly warranted.