Hehe, yeah I'm not a big fan either.
But I've pinned the awkwardness down to the missing syntax highlighting and
weird argument passing.
Syntax could come "for free" with a good parser design, but argument
passing is still a little bit sketchy.
But I'm pretty sure, that we can find something satisfying.
How Keno calls C++ functions and passes arguments in Cxx.jl doesn't look
very awkward ;)
2014-11-16 21:19 GMT+01:00 Johan Sigfrids <johan.sigfr...@gmail.com>:
> 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 <johan.s...@gmail.com>:
>>
>> 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 <johan.s...@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
>>>>>>
>>>>>
>>>>
>>
