No! The expression between *begin ... end* must still be valid Julia
syntax, which is why you need to tell Julia, not to parse it into a Julia
AST, but into some intermediate representation.
@Scala begin
person match {
ERROR: syntax: extra token "match" after end of expression
2014-11-16 16:18 GMT+01:00 Johan Sigfrids <johan.sigfr...@gmail.com>:
> Would it be impossible to simply have something like:
>
> @Scala begin
>
> person *match* {
> *case* Person("Hans","Meyer",7) => "Found: Hans Meyer"
> * case* Person("Heinz","Mustermann",28) => "Found: Heinz Mustermann"
> * case* *_* => "Unknown Person"
> }
> end
>
>
> Without having to have the multiline string thing or DSL call?
>
> On Saturday, November 15, 2014 11:55:15 PM UTC+2, Simon Danisch wrote:
>>
>> Hi,
>> I was thinking about Domain Specific Languages lately from different
>> perspectives and concluded, that we could "easily" make Julia an awesome
>> home for DSL's. (Domain Specific Languages)
>> Why would Julia benefit from a good infrastructure for DSL's?
>>
>> *1.)*
>> Rapid prototyping of language concepts.
>> I was considering Mauro's trait implementation lately, and I didn't want
>> to use it, because it just looked a little cumbersome (no offense, its just
>> a little difficult with only macros!).
>> If he was able to implement the prototype first with a DSL, he could have
>> already created a syntax prototype for it and thinks could have looked more
>> concise and inviting.
>>
>> *2.)*
>> Writing in different languages inside Julia, for example Assebler, OpenCL
>> kernels, OpenGL shader, etc...
>> function foo(a::Float32, b::Float32)
>> @DSL Assembler(a, b)"""
>> push RBP
>> mov RBP, RSP
>> vaddss XMM0, XMM0, XMM1
>> pop RBP
>> ret
>> """
>> end
>> I know you might ask, why this is a good idea, as LLVM should be tuned,
>> to emit the best native code.
>> But lets assume that it doesn't! Then, a person can already prototype how
>> the code emitted by LLVM should look like, and another person, who probably
>> knows LLVM a lot better, can do the appropriate changes to LLVM/Julia.
>>
>> *3.)*
>> Classic use cases like a specialized UI languages, first order logic,
>> other mathematical constructs, scripting, etc...
>>
>> *4.)*
>> Stealing nice syntactic concepts from other language, to see if they give
>> Julia any advantages, without a big hassle.
>> function isspecificperson(person)
>> @DSL Scala"""
>>
>> person *match* {
>> *case* Person("Hans","Meyer",7) => "Found: Hans Meyer"
>> *case* Person("Heinz","Mustermann",28) => "Found: Heinz Mustermann"
>> *case* *_* => "Unknown Person"
>> }
>>
>> """
>>
>> *Possible disadvantages: *
>> If widely used, code will get harder to read, as you need to learn all
>> the crazy DSL's users are creating.
>> But this will happen anyways, and it's probably better to do it in an
>> orderly fashion than ;)
>>
>> *Implementation Sketch:*
>>
>> macro DSL(name, text)
>> tokens = *dsltokenizer*(DSLTokens{name}(), text)::DSLTokens{name}
>> dslast = *generate_ast*(tokens)::AST{name}
>> return *dsl*(dslast)::AST{:Julia}
>> end
>>
>> # Default implementations:
>> *dsltokenizer*(::DSLTokens, text) = ... # Default probably with Jake
>> Bolewkis Lexer?!
>> *generate_ast*(text::DSLTokens) = ...
>> *dsl*(ast::AST) = ...
>> #Depending on the complexity of your DSL, overwrite any of these stages,
>> to implement your own DSL, otherwise use default
>>
>>
>> It seems like Jake Bolewski has already implemented a lot to make this
>> work.
>> Probably it would be nice to integrate OpenCL kernel code like this ;)
>> My hope would also be, to pair this with meta data on the different
>> stages, to make it very easy to supply correct syntax
>> highlighting/correction for the different DSL's.
>> Creating the ast and tokenizing things otherwise needs to be done twice,
>> one time for the system and one time for an IDE.
>> Or are there currently simple ways in Julia, to determine where tokens
>> are in a string, what scopes there are and what kind of attribute println
>> is in "println("1234")" ?
>> I haven't found them yet. Most of the things you would currently need to
>> implement for this, will be redundant to "parse" and are then volatile to
>> changes in the language.
>>
>> Well these are just some thoughts I recently had, feel free to evaluate
>> this and/or judge if this is something we really want!
>> I won't implement this anytime soon, but maybe someone searching for a
>> bachelor/master thesis comes to the rescue?
>> Who knows...
>>
>> Cheers,
>> Simon
>>
>
