You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This came from point! design discussion: can we on top of literal (1, 2, 3) syntax also support expressions, like (x, y, z), as in the original geometry point notation that we copied?
Currently point can only be constructed as make point2D! reduce [x y] or as-point2D x y (similarly for 3D). This sometimes becomes quite verbose, turning reader's attention on the means rather than on the goal (syntactic noise problem).
We could make comma an operator that can by default:
accept two numbers (x1 + x2, y) and produce a point2D!
accept pair! or point2D! and a number ( (x1 + x2, y), z) <=> (x1 + x2, y, z) and produce a point3D!
accept triple! or point3D! and a number and produce a point4D! (4D is reserved for the future for now as we don't have enough space in the cell for it in our 32-bit runtime)
This will allow one to write expressions like (x, y, z) which will be lexed as paren! with 5 word!s: (x , y , z), comma being a word! that lexer must unstick from other tokens (x,y not a single word but three). Parentheses are not required of course: point: x,y,z would work the same, but in more complex expressions, like s + (x,y,z) / 2 they still make sense and add readability.
Consider: compose [offset: (0,0,0) size: (x,y,z)]. (0,0,0) is lexed as a point3D! literal value, but (x,y,z) as a a paren! which gets evaluated by compose itself.
Another usage for comma would be dialects, maybe to separate items in lists e.g. [1 2, 3 4, 5 6] or words in sentences lorem ipsum, dolor, sit amet.
Points against it are:
comma doesn't look like something that evaluates, so it may make the code confusing to the reader
point! syntax already collides with paren! syntax, and (x,y,z) expression vs (1,2,3) literal value only adds to the confusion
So the main question here is whether the readability benefit will overweight the risks of abuse, or vice versa.
The text was updated successfully, but these errors were encountered:
This came from
point!
design discussion: can we on top of literal(1, 2, 3)
syntax also support expressions, like(x, y, z)
, as in the original geometry point notation that we copied?Currently point can only be constructed as
make point2D! reduce [x y]
oras-point2D x y
(similarly for 3D). This sometimes becomes quite verbose, turning reader's attention on the means rather than on the goal (syntactic noise problem).We could make comma an operator that can by default:
(x1 + x2, y)
and produce apoint2D!
pair!
orpoint2D!
and a number( (x1 + x2, y), z) <=> (x1 + x2, y, z)
and produce apoint3D!
triple!
orpoint3D!
and a number and produce apoint4D!
(4D is reserved for the future for now as we don't have enough space in the cell for it in our 32-bit runtime)This will allow one to write expressions like
(x, y, z)
which will be lexed asparen!
with 5word!
s:(x , y , z)
, comma being aword!
that lexer must unstick from other tokens (x,y
not a single word but three). Parentheses are not required of course:point: x,y,z
would work the same, but in more complex expressions, likes + (x,y,z) / 2
they still make sense and add readability.Consider:
compose [offset: (0,0,0) size: (x,y,z)]
.(0,0,0)
is lexed as apoint3D!
literal value, but(x,y,z)
as a aparen!
which gets evaluated bycompose
itself.Another usage for comma would be dialects, maybe to separate items in lists e.g.
[1 2, 3 4, 5 6]
or words in sentenceslorem ipsum, dolor, sit amet
.Points against it are:
point!
syntax already collides withparen!
syntax, and(x,y,z)
expression vs(1,2,3)
literal value only adds to the confusionSo the main question here is whether the readability benefit will overweight the risks of abuse, or vice versa.
The text was updated successfully, but these errors were encountered: