function version of &

[ggggg]

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)

[Stefan Karpinski]

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

[ggggg]

Ok, thanks.  Although it doesn't seem to be the case for |, eg "|(true, false)" works out of the box.

[Stefan Karpinski]

Yeah, I forget exactly why you can't to that with & but there's some parsing ambiguity.

[Elliot Saba]

Probably because of our special parsing of & in ccall invocations.

-E

[Stefan Karpinski]

That seems likely.

[gentlebeldin]

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.

[Stefan Karpinski]

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:

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.

[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.

[gentlebeldin]

That would be my favorite, too. But you're right, it is a very hard problem.

[Jeff Bezanson]

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.

[Jameson Nash]

Sounds to me like another reason for deprecating this special syntax (and replacing it with an improved ccall, as part of the jn/ccall3 WIP)

:)

[Jason Merrill]

On Wednesday, August 20, 2014 3:22:07 PM UTC-7, Jeff Bezanson wrote:

You know, it's interesting: it's easy to write down a grammar in
formal language that is actually ambiguous. Code is not ambiguous.

I think this was at least part of the motivation for PEGs. They are closer to modeling the way that recursive descent parsers actually work.

Another way to put it is that PEGs are designed for recognizing languages, and CFGs are designed for producing examples of languages.

[gentlebeldin]

Whatever, if I rtfm, especially the part saying "Operators Are Functions" (with the only exceptions of && and ||, because of short-circuit evaluation), then I conclude that the error message following &(x,y) is not a feature, it's a bug. And whether we like a generated parser or not, it's better than a buggy one, imho. Sure grammar can be ambiguous, but there are techniques to get around that, like here: http://accent.compilertools.net/Accent.html

[Stefan Karpinski]

How & is parsed has nothing to do with whether we use a parser generator or not. The only relevance is that having a formal grammar would make it easier to know that & is special in this respect. But better documentation would serve that purpose better than a formal grammar.