i-tu / Hasklig

Hasklig - a code font with monospaced ligatures
SIL Open Font License 1.1
5.56k stars 156 forks source link

λ to indicate anonymous functions #124

Open ShalokShalom opened 3 years ago

ShalokShalom commented 3 years ago

\ is meant to indicate a λ

I know this is a little bit of a stretch since it is one character, that is converted into a ligature and not two.

But I think it is worth thinking about this since it makes the language prettier and it makes the symbol more clear in its intention.

Thanks a lot to consider this ☺

anka-213 commented 3 years ago

Might be difficult, since \ can occur in other places as well and those probably shouldn't be rendered as λ, but I'm not super familiar with how fonts like these works, so maybe it's doable.

ShalokShalom commented 3 years ago

Where does \ appear on its own without an additional character and does not mean an anonymous function?

anka-213 commented 3 years ago

Mainly in strings. I don't know if that would count as "on its own", but this is an anonymous function

\n ->  n + 1

and this is a newline

"\n -> n + 1"

and I don't know if it is possible for a font to differentiate between these cases? Maybe we just ignore that case and make a ligature out of backslash followed by whitespace?

ivanopagano commented 3 years ago

and I don't know if it is possible for a font to differentiate between these cases? Maybe we just ignore that case and make a ligature out of backslash followed by whitespace?

Sorry to jump in, but wouldn't it be incorrect? Lambdas' definitions will usually follow the \ with the variable name, right?

anka-213 commented 3 years ago

Yes, most of the time people won't have a whitespace between \ and the variable name, so it would cripple the feature significantly. But it is the only way I can think of to differentiate between lambdas and string escapes without knowing more context. But maybe I'm overthinking this.

ivanopagano commented 3 years ago

Yes, most of the time people won't have a whitespace between \ and the variable name, so it would cripple the feature significantly. But it is the only way I can think of to differentiate between lambdas and string escapes without knowing more context. But maybe I'm overthinking this.

No, I think your worries are reasonably founded.

ShalokShalom commented 3 years ago

Well, the language can differentiate between strings and operators, while idk what Haskling can do.

Is it possible to make an exception for \n? Is this enough, covers it all edge cases?

That would only disallow the anonymous function with the variable name n, all other cases could be covered.

ShalokShalom commented 3 years ago

I would like to add, that /n for a varible name that comes after a lambda, would be confusing.

\n kinda indicates a newline, if within a string or not, so this is a bit 'bad style' and is advised to be avoided anyway.

So if we can avoid \n for that reason, is there anything else that could be considered?

anka-213 commented 3 years ago

I would like to add, that /n for a varible name that comes after a lambda, would be confusing.

\n kinda indicates a newline, if within a string or not, so this is kinda bad style.

No, I disagree. n is a common variable name, regardless of if it is used in a lambda or not. Furthermore, we would have to disqualify any name starting with n as well and that is starting to get ridiculous.

So if we can avoid \n for that reason, is there anything else that could be considered?

Yes, \t, \x1234, \r, \ and probably a few more I have forgot about.

I am starting to think that, unless the font can render differently in strings and outside strings, the easiest way to implement this is to simply accept that escape codes in strings get rendered as lambdas, despite it being kind of wrong.

ShalokShalom commented 3 years ago

Yeah, I would fully agree on that

ShalokShalom commented 3 years ago

I did a little bit of research, and according to Tonksy, who is the developer of the contextual alternative code, which is used in Hasklig, is this possible to differentiate between comments and functions via the syntax highlighting.

https://github.com/tonsky/FiraCode/issues/1207#issuecomment-790748580

So you can turn ligatures off in comments, which is sensical anyway, in my opinion.

anka-213 commented 3 years ago

(and in strings)

Sweet!

ShalokShalom commented 3 years ago

So can we do this now? :smile: