[antlr-interest] ST 4.0 planning

[Foust]

Austin,

Very well said -- all three points, on multiple levels.

I especially like your observation about languages. The design of the
language should not get in the way of getting common stuff done (Prolog, F#,
ERLANG, etc.), without giving even more back for the effort (as do C++,
Java, C#, etc.).

> pretend you have a SQL database as the ONLY thing available 
> to the template engine

I don't know ST well enough to comment on its implementation, but it this is
an intriguing idea. Wouldn't you need expression support, in addition, to
allow the manipulation/combination of that data?

-Brent

> -----Original Message-----
> 
> 1. Part of putting code into an open source project is letting
> everybody
> else read it. Another part is letting other people contribute to it.
> 
> Before you spend a year writing code, go to some conferences that have
> nothing to do with parsing.
> 
> 2. There seem to be two models for using ST currently. First is "let
> the
> templates run free." Second is "call a template, then call another."
> 
> 2a. The "templates run free" is I guess the "best way" but getting all
> the data structures set up so that the templates can be happy takes a
> hell of a lot of work. If you could do that, then one template could
> blissfully call another and another, referring to the giant global data
> store.
> 
> 2b. The "call one, call another" makes more sense from an immediate
> code
> perspective, especially from a parser: here's all the context I have at
> the moment, go generate a little bit of text and come back. I'll pass
> that string up the chain, and somebody with more or different
> information can insert that string into their context.
> 
> It makes sense for there to be a sort of happy medium, 2c, which maybe
> should be built on top of some kind of hierarchical base data object
> class. That way callers with fairly limited context could link a
> template, or a location (anchor? namespace? context) inside a template,
> to a concrete data element. But at the same time, the templates could
> be
> written to interact with each other, instead of just dumbly returning
> text. In that respect, it seems a little bit like the DOM tree model.
> Except that it shouldn't be. It should be more general purpose -- an
> in-memory database, say. (Seriously: as a thought experiment, pretend
> you have a SQL database as the ONLY thing available to the template
> engine. What do templates look like?)
> 
> Alternatively, think about what happens if template data access uses
> xpath syntax.
> 
> My point is that the stuff *outside* the angle brackets is easy. It's
> the interpolation and invocation and whatnot that costs all the effort.
> At some level, you'll wind up writing a PHP interpreter. What do you
> really want as your requirements?
> 
> 3. I read a bunch of stuff about how ST was a functional language. And
> I
> remember thinking, what possible use is this to me? Do I give a rat's
> ass if my text is generated in a functional language? At the time, I
> was
> trying to implement automatically generated sequence numbers for things
> like test cases and symbols. It was far more difficult than it needed
> to
> be to inject that single simple feature. I had to support it in my
> code,
> rather than having it come for free in the templates. And it tended to
> taint my design. There needs to be a way to get stuff done, and if that
> means that a bunch of nerds from the Esoteric Language Institute are
> disappointed, give 'em a Klingon dictionary and send them home.