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

[CN] Allow ' in numeric constants #337

Open
yav opened this issue Jun 20, 2024 · 8 comments
Open

[CN] Allow ' in numeric constants #337

yav opened this issue Jun 20, 2024 · 8 comments
Assignees
Labels
cn enhancement New feature or request

Comments

@yav
Copy link
Collaborator

yav commented Jun 20, 2024

It'd be nice to allow _ in numeric constants, so you can write things like -2147483648_i32 or 0x_FFFF_FFFF.

If we do this, it would also be nice to update the pretty printers to add _ before the type suffix of constants (e.g., 0_i32 instead of 0i32).

@yav yav added enhancement New feature or request cn labels Jun 20, 2024
@bcpierce00
Copy link
Collaborator

bcpierce00 commented Jun 20, 2024 via email

@dc-mak
Copy link
Contributor

dc-mak commented Jun 24, 2024

Unfortunately, to match C23 and C++, the separator must be '.

@dc-mak dc-mak changed the title [CN] Allow _ in numeric constants [CN] Allow ' in numeric constants Jun 24, 2024
@dc-mak dc-mak changed the title [CN] Allow ' in numeric constants [CN] Allow ~~_~~ in numeric constants Jun 24, 2024
@dc-mak dc-mak changed the title [CN] Allow ~~_~~ in numeric constants [CN] Allow ' in numeric constants Jun 24, 2024
@septract
Copy link
Collaborator

Addressed in #379, but I used _ as originally proposed

@dc-mak why would this have to be '? The syntax only appears inside magic comments, which are not specified by C23 / C++, surely?

@dc-mak
Copy link
Contributor

dc-mak commented Jul 11, 2024

For consistency between the spec and C and code re-use in the lexer (e.g. also handling hex, binary and octal). This feature is being handled in the ongoing C/CN parser split.

@dc-mak
Copy link
Contributor

dc-mak commented Jul 11, 2024

This will be shipped as part of: #342
However, if the feature is urgent we can consider separate PRs.
(Sorry @septract for not updating the project board and the time spent).

@yav
Copy link
Collaborator Author

yav commented Jul 11, 2024

@dc-mak having to write 0i32 is already different from C though, is that changing?

@thatplguy
Copy link
Collaborator

FWIW I agree with @dc-mak – we should try to follow C conventions and standards where possible, even in magic comments, unless there's a reason not to. Thanks @dc-mak for adding this in the parser refactor.

@dc-mak
Copy link
Contributor

dc-mak commented Jul 15, 2024

0i32 is a limitation of the term language type system and can be overcome with a bit of engineering. It was more a pragmatic work-around to keep moving when we transitioned from integers to bit vectors rather than a design choice.

yav added a commit that referenced this issue Aug 7, 2024
* This changes the `atomic` boolean parameter to a `prec` integer
  parameter specifying the precedence of the surrounding context.

* We also change how some things are printed:
  - a lot fewer parens, based on precedence
  - suffix of numeric literals is separated by `'` (see also #337)
  - pointers are printed in base 16
  - use `NULL` instead of `null` to match CN's input notation
  - custom printing for negated comparisons `x != y` instead of `!(x == y)`
  - use `%` instead of `rem`
  - use `^` instead of `xor_uf`
  - use `&` instead of `bw_and_uf`
  - use `|` instead of `bw_or_uf`
  - use `<<` instead of `shift_left`
  - use `>>` instead of `shift_right`
  - use `{ ...s, x = e }` for updating things.  This is borrowed
    from JavaScript but it makes the precedence story simpler.
  - use `&p->x` instead of `member_shift<T>(p,x)`
  - use `&p[x]` instead of `array_shift<T>(p,x)`
  - use `cons(x,xs)` instead of `x :: xs`
@yav yav mentioned this issue Aug 7, 2024
yav added a commit that referenced this issue Aug 8, 2024
* This changes the `atomic` boolean parameter to a `prec` integer
  parameter specifying the precedence of the surrounding context.

* We also change how some things are printed:
  - a lot fewer parens, based on precedence
  - suffix of numeric literals is separated by `'` (see also #337)
  - pointers are printed in base 16
  - use `NULL` instead of `null` to match CN's input notation
  - custom printing for negated comparisons `x != y` instead of `!(x == y)`
  - use `%` instead of `rem`
  - use `^` instead of `xor_uf`
  - use `&` instead of `bw_and_uf`
  - use `|` instead of `bw_or_uf`
  - use `<<` instead of `shift_left`
  - use `>>` instead of `shift_right`
  - use `{ ...s, x = e }` for updating things.  This is borrowed
    from JavaScript but it makes the precedence story simpler.
  - use `&p->x` instead of `member_shift<T>(p,x)`
  - use `&p[x]` instead of `array_shift<T>(p,x)`
  - use `cons(x,xs)` instead of `x :: xs`
cp526 pushed a commit that referenced this issue Aug 8, 2024
* This changes the `atomic` boolean parameter to a `prec` integer
  parameter specifying the precedence of the surrounding context.

* We also change how some things are printed:
  - a lot fewer parens, based on precedence
  - suffix of numeric literals is separated by `'` (see also #337)
  - pointers are printed in base 16
  - use `NULL` instead of `null` to match CN's input notation
  - custom printing for negated comparisons `x != y` instead of `!(x == y)`
  - use `%` instead of `rem`
  - use `^` instead of `xor_uf`
  - use `&` instead of `bw_and_uf`
  - use `|` instead of `bw_or_uf`
  - use `<<` instead of `shift_left`
  - use `>>` instead of `shift_right`
  - use `{ ...s, x = e }` for updating things.  This is borrowed
    from JavaScript but it makes the precedence story simpler.
  - use `&p->x` instead of `member_shift<T>(p,x)`
  - use `&p[x]` instead of `array_shift<T>(p,x)`
  - use `cons(x,xs)` instead of `x :: xs`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cn enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

6 participants