Whether you *like* the grammar is totally unrelated to whether there is a formal spec for it. It's fine to dislike the special treatment of `&` as a prefix operator. However this would not be fixed by describing the behavior you dislike in some formal language.
You know, it's interesting: it's easy to write down a grammar in formal language that is actually ambiguous. Code is not ambiguous. On Wed, Aug 20, 2014 at 4:17 PM, gentlebeldin <[email protected]> wrote: > 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]> >> 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 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: >>> >>> A formal grammar (the easy part); >>> A parser generator that takes that formal grammar as input and produces >>> AST; >>> 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) >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>> >>>>> >>> >> >
