That would be my favorite, too. But you're right, it *is* a very hard problem.
Am Mittwoch, 20. August 2014 19:11:27 UTC+2 schrieb Stefan Karpinski: > > There is actually one other approach that would work and produce a lot of > side benefit: write a parser generator in Julia that uses the language's > JIT and metaprogramming capabilities to turn a formal grammar into a really > fast parser and then use that parser for Julia itself. Then you not only > get a grammar for Julia, but you also get really great parsing > infrastructure in Julia, which is probably the more valuable of the two. > That's an exciting prospect, but it's a very hard problem. > > > On Wed, Aug 20, 2014 at 1:07 PM, Stefan Karpinski <[email protected] > <javascript:>> wrote: > >> No one is against the existence of a formal grammar – and anyone is free >> to write one. Of course, for it to be really meaningful, you have to make >> sure it stays in sync with Julia's actual parser. The only ways I can think >> of to reliably make sure the parser and the grammar stay in sync is to (a) >> make the grammar definitive by switching to using a parser generator or (b) >> do what Jake did with JuliaParser.jl >> <https://github.com/jakebolewski/JuliaParser.jl> and automatically run >> both parsers on a large body of code (e.g. all packages) and make sure that >> the ASTs constructed are identical. Parser generators tend to be much >> slower than hand-coded parsers and Julia's grammar is slightly context >> sensitive in a way that most parser generators – especially the more >> efficient ones – can't handle. So (a) isn't really a practical option. >> Option (b) still requires a parser generator, but since that parser won't >> be used by Julia itself, it can be slow. This option would require: >> >> 1. A formal grammar (the easy part); >> 2. A parser generator that takes that formal grammar as input and >> produces AST; >> 3. Infrastructure for automatically parsing and checking a large body >> of Julia code. >> >> Again, step 2 is made tricky since most parser generators can't handle >> Julia's slightly context-sensitive grammar – so you might need to write >> your own parser generator infrastructure. So if someone – say you – really >> wants there to be a formal grammar for Julia that stays in sync with >> Julia's parser, then it would be great if they wrote one. And then wrote a >> parser generator based on it. And then set up some infrastructure to >> automatically check its output against the standard parser on all >> registered Julia packages. This is certainly possible, but I'm sure you can >> see why I think there are better ways for the people who are most qualified >> to do this – namely Jeff and Jake – to spend their time. I'm not saying >> this wouldn't be good to have, but it's just a lot of work for fairly >> little return. >> >> >> On Wed, Aug 20, 2014 at 12:36 PM, gentlebeldin <[email protected] >> <javascript:>> wrote: >> >>> Maybe there *are* drawbacks of ad-hoc parsers, after all. I don't want >>> to be offensive, really, I like Julia... but the absence of a formal >>> specification of the grammar is nothing to be proud of. >>> >>> Am Dienstag, 19. August 2014 01:39:53 UTC+2 schrieb Stefan Karpinski: >>>> >>>> That seems likely. >>>> >>>> On Aug 18, 2014, at 7:24 PM, Elliot Saba <[email protected]> wrote: >>>> >>>> Probably because of our special parsing of & in ccall invocations. >>>> -E >>>> >>>> >>>> On Mon, Aug 18, 2014 at 7:14 PM, Stefan Karpinski <[email protected] >>>> > wrote: >>>> >>>>> Yeah, I forget exactly why you can't to that with & but there's some >>>>> parsing ambiguity. >>>>> >>>>> >>>>> On Mon, Aug 18, 2014 at 6:33 PM, ggggg <[email protected]> wrote: >>>>> >>>>>> Ok, thanks. Although it doesn't seem to be the case for |, eg >>>>>> "|(true, false)" works out of the box. >>>>>> >>>>>> >>>>>> On Monday, August 18, 2014 4:24:31 PM UTC-6, Stefan Karpinski wrote: >>>>>> >>>>>>> This are some of those few operators that need parens to be used in >>>>>>> function call syntax: >>>>>>> >>>>>>> julia> (&)(3,5) >>>>>>> 1 >>>>>>> >>>>>>> julia> (|)(3,5) >>>>>>> 7 >>>>>>> >>>>>>> >>>>>>> This isn't required in unambiguous situations like as an argument to >>>>>>> another function: >>>>>>> >>>>>>> julia> reduce(|, 0:8) >>>>>>> 15 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Mon, Aug 18, 2014 at 6:20 PM, ggggg <[email protected]> wrote: >>>>>>> >>>>>>>> Is there a named function that does what & does, eg "&(a,b) == >>>>>>>> a&b"? I actually want a multi argument version like "$(a,b,c...)". >>>>>>>> Also is >>>>>>>> that the name of that function is not "&" and "& is not overloadable? >>>>>>>> The >>>>>>>> same is not true of "|". >>>>>>>> >>>>>>>> *julia> **a = zeros(Bool,10);b=[randbool() for j=1:10];* >>>>>>>> >>>>>>>> *julia> **a&b==b* >>>>>>>> >>>>>>>> *false* >>>>>>>> >>>>>>>> *julia> **a|b==b* >>>>>>>> >>>>>>>> *true* >>>>>>>> >>>>>>>> *julia> **|(a,b)==b* >>>>>>>> >>>>>>>> *true* >>>>>>>> >>>>>>>> *julia> **&(a,b)==b* >>>>>>>> >>>>>>>> >>>>>>>> *ERROR: unsupported or misplaced expression & * >>>>>>>> *julia> **&(a,b) = a&b* >>>>>>>> >>>>>>>> *ERROR: syntax: invalid assignment location* >>>>>>>> >>>>>>>> Julia even seems to think & is a function >>>>>>>> >>>>>>>> *julia> **&* >>>>>>>> >>>>>>>> *& (generic function with 35 methods)* >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>> >>>> >> >
