Primitive types and built-in functions aren't part of the grammar #1

Closed
opened 2024-07-05 18:36:11 +02:00 by aykevl · 2 comments
aykevl commented 2024-07-05 18:36:11 +02:00 (Migrated from github.com)

I'm trying to port the Chroma tango theme to CodeMirror and I'm hitting a small issue that results in a difference in look: built in functions and types don't seem to be treated in a special way.

Specifically, it would be nice to treat the following types as t.standard(t.typeName): uint, uint8, uint16, uint32, uint64, int, int8, int16, int32, int64, float, float32, float64, complex64, complex128, byte, rune, string, bool, error, uintptr.

And the following as built-in functions (perhaps using t.standard(t.function(t.name))): print, println, panic, recover, close, complex, real, imag, len, cap, append, copy, delete, new, make, clear, min, max.

(I might try to make a PR but I'm not very familiar with the JavaScript ecosystem so I'm not sure how to test such a change).

I'm trying to port the Chroma tango theme to CodeMirror and I'm hitting a small issue that results in a difference in look: built in functions and types don't seem to be treated in a special way. Specifically, it would be nice to treat the following types as `t.standard(t.typeName)`: `uint`, `uint8`, `uint16`, `uint32`, `uint64`, `int`, `int8`, `int16`, `int32`, `int64`, `float`, `float32`, `float64`, `complex64`, `complex128`, `byte`, `rune`, `string`, `bool`, `error`, `uintptr`. And the following as built-in functions (perhaps using `t.standard(t.function(t.name))`): `print`, `println`, `panic`, `recover`, `close`, `complex`, `real`, `imag`, `len`, `cap`, `append`, `copy`, `delete`, `new`, `make`, `clear`, `min`, `max`. (I might try to make a PR but I'm not very familiar with the JavaScript ecosystem so I'm not sure how to test such a change).
marijnh commented 2024-07-05 19:20:54 +02:00 (Migrated from github.com)

Go, like many languages, allows shadowing built-in variable names, so it is not possible to reliably recognize these on a syntactic level. As such, Lezer chooses not to try and treat them specially.

The same seems to go for types—you can define types with those names in your own programs.

Go, like many languages, allows shadowing built-in variable names, so it is not possible to reliably recognize these on a syntactic level. As such, Lezer chooses not to try and treat them specially. The same seems to go for types—you can define types with those names in your own programs.
aykevl commented 2024-07-06 16:00:42 +02:00 (Migrated from github.com)

I see, so it's an intentional design choice. In any case, thank you for the response!

(For those wondering, the tango theme I made is here: https://github.com/tinygo-org/playground/blob/main/editor/tango.js. It doesn't look exactly the same but it's pretty close.)

I see, so it's an intentional design choice. In any case, thank you for the response! (For those wondering, the tango theme I made is here: https://github.com/tinygo-org/playground/blob/main/editor/tango.js. It doesn't look exactly the same but it's pretty close.)
Sign in to join this conversation.
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
lezer/go#1
No description provided.