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

Postfix syntax for variants #637

Closed
chenglou opened this issue Jul 13, 2016 · 7 comments
Closed

Postfix syntax for variants #637

chenglou opened this issue Jul 13, 2016 · 7 comments
Labels
RFC For larger proposals/ideas that will need discussion

Comments

@chenglou
Copy link
Member

Most probably not gonna work out because of the sheer number of parsing conflicts it'll create. But I'm filing this anyway. The reason I'm wondering about this is for simulating units, e.g. 1Px, 50Percent, 1min, etc. They'll be desugared to e.g. Px 1 and you'd prevent accidental mis-addition of two incompatible units together.

@jordwalke
Copy link
Member

It actually wouldn't create many parsing conflicts I believe because these would in theory be extracted in the tokenizer. The question is just a matter of specifying which variants should be lexed/parsed/printed this way.

@yunxing
Copy link
Contributor

yunxing commented Jul 13, 2016

One trick I was thinking is to add an attribute to the node, annotating how it should be printed.

If we eventually have our own ocaml printer, we can just ignore that special attribute.

@jordwalke
Copy link
Member

Yeah, that would work. Is there any precedence for postfix sugar in other languages? tbph, the set of code that I'd want unit of measurement tracking are exactly the cases where I would not want to pay for the extra boxing of a variant tag.

@Schmavery
Copy link
Contributor

Hopefully wouldn't conflict with anything trying to use extension literals?

@jordwalke
Copy link
Member

@Schmavery : That's actually a good point - we can actually just use the extension literals to implement suffixes right? I would bet there already examples of doing so.

@saschatimme
Copy link

This would be really neat for a CSS solution like elm-css!

@cullophid
Copy link

I just starter working on https://github.com/SentiaAnalytics/bs-css.
This would be majs it much nicer

@jaredly jaredly added the RFC For larger proposals/ideas that will need discussion label Jun 14, 2018
@anmonteiro anmonteiro closed this as not planned Won't fix, can't repro, duplicate, stale Jul 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
RFC For larger proposals/ideas that will need discussion
Projects
None yet
Development

No branches or pull requests

8 participants