On 30/01/2008, Freeman, Tim <tim.freeman@...
> Seems like a good idea.
> As a user, I'd rather see the SQL problem solved right by having a parser that's more sophisticated than a finite state machine than to not have it solved right.
Fair enough. It's tough to implement sophisticated and efficient
Perhaps if StringInterpolation.interpolate instead of taking a
contextScanner and an escaper published events like ('Literal, "foo")
or ('Substitution bar) to an interpolationEventSink then the current
contextScanner&escaper could be built on top of it, or an
implementation could route those events to an AST builder instead.
> In the paper, every result from Template is immediately passed to open. Did I miss one? If not, then why make people write both? I'd expect to have "openedTemplate(...blah...)" as an abbreviation for "open(Template(...blah...))", although maybe a name shorter than "openedTemplate" should be selected.
You didn't miss anything. This is an implementation detail leaking
out through the API.
The `Template` part converts the "Hello $name_of_planet!" to "new
StringInterpolation(['Hello ', name_of_planet, '!'])" and the `open`
part is really `eval` in disguise which parses the string and invokes
the constructor. Thus, two function calls are needed for this macro
> Tim Freeman
> Email: tim.freeman@...
> Desk in Palo Alto: (650) 857-2581
> Home: (408) 774-1298
> Cell: (408) 348-7536