[stringtemplate-interest] ST Half-in or All-in? Pragmatism & Portability.

[Joseph Grace]

I was just reading Harry's post suggesting a variety of ST operators, and it
brought the discussion back to basics:  which operators are commonly needed.
 He lists some useful operators, but it occurred to me that (with
conditionals) there are any number (combinatoric) of ways to combine them,
depending on need.  So customization is essential (no surprise).  Custom
data handling is a recurring, major issue these operators could address
using ST across applications, via user hooks for their own custom needs.  ST
could help with custom data issue in a pragmatic way by adding a work area
to support custom conversion (et al.) code.  "com.<domain>.<app>.*"
Then I thought back to some questions Zen asked earlier in the conversation:
"If we added native.if, are there other operators you see being useful in
the native.* library?", and
"A native.* library would be good to think/ plan for in advance though,
rather than one feature at a time, don't you think?"

I realized there's really a second concern intermingled with "custom data",
and that's the whole issue of keeping ST portable across languages.  ST data
conversion is not something that is always custom.  Each language may
present its own special needs, but many problems will be generic conversion
problems shaping, converting, tweaking, tagging data for ST.  ST could
probably use a portable library (a la Zen's questions, above) to handle
standard data conversions (et al.) into ST.  ("st.*" and "st.<lang>.*").  An
ST standard portable library could help with data conversions, capture
expertise for reuse, and lend a hand with language portability of ST.  ST
support could also foster more community among users of specific languages
with ST, through language specific support ("st.<lang>.*").  The idea would
be to make ST portable to many languages, by treating those languages and
data with first-class citizenship.

Pragmatism & Portability.  Those are really two separate issues.

I think the key idea is that data migration into ST can be difficult from
unorthodox languages or applications. The key to making ST work in many
situations is ST Data Generosity, the idea that ST should be generous about
accepting data. However, that can be a can of worms.

So we really have two concerns representing two namespaces:

1. "com.<domain>.<app>.*" Pragmatism.
Make ST extensible for custom projects/situations: User Extensibility.
"com.domain.app.*" Open to all developers.

2. "st.*" and "st.<lang>.*" Portability.
Help ST play nice, accept data easily: Data Generosity.
"st.<lang>.*" Ports ST data tools for ST to host each language.

I guess that's really a mash-up of Graham Wideman's namespace
suggestions + Zenaan
Harkness's library questions.

#1.  Pragmatism means that ST would open itself to user extensibility by
providing a namespace for custom tools.  Let the developers hook to their
models however they want or need, convert their data, and start using ST
even if the data is idiosyncratic.  Basically, ST would provide an extra
layer ("com.<domain>.<app>.*") within itself to take care of sticky model
and other custom data issues.  Users have a work area for getting their data
into ST any way they need or know how.  ST becomes friendly to all
string-compatible data.

#2.  Portability means that ST actually takes an active role in helping data
fit it's model, and would do so with welcome arms (instead of begrudgingly).
 So that's a philosophical change for ST community, but means that ST would
become a more language portable and data friendly tool.  I do not have any
ideas on what the library would look like, but I think ST could benefit from
taking a proactive role in being a good customer for data and hosting data
into ST.  The library would be portable across languages as much as
possible, but would probably end up also having specials code for
idiosyncracies of certain languages (putting emphasis on porting data into
ST).

As stuff from #1 gets shared among users, it could eventually graduate into
#2, library support for ST itself.  #1 would be minor leagues, and #2 would
be official ST data conversion tools.

-=-

Granted, all this is a far cry from Ter's main application for ST:  antlr.
 Antlr is a closed system, so this data hosting idea doesn't apply.
 However, in the real world, since ST is so useful, tool friendliness
(extensibility, pragmatism) and data hosting (conversions, portability)
become real issues.

Philosophically, I think ST pragmatism and portability would be a big step
forward.  However it would be a second focus and a lot of new
responsibility.  I'm not sure ST is ready for it.  However, the timing is
right for such a change since Ter is retooling ST for STv4.

Adding data conversion + hosting support would expand ST would become a
two-part toolset.  1.  ST the functional language.  2.  ST data conversion
and hosting tools.  That would be new focus for ST and ST community, and
would require dropping the insular attitude and adopting an open attitude
toward data as a first-class citizen in the ST space.   Each ST port would
then involve porting any "st.*" and "st.<lang>.*" library support functions
as well (and I don't know what else).  So ST would become higher maintenance
to see wider adoption, success, and... more radical testimonials!-)

I'm not sure if the ST community is ready or even wants such success.  One
person has already spoken out against such growth and expansion.  Now that
such growth appears to have higher maintenance costs, since ST would be
taking on some of that responsibility with "st.*" and "st.<lang>.*", such an
expansion may be seen as a threat to the community or otherwise undesirable.

OTOH, ST is powerful and has tons of potential, and maybe Ter would like to
see ST expand its roots to become more pragmatic, portable, and broadly
successful.

Cheers,

= Joe =
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.antlr.org/pipermail/stringtemplate-interest/attachments/20091020/7bec9a46/attachment-0001.html