Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

syntax confusion: 1.+2 #19089

Closed
StefanKarpinski opened this issue Oct 24, 2016 · 12 comments
Closed

syntax confusion: 1.+2 #19089

StefanKarpinski opened this issue Oct 24, 2016 · 12 comments
Assignees
Labels
parser Language parsing and surface syntax
Milestone

Comments

@StefanKarpinski
Copy link
Member

This sort of confusion keeps cropping up: https://groups.google.com/forum/#!topic/julia-users/aycsd2iAktE. Two possibilities seem possible:

  • Eliminate 1. as a short syntax for 1.0;
  • Allow 1. but make ambiguous cases like 1.+2 a syntax error.

Related: #18714 – in that it also relates to making potentially ambiguous cases errors.

@StefanKarpinski StefanKarpinski added the parser Language parsing and surface syntax label Oct 24, 2016
@StefanKarpinski StefanKarpinski added this to the 0.6.0 milestone Oct 24, 2016
@ararslan
Copy link
Member

+1 for eliminating 1.. That change might be mildly annoying for some people, but it's much clearer to write floating point literals as 1.0 anyway.

The second point, allowing 1. but making 1.+2 a syntax error, seems like more trouble than it's worth.

@tknopp
Copy link
Contributor

tknopp commented Oct 25, 2016

given that . is extensively used in Julia I would also vote for eliminating 1.
Making it a syntax error adds new special cases to the parser, which increases the complexity of a (potential) Julia grammar.

@JeffBezanson
Copy link
Member

Disallowing 1. seems too strict to me. Many languages allow that syntax, and getting rid of it because of a corner case seems like throwing out the baby with the bathwater. The problems with 1.+2 (either as it is now, or if we add a special case error for it) are much rarer and less significant than the use of 1. as a literal.

@carlobaldassi
Copy link
Member

I agree with Jeff even though I personally dislike 1., as I'm sure a lot of people would be very annoyed by not being able to write it/having to change their code. Simply disallowing ambiguous cases should be enough I believe.

@StefanKarpinski
Copy link
Member Author

At this point everyone seems to agree that 1.+2 should be a warning, so let's agree to that. For what it's worth, Ruby doesn't seem to allow 1. as a syntax – probably because the language allows calling methods on integers. C, C++, Python and Perl allow 1.. I'm not sure what R does since I don't have it installed.

@JeffBezanson
Copy link
Member

JeffBezanson commented Oct 25, 2016

R accepts it, as do octave/matlab, bc, and most lisps/schemes. The syntax is nearly universal.

@mauro3
Copy link
Contributor

mauro3 commented Oct 25, 2016

Whilst we're at it, are there any problems with omitting the leading zero: .1 which should be taken care of too?

@StefanKarpinski
Copy link
Member Author

There seem to be a lot fewer issues with that syntax.

@StefanKarpinski StefanKarpinski added the help wanted Indicates that a maintainer wants help on an issue or pull request label Oct 27, 2016
@StefanKarpinski
Copy link
Member Author

For 0.6 this should be made a deprecation warning or an error, but this change is pretty minor and low impact, so I'm leaving this as up for grabs in case someone wants to do it.

@StefanKarpinski StefanKarpinski modified the milestones: 1.0, 0.6.0 Oct 27, 2016
@akaysh
Copy link
Contributor

akaysh commented Dec 1, 2016

Hi @StefanKarpinski ,
I am a beginner, can I work on this issue?
Please help me how to get started.
Thanks

@yuyichao yuyichao removed the help wanted Indicates that a maintainer wants help on an issue or pull request label Dec 1, 2016
@StefanKarpinski
Copy link
Member Author

@akaysh: anyone who wants to can work on it (no need to ask permission), but I suspect this is not a particularly easy issue. It requires some deep hacking on Julia's parser, which is written in Scheme. But if you think that sounds doable, you're welcome to give it a shot.

@Sacha0
Copy link
Member

Sacha0 commented Feb 14, 2017

are there any problems with omitting the leading zero: .1 should be taken care of too?

There seem to be a lot fewer issues with that syntax.

(Perhaps due to dot-ops presently having the dot on the left rather than right?)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
parser Language parsing and surface syntax
Projects
None yet
Development

No branches or pull requests

9 participants