Just as a minor point, Match.jl handles most of the pattern matching functionality of scala (although to match it fully would probably require more support in the parser, or something like what Simon proposes here).
Cheers, Kevin On Saturday, November 15, 2014, Simon Danisch <[email protected]> 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 >
