gluon icon indicating copy to clipboard operation
gluon copied to clipboard

Unicode type-level infix operators

Open toastal opened this issue 6 years ago • 5 comments

Namely type-level operators and for forall and -> respectively--and maybe subjectively others outside of type-level like for :: and for <<.

(==): : forall a . [std.prelude.Eq a] -> a -> a -> std.types.Bool

becomes

(==): : ∀ a . [std.prelude.Eq a] → a → a → std.types.Bool

toastal avatar Jun 04 '19 11:06 toastal

Not a fan of using unicode symbols, it just becomes a hassle to write them. Granted, I have never looked into how to make it possible but just the fact that it is something one needs to look up is a pretty big problem.

Having it as an alternative syntax might make some sense but I personally rather stick to one way of doing things. Encountering code written by somebody using unicode when you aren't using it becomes a barrier to entry so I rather avoid that.

It seems more plausible that an editor can translate -> etc to unicode characters on the fly while still keeping ascii symbols in the source code.

Marwes avatar Jun 04 '19 12:06 Marwes

Is it possible to create your own type-level infixes? The others can be made with an alternative prelude

I'm actually pretty used to either depend on project (small preference for unicode via ctrl+k in n/vim), but Agda uses it heavily, PureScript supports many out of the box for type-level, and so can Haskell via the unicode language extension. If both ASCII and unicode supported, I don't see why there'd be a collision.

-------- Original Message -------- On Jun 4, 2019, 19:16, Markus Westerlind wrote:

Not a fan of using unicode symbols, it just becomes a hassle to write them. Granted, I have never looked into how to make it possible but just the fact that it is something one needs to look up is a pretty big problem.

Having it as an alternative syntax might make some sense but I personally rather stick to one way of doing things. Encountering code written by somebody using unicode when you aren't using it becomes a barrier to entry so I rather avoid that.

It seems more plausible that an editor can translate -> etc to unicode characters on the fly while still keeping ascii symbols in the source code.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

toastal avatar Jun 04 '19 12:06 toastal

Is it possible to create your own type-level infixes?

No, never really thought about it before since I never felt a need. I don't really object to adding infix types, however for me it has rather low priority. Could be nice to have :: as a constructor for List for pattern matching on it. It could at least be a function for constructing lists now but it seems I forgot to add it to std https://gluon-lang.org/doc/crates_io/std/std/list.html .

For unicode operators specifically they would need to be added to the lexers list of valid operator characters. Since unicode is already allowed in identifiers I suppose it just consistent to allow them in operators as well 🤔 .

: is a keyword operator however (I guess -> is as well, in lambdas \x -> x and match alternatives) so any unicode alternative would need an explicit blessing to work which makes me a bit more skeptical than plain unicode operators but I don't know how rational that is.

Marwes avatar Jun 04 '19 12:06 Marwes

I don't see why there'd be a collision.

It is not about a collision.

If I want to contribute to a library which uses unicode symbols and I am not used to that then that is a barrier to entry. With that drawback I am a bit skeptical to embracing unicode.

Marwes avatar Jun 04 '19 12:06 Marwes