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 h
I'd also argue that JuMP is a DSL ;)
And I guess it would also profit from having less constraints on the actual
syntax and custom syntax highlighting, which doesn't need to be explicitly
defined.
Keno seems to do a lot of things, which would also be needed for easier DSL
generation, like integ
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-
>
> 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.
>
Well, in the examples you showed the command block is passed as string
anyway, so the more accura
I'd argue (and in fact we have in the academic literature) that JuMP.jl is
a DSL for mathematical programming, e.g.
m = Model()
@defVar(m, x[1:5], Bin)
@addConstraint(m, sum{x[i], i=1:5; iseven(i)} <= 2)
solve(m)
Notice the sum{ }
On Sunday, November 16, 2014 10:45:57 AM UTC-5, Isaiah wrote:
>
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 w
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 gue
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
You'd need some sort of special delimiters anyway, and """ is pretty good
because it is unlikely to occur in a DSL.
It depends on how you look at it, but I'd actually argue that a string
macro isn't more like a string than the rest of the code file is a string.
Good editors will have a much bet
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 satisf
> Its just something inside me that rebels against having code inside
strings.
Yea, I don't like it either. If feels half-done.
New token? @@
If you want DSLs to have arbitrary syntax, then you need to put them inside
of strings or the moral equivalent thereof (e.g. Julia's backtick syntax
for commands). If you're ok with the DSL using Julia syntax, then you can
use a macro. Anything besides that ends up delving into making Julia's
gramm
12 matches
Mail list logo
