-
Notifications
You must be signed in to change notification settings - Fork 153
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
Collection / Vector Literals #527
Comments
I like the idea of using prefixes for literals. Many other languages use different delimiters depending on the datatype (
Perhaps Another thought, currently the |
Ideally we would desugar during parsing. Or at the very least statically prior to typechecking. One issue with your proposed Alternative delimiters could be I agree that we could have the Koka already has some static determination prior to typechecking in terms of operator precedence, and allows you to create definitions such as Alternatively some languages use a dual brace system like: Thinking some more about the spreading syntax, we actually don't need spreading since we already have static overriding based on types so we could have The other issue is the order of operations. |
Is the aim to only support static (compile-time) literals, or support a more general form of collection expressions? I.e. supporting variables, so you can do |
I believe the above desugaring should support both. |
The main thing that I'm concerned with this proposal is making sure that we make sure we are open to map literals, as well as anonymous struct types (canonicalized of course to prevent code blowup) which is another hope of mine. |
It would be good to support vector literals and add special support to the backends to lower them directly to the runtime representation.
As far as syntax, I think directly prefixed literals would be good to support: (This is already supported for raw strings), and could be useful for other literal forms as well.
Then the idea would be to add the following definition
Which could allow other prefixed identifiers (even if they are not externs or specially compiled):
Unfortunately this clashes with index and assignment notation.
Are there other characters that could be used, or should it be distinguished by no local variable by that name, or what?
Additionally literal map notation would ideally be able to use the typical
0: ""
notation instead of tupled arguments.Not sure what the best design is. Just wanted to get a conversation started.
For a similar prefix idea for strings and string interpolation see #528
Alternatively for this we could use a similar desugaring as the string interpolation proposal: i.e. something like
This could then allow for 'spreading' of various collections into others.
Of course the preallocated 'size' parameter of the start function then becomes less useful when spreading unknown sized collections, but they could be computed.
The text was updated successfully, but these errors were encountered: