Yeah, that's fair. Its just something inside me that rebels against having code inside strings.
On Sunday, November 16, 2014 9:40:07 PM UTC+2, Simon Danisch wrote: > > Well, the DSL macro I sketched out would allow for that. > Maybe, if time comes and people think this is a good idea, this could > become an extension to normal macros? > But first of all, a prototype is needed anyways... How deeply the > prototype will be integrated later on depends on the feedback, I guess. > > 2014-11-16 20:01 GMT+01:00 Johan Sigfrids <[email protected] > <javascript:>>: > >> Your right. That is a problem. Is there no way to extend Julia so that >> you can create a macro that automatically uses a custom parser? >> >> On Sunday, November 16, 2014 5:26:26 PM UTC+2, Simon Danisch wrote: >>> >>> 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 <[email protected]>: >>> >>> 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 >>>>> >>>> >>> >
