Using JuliaParser.jl as a reference, it loks like & is in the class
unary_and_binary_ops, as well as syntactic_binary_ops. The | operator is
not in either of these classes. At least one reason for the difference in
lowering to the AST is that & is also an addressof-like operator in the
context of a ccall. I suspect, however, that the inconsistency in usage of
the surface syntax can be regarded as a bug--you should go ahead and file
an issue.
On Monday, January 26, 2015 at 6:28:49 AM UTC-6, Gabriel Mitchell wrote:
>
> Here are two statements, one written with chained binary operations the
> other in prefix notation
>
> >>[true,true] | [true,false] | [false,true]
> 2-element Array{Bool,1}:
> true
> true
> >>|([true,true], [true,false],[false,true])
> 2-element Array{Bool,1}:
> true
> true
>
>
> Now I can also do the first for & as in
> >>[true,true] & [true,false] & [false,true]
> 2-element Array{Bool,1}:
> false
> false
>
> However if I try this in the prefix notation
>
> &([true,true], [true,false],[false,true])
>
> unsupported or misplaced expression &
> while loading In[32], in expression starting on line 1
>
> Looking a little closer, I find that the parser does this
>
> >>:(|([true,true], [true,false],[false,true])).head
> :call
> >>:(&([true,true], [true,false],[false,true])).head
> :&
>
> Can someone tell me, is this behavior for '&' on purpose? If so can
> someone point to some documentation so I can read about said purpose? I was
> interested in making calls in the function prefix notation so that i can
> write something like '&(bunchofarrays...)'. This works for '|' but not for
> '&' on my version (0.3.4). Or if there is a more idiomatic way to achieve
> this effect I'd also like to here.
>
>
