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
>
