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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

(parser) Support underscores in integer literals #221

Merged
merged 1 commit into from
Oct 13, 2021

Conversation

perlun
Copy link
Collaborator

@perlun perlun commented Oct 13, 2021

This is really "syntactic sugar" at its finest. No sensible person could claim that this is a required language feature, but it sure is nice to have stuff like this when you need it (perhaps especially when working with many integer literals).

(Btw, the PR probably supports underscore in floating-point literals as well, I haven't tried. 馃榿)

@perlun perlun added enhancement New feature or request language Language features (or bugs) labels Oct 13, 2021
@perlun perlun added this to the 0.1.0 milestone Oct 13, 2021
@perlun perlun enabled auto-merge (squash) October 13, 2021 17:53
@perlun perlun merged commit e35d7b5 into master Oct 13, 2021
@perlun perlun deleted the feature/support-underscore-in-integer-literals branch October 13, 2021 17:54
@perlun
Copy link
Collaborator Author

perlun commented Nov 5, 2021

(Btw, the PR probably supports underscore in floating-point literals as well, I haven't tried. grin)

Interestingly enough, no - it fails (just like before?).

Perlang Interactive REPL Console (0.1.0-dev.179, built from git commit 90bd9da)
> 123.45
123.45
> 123.45_67
[line 1] Error at '_67': Expect ';' after expression.

This one is even worse. Will check with the commit right before to see if it's the same there or if this is a regression introduced by this PR.

> 123_45.67
Unhandled exception: System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation.
 ---> System.FormatException: Input string was not in a correct format.
   at System.Number.ThrowOverflowOrFormatException(ParsingStatus status, TypeCode type)
   at System.Double.Parse(String s)
   at Perlang.Parser.Scanner.Number() in /home/per/git/perlang/src/Perlang.Parser/Scanner.cs:line 356
   at Perlang.Parser.Scanner.ScanToken() in /home/per/git/perlang/src/Perlang.Parser/Scanner.cs:line 273
   at Perlang.Parser.Scanner.ScanTokens() in /home/per/git/perlang/src/Perlang.Parser/Scanner.cs:line 152
   at Perlang.Interpreter.PerlangInterpreter.ScanAndParse(String source, ScanErrorHandler scanErrorHandler, ParseErrorHandler parseErrorHandler) in /home/per/git/perlang/src/Perlang.Interpreter/PerlangInterpreter.cs:line 413
   at Perlang.Interpreter.PerlangInterpreter.Eval(String source, ScanErrorHandler scanErrorHandler, ParseErrorHandler parseErrorHandler, NameResolutionErrorHandler nameResolutionErrorHandler, ValidationErrorHandler typeValidationErrorHandler, ValidationErrorHandler immutabilityValidationErrorHandler, CompilerWarningHandler compilerWarningHandler) in /home/per/git/perlang/src/Perlang.Interpreter/PerlangInterpreter.cs:line 175
   at Perlang.ConsoleApp.Program.Run(String source, CompilerWarningHandler compilerWarningHandler) in /home/per/git/perlang/src/Perlang.ConsoleApp/Program.cs:line 352
   at Perlang.ConsoleApp.Program.RunPrompt() in /home/per/git/perlang/src/Perlang.ConsoleApp/Program.cs:line 346
   at Perlang.ConsoleApp.Program.<>c__DisplayClass9_0.<MainWithCustomConsole>b__3(ParseResult parseResult, IConsole console) in /home/per/git/perlang/src/Perlang.ConsoleApp/Program.cs:line 180
   --- End of inner exception stack trace ---
   at System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor, Boolean wrapExceptions)
   at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
   at System.Delegate.DynamicInvokeImpl(Object[] args)
   at System.Delegate.DynamicInvoke(Object[] args)
   at System.CommandLine.Invocation.ModelBindingCommandHandler.InvokeAsync(InvocationContext context)
   at System.CommandLine.Invocation.InvocationPipeline.<>c__DisplayClass4_0.<<BuildInvocationChain>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass23_0.<<UseParseErrorReporting>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass16_0.<<UseHelp>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass25_0.<<UseTypoCorrections>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c.<<UseSuggestDirective>b__24_0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass22_0.<<UseParseDirective>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass11_0.<<UseDebugDirective>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c.<<RegisterWithDotnetSuggest>b__10_0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass14_0.<<UseExceptionHandler>b__0>d.MoveNext()

@perlun
Copy link
Collaborator Author

perlun commented Nov 5, 2021

This one is even worse. Will check with the commit right before to see if it's the same there or if this is a regression introduced by this PR.

Confirmed - it worked correctly (no System.FormatException) in 80c0bf5:

Perlang Interactive REPL Console (0.1.0-dev.177, built from git commit 80c0bf5)
> 123.45_67
[line 1] Error at '_67': Expect ';' after expression.
> 123_45.67
[line 1] Error at '_45': Expect ';' after expression.

I'll see if I can at least get rid of the exception. In the best of worlds, we should probably support underscores in floating-point literals as well.

@perlun
Copy link
Collaborator Author

perlun commented Nov 5, 2021

I'll see if I can at least get rid of the exception. In the best of worlds, we should probably support underscores in floating-point literals as well.

Fixed in #222.

perlun added a commit that referenced this pull request Nov 5, 2021
Similar to #221, but for floating point values.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request language Language features (or bugs)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant