Embedded expressions in string literals.

rssh at gradsoft.com.ua rssh at gradsoft.com.ua
Wed Mar 18 13:51:37 PDT 2009


> I don't see your binding proposal as an improvement over what we have
> got for many use cases, that is not to say that it isn't valuable as
> an API. It is an API for string processing and therefore should be a
> suggested library change; not part of coin. The string literals with
> expressions and your API proposal would be complementary, particularly
> if they had similar syntax. Also see a formal proposal for embedding
> expressions into strings on coin, it is called Proposal: Embedded
> Expressions for String Statements and is from Stefan Schulz.
>

For implementing such proposal you need a mapping between names and values.
(I. e. our binding).

Now, let's think about all entities, which we have:

1. binding.
2. String before process of substituting embedding expression.
3. Process of substituting embedding expression. (I. e. syntax of
mini=language inside string).

Applying this 3 entities we receive:

4. String after process of substituting embedding expression.

 Original Stefan proposal does not specify difference between 2 and 4.
Problem, that
  if (2) exists only in program text (and transformed to 4 during
compilation process), than
    - such transformation is possible only in static context, fixed in
compile-time. This means that you can't pass such string literal to
arguments, and, for example, next code snipset:

int x = readX();
System.out.println("You entered \{x}");

Will produce result differ, than

String message = "You entered \{x}";
int x = readX();
System.out.println(message);

I belive, that fixing all such transformations in static context is
fundamentally wrong.

Ok, now let's interpret Stefan proposal (EESL) in dynamic context.
But for this we need specify binging (explicit or implicit [in static
context ?]) and mark process of interpretation by some function. I. e.
receive all the complexity of embedding interpreted language. Fortunelly,
this complexity already implemented in JSR223 interface. Embedded
expressions proposal in such interpretation - just yet one syntax for
embedded language. (We already have near 200 JVM languages, most of them
implement javax.scripting interfaces)
 Of course, we can choose language of some simple syntax be default for
string expression processing - in such case, binding will just a mechanism
for implementation of EESL.


> 2009/3/19  <rssh at gradsoft.com.ua>:
>>> Hi All,
>>>
>>> 2009/3/18  <rssh at gradsoft.com.ua>:
>>>
>>> [snip]
>>>
>>>> Complex case:
>>>> Create special syntax for template processing inside strings - I guess
>>>> this can be a library issue.
>>>> We have jsr223. May be good ideaa is adding helper methods, which
>>>> process
>>>> string via choosed language interptreter, i.e.
>>>> ═s.scriptEval("velocity",binding);
>>>> ═.... but - from other side ═we can't receive binding between names
>>>> and
>>>> values automatically for now.
>>>
>>> Not sure that a library would work, can you give an example of the
>>> call you propose?
>>>
>>
>> Example of such call can be:
>>
>> binding = new Binding();
>> binding.put("x",x);
>> binding.put("y",y);
>>
>> """
>>  <?if ($x==$y) {?>
>>   A
>>  <? } else { ?>
>>   B
>>  <? } ?>
>> """.evalScript("PHP",binding);
>>
>> If PHP is avaible via JSR223 API, then string will be evaluated to A or
>> B.
>> Or, if you does not like PHP, you can use velocity or java.
>>
>> But creating binding by hands (first 3 strings of test) kill all :(
>>
>> From other side, in principle compiler can generate binding for local
>> variables automatically, so in principle it is possible to create 'magic
>> annotation', to write code like:
>>
>>
>> int someMethod();
>> {
>> int x=1;
>> int y=2;
>> @GenerateVariableBinding
>> Binding binding;
>>
>> String s = """
>>  <?if ($x==$y) {?>
>>   A
>>  <? } else { ?>
>>   B
>>  <? } ?>
>> """.evalScript("PHP",binding);
>>
>> System.out.println();
>>
>> }
>>
>>
>> (I think about formalizing and submitting such proposal, but not sure
>> that
>> it is possible correct define one in short terms.)
>>
>>
>>
>>
>>
>> ______________________________________________________________________
>> This email has been scanned by the MessageLabs Email Security System.
>> For more information please visit http://www.messagelabs.com/email
>> ______________________________________________________________________
>>
>





More information about the coin-dev mailing list