Hi folks, I got some idea and ready for being criticized
Currently, only some swift syntax allowed in function building closures, but that limits the expressivity of DSL in that it cannot accept raw strings of text which can be some external code. For example, something like this is not possible:
Python {
import os
catPicture = os.open("../royal-kitten.jpg")
}
//or
EBNF {
variable_declaration := 'var' identifier (':' type_spec)? assignment_expression;
}
Well it is possible to do it, but it is ugly as hell :
Python {"""
import os
//HOLY!
catPicture = os.open("../royal-kitten.jpg")
"""}
My point is - if the function building stuff is mostly concerned with an aesthetic vibe in every place, then accepting the code as a raw string should be possible.
In short, I suggest making an addition to function building aggregate a set of new attributes:
//must contain the function that takes a string and produces a syntax tree
@syntaxParser struct PythonParser {}
//must contain a function that for every token adds additional metadata about colouring to it
@syntaxColoring struct PythonSyntaxDyer {}
//and the cherry in this mix
//attribute for marking closures inside a fb declaration
@quasiString(syntaxParser:syntaxDyer:)
@functionBuilder struct HLSL {
static func buildBlock(_ partialResults: @quasiString(...) String) -> HLSL.Shader {
...
}
}
Capturing values from swift should be done with unquoting:
let a = 3
Python { someValue = #{ a } }
//syntax of the representative language must not collide with unquoting
//probably should be possible to change quotation starting symbol
What ya all thinking bout that?
- +1
- -1
0 voters