remove "typed hcat" syntax?

[pwl]

A space after the first "end" in the code

x=[1:2]
x[end :end]

results in the following error

ERROR: no method Array{T,N}(Array{Int64,1}, Int64, Int64)

Without the space the above code works just fine. Is this the expected behavior?

[ivarne]

Essetntially a dup of #6478.

The :end is parsed as a symbol, and this is very annoying, but at least known behaviour.

[cmundi]

I may be a heretic or a blessed lunatic, but here goes... This sort of idiosyncrasy is much less likely in languages built from a formal gramnar. I was very surprised when I realized that the Julia grammar is defined implicitly by the parser implementation. No one can say you guys don't have guts. I would never attempt to implement a rich type system without a formal grammar, just as an example. Having a grammar (even if inferred post facto) might be useful for non-self-hosted code manipulation as well as for thinking through proposed future language changes.

[JeffBezanson]

If we had a formal grammar, it would state that x[end :end] is syntax for a typed matrix literal with one row, and you would get the exact same error.

[cmundi]

Fair enough. Then it's a feature and I won't be surprised. I was one of
those kids who read the appendix of K&R and then gave the book away to
someone who might have a use for the rest. As long as the number of
counterintuitive features...and I claim this is one...remains small, the
grousing of grumpy pragmatists like me won't hurt Julia uptake. So 'end'
is special, just not that special. Got it. :)
On Apr 14, 2014 12:00 PM, "Jeff Bezanson" notifications@github.com wrote:

If we had a formal grammar, it would state that x[end :end] is syntax for
a typed matrix literal with one row, and you would get the exact same error.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/6491#issuecomment-40404725
.

[JeffBezanson]

If the point is that we should remove that syntax, then my reaction is quite different: I think it's very likely we should remove it.

[cmundi]

If I have a point, I think it's that it's useful to minimize surprises.
This particular syntax is surprising (to me) and I would favor a grammar
without it.

If we retain the perfectly reasonable type annotation syntax (yes) and we
want to retain the very convenient 'end' idiom (yes), then the only
non-onerous-to-users path I see offhand is to make 'end' special in all
contexts. Fully realized, this may (?) add excessive complexity to the
parser, and it does not get us any closer to what I see as the core issue,
which is whitespace.

As much as I dislike syntactic whitespace, at least the consequences in
python are deliberate and...afaik...not surprising. Some effects of
whitespace in Julia seem (to me) to be surprising, inessential side-effects
of partial Matlab compatibility. It's a valid trade but not one I am really
comfortable with.

But if I'm told (and I guess I have been) that "whitespace has meaning in
Julia and here are the rules" then clearly I'll play along.

Thanks for indulging discussion which probably belongs on the mailing list,
although I do think we're still on topic.
On Apr 14, 2014 2:37 PM, "Jeff Bezanson" notifications@github.com wrote:

If the point is that we should remove that syntax, then my reaction is
quite different: I think it's very likely we should remove it.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/6491#issuecomment-40421468
.

[nalimilan]

I don't think end is special at all. There's the same issue with e.g. x[3 -1] vs x[3 - 1]. This kind of expression is relatively common, when you replace 3 with a variable or a function call.

[JeffBezanson]

also #6405

[tonyhffong]

Just got burned by this today myself. a[1:end] and a[1 :end] are different. I have added to Lint.jl to catch that.

[jakebolewski]

Closing as I feel like this issue addressed under the umbrella of #7941. See also #8599.