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]> 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]> > 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)* >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>> >>> >
