On Tue, Nov 5, 2013 at 3:19 PM, Daniel Davidson <nospam@spam.com> wrote:

> Do you have working code on github that others may use?
>
>
Let me try to post it soon.

On Tue, Nov 5, 2013 at 5:42 PM, Manu <turkeyman@gmail.com> wrote:

> While thinking on a new string literal that may support DSL's, the syntax
> should optionally receive a language specification on opening.
> The thing that sucks most about DSL's is that the IDE can't syntax hilight
> them, but if it was provided what language the string was, then a smart IDE
> could apply syntax hilighting for that language within the scring scope.
> Eg, this sort of thing is supported in html, which is usually hilighted
> correctly by IDE's:
>   <script type="text/javascript"> or <script language="javascript">
>
> And exists in many other places too.
>

I agree. For that suggest the following syntax (independent of this
proposal):

That is, support UDA for expressions.

----
void main(){
  import std.conv:text;

  int var=12;

  @("syntax=python")
  r{
    def fun:
      print(@var) #will expand to tuple element 12
      print(@(var.to!string)) #will expand to tuple element "12"

    }
   .text
   .run_python;

  void run_python(string a){
    import std.system;
    system("python -c "~a.escapeShellFileName);
  }
}
----

On Wednesday, 6 November 2013 at 02:38:57 UTC, Timothee Cour wrote:
> I agree. For that suggest the following syntax (independent of this
> proposal):
>
> That is, support UDA for expressions.
>
> ----
> void main(){
>   import std.conv:text;
>
>   int var=12;
>
>   @("syntax=python")
>   r{
>     ...snip...
>   }
> }
> ----

I'd very nearly say that this could be a library function. Imagine it like this:

---
syntax!"python"(r{
...
})
---

A bit more verbose than using a UDA but the return type could be something like SyntaxType!"python" and you could make it so that functions only take SyntaxType!"python" for some compile-time checking using the type system. For instance, if your function requires python code then you can specify it in the argument. I'd also like it to be implicitly convertable to a generic SyntaxType that accepts everything if you just don't care what kind of syntax it is.

As long as it's part of the standard library, then IDEs could also take advantage of it. Not saying that they shouldn't also support UDAs, but just throwing that out there as another alternative.

On Tue, Nov 5, 2013 at 7:43 PM, Chris Cain <clcain@uncg.edu> wrote:

> On Wednesday, 6 November 2013 at 02:38:57 UTC, Timothee Cour wrote:
>
>> I agree. For that suggest the following syntax (independent of this
>> proposal):
>>
>> That is, support UDA for expressions.
>>
>> ----
>> void main(){
>>   import std.conv:text;
>>
>>   int var=12;
>>
>>   @("syntax=python")
>>   r{
>>     ...snip...
>>   }
>> }
>> ----
>>
>
> I'd very nearly say that this could be a library function. Imagine it like this:
>
> ---
> syntax!"python"(r{
> ...
> })
> ---
>
> A bit more verbose than using a UDA but the return type could be something like SyntaxType!"python" and you could make it so that functions only take SyntaxType!"python" for some compile-time checking using the type system. For instance, if your function requires python code then you can specify it in the argument. I'd also like it to be implicitly convertable to a generic SyntaxType that accepts everything if you just don't care what kind of syntax it is.
>
> As long as it's part of the standard library, then IDEs could also take advantage of it. Not saying that they shouldn't also support UDAs, but just throwing that out there as another alternative.
>


one problem with this:

r{...} is converted to a built-in tuple, and we can't return built-in
tuples from functions (only std.typecons.tuple, which has issues, eg
unnecessary copying, can't return elements by ref, etc). Note that
returning elements by ref (when needed) is crucial for use case B in the OT
(formattedRead).

On the otherhand, I also thought about using a modification of
std.typetuple.Alias that gets an extra 1st argument to indicate syntax.
It doesn't work because when there's an expression involved we get: Error:
variable a cannot be read at compile time; eg: Alias!(a+b,"foo")
and r{...} syntax is suppose to support arbitrary expressions and forward
them as builtin tuple.

On 2013-11-05 23:26, Timothee Cour wrote:
> actually an important use case of this feature is to help writing domain
> specific language inputs, eg writing a python file inside D, or config /
> plain text files.
> # is common in many languages (eg python/bash etc) as a comment.
>
> @ would be inside string literal so should cause little confusion from
> D's side, but for example would force one to escape '@' in email
> addresses (more rare).

If we're talking about writing other languages inside D, then "@" would be in conflict with Objective-C which uses that for all new syntax (that isn't available in plain C).

-- 
/Jacob Carlborg

On 2013-11-06 02:42, Manu wrote:
> While thinking on a new string literal that may support DSL's, the
> syntax should optionally receive a language specification on opening.
> The thing that sucks most about DSL's is that the IDE can't syntax
> hilight them, but if it was provided what language the string was, then
> a smart IDE could apply syntax hilighting for that language within the
> scring scope.
> Eg, this sort of thing is supported in html, which is usually hilighted
> correctly by IDE's:
>    <script type="text/javascript"> or <script language="javascript">
>
> And exists in many other places too.

Github flavored Markdown uses:

```javascript
// JavaScript code
```

-- 
/Jacob Carlborg

Reasonable proposal but I have not encountered much need in this functionality personally (std.string.format worked just fine) and thus can't really evaluate how justified such addition may be.

On Wednesday, 6 November 2013 at 03:44:07 UTC, Chris Cain wrote:
> I'd very nearly say that this could be a library function. Imagine it like this:
>
> syntax!"python"(r{
> ...
> })

I agree.

On Wednesday, 6 November 2013 at 11:45:41 UTC, Dicebot wrote:
> Reasonable proposal but I have not encountered much need in this functionality personally (std.string.format worked just fine) and thus can't really evaluate how justified such addition may be.

I also agree.

06-Nov-2013 15:45, Dicebot пишет:
> Reasonable proposal but I have not encountered much need in this
> functionality personally (std.string.format worked just fine) and thus
> can't really evaluate how justified such addition may be.

+1

Since formatting/templates became accessible in CTFE I do not see much need for this.

-- 
Dmitry Olshansky

On 7 November 2013 03:14, Dmitry Olshansky <dmitry.olsh@gmail.com> wrote:

> 06-Nov-2013 15:45, Dicebot пишет:
>
>  Reasonable proposal but I have not encountered much need in this
>> functionality personally (std.string.format worked just fine) and thus can't really evaluate how justified such addition may be.
>>
>
> +1
>
> Since formatting/templates became accessible in CTFE I do not see much need for this.


Every time I use a q{} block, it's to embed some code in a different language. I would like the IDE to syntax hilight properly if able. HLSL/GLSL, JSON, XML are the most common embedded languages I encounter.