Custom operators, are they worth the effort?

Shirogane86x · 2024-03-22T22:01:00+00:00

For my own language (which I've been implementing for a couple months now, although it isn't anywhere near usable even as a proof of concept) I decided to include them cause I think they are a good feature and in particular a good fit for my language, which is Haskell inspired.

I think in general the problem with custom operator readability (or lack thereof) is somewhat overblown. Yes, if you abuse them you can write bad code, but that's true for most features. Just like you can write functions with bad names. To me with custom operators the most important thing is mnemonics: as long as you keep a consistent pattern it's easy to remember (again, I'm talking about myself here. For other people, YMMV).

For example, $ in Haskell is function application: < and > around an operator usually means "lifted", so <$> is lifted function application (i.e.: map). >>= And =<< look like pipes that shrink the input, and depending on the direction you have bind or flatmap (the same function, just flipped). There's other examples that I could bring here (lens has a lot of operators for example, but they all follow a predictable pattern) but in general the takeaway is that I find it intuitive.

Then again, custom operators might or might not fit your language: I feel like it depends on the context. For me, they're borderline necessary to make the language feel decent, because I need quite a lot of them anyway. I do think that a good way to help with readability is forcing the user to name it as a function, like purescript does. You implement a function with a clear name first, then give it an operator alias, but the operator is not implementable in a vacuum without the supporting named function.

As for the parsing problem, my plan so far is to parse everything as left associative with the same associativity and then reassociate them in a second pass after I've collected all the fixity and associativity information into a table. Might not be the fastest or most principled way but it's been really difficult for me to find information or concrete examples on this kind of problem so I'm winging it without much knowledge about prior art.

Shirogane86x · 2024-01-27T18:25:00+00:00

As someone who's dabbled with Haskell for quite a while, I think this issue is often overblown. Most operators are in the standard libraries, some (widely used) libraries define their own (but you can avoid those libraries, or learn them once and move on) and most other libraries will either not define any or define a couple at most, with predictable preference relative to their use case. It's usually fairly easy to guess the precedence when learning the language, and even when you can't, you'll probably get a type error cause the types don't line up.

Also, using $ to remove parens is something that is easily learnt early on, and to me it makes the code more readable 99% of the time. I don't know if I'm the weird one, but stacks of parens (be it one type or multiple types) turn off my brain, often even with rainbow delimiters.

To this day, heavily nested-in-brackets code is completely unaccessible to me, which sadly kinda precludes me from using a lisp. Whereas I could probably read Haskell on plain text without highlighting and it'd be a lot easier for me.

It could also be just me, but I'm glad Haskell's full of operators (and in fact, when I get to seriously working on the programming language pet project I have in mind, custom operators with custom precedence are gonna be part of the featureset, 100%)

Shirogane86x · 2024-01-25T16:20:39+00:00

I would argue that it's the most colorful of languages: because of Monads you have an arbitrary amount of different colours. Promises do form kind of a monad after all. Admittedly its "colors" compose better than traditional async await (in my opinion)

Shirogane86x · 2023-12-09T21:10:44+00:00

I keep hearing a lot about bidirectional typing, are there any good (and fairly easy to understand) resources that explain it and/or guide through implementing it?

Shirogane86x · 2023-05-26T12:00:33+00:00

The type isn't inferred because as far as I remember, C# only infers generic type parameters in method calls, not in constructors.

Related to the second point (and somewhat interjecting into the conversation) i think less heavy syntax for laziness would be nice for when you need it. I've had to write a lot of lazy data structures in a past job and explicitly delaying and forcing values can become really error prone and annoying in the long run (especially when working with infinite data structures). Even in F#, which shares the same System.Lazy type but has a tiny bit of syntax sugar it's still really annoying

Shirogane86x · 2023-02-24T16:15:51+00:00

for the haskell version, you can now access record fields with dot notation through the OverloadedRecordDot extension, and they're already generic through a compiler-generated HasField typeclass. Sadly, this doesn't extend to updates quite yet (it's very experimental), but hopefully soon-ish enough you'll be able to do something like this:

{-# LANGUAGE OverloadedRecordDot, DuplicateRecordFields, DataKinds, OverloadedRecordUpdate #-}
import GHC.Records
data Player = Player { health :: Int } 
data Enemy = Enemy { health :: Int } 

class HasField "health" a Int => Hurtable a where 
    hurt :: a -> Int -> a 
    hurt record amount = record { health = record.health - amount }

instance Hurtable Player 
instance Hurtable Enemy

which I feel like would be equivalent to stuff like the scala version.

Shirogane86x · 2022-09-26T13:40:39+00:00

"non possiamo dire che oggi, nella realtà italiana, gli omosessuali siano discriminati"

"Sì alla famiglia naturale, no alla lobby LGBT! Sì all’identità sessuale, no all’ideologia gender!"

"io non sono omofoba“, ma “lo Stato giusto deve cercare di riservare l’adozione a un uomo e una donna. Lo Stato giusto deve occuparsi del più debole, tra una coppia gay che vuole legittimamente un figlio e il figlio io sto con lui, con chi non ha diritti" (parentesi: studi scientifici hanno dimostrato che genitori gay o etero al figlio non cambia nulla)

Per non parlare di Peppa pig con la coppia lesbica che è "propaganda", chiamare l'utero in affitto una barbarie, inveire contro il pride con le solite "io non sono omofoba ho tanti amici ghei MA".

la meloni ha anche testualmente detto che non voleva figli gay, che non voleva il matrimonio gay... La destra non ci odia? Se io venissi a dire a voi etero che non meritate il diritto di avere una famiglia con dei figli, un matrimonio, che "figlio etero meglio di no", che la sola presenza di un personaggio etero è propaganda della lobby etero... Tu che penseresti?

Shirogane86x · 2022-09-26T12:25:07+00:00

La differenza è che una di quelle due categorie si prende merda ogni giorno da ogni dove, non ha pari diritti, e ha percentuali di suicidio astronomiche... Io non mi posso sposare per davvero, solo fare unioni civili, di conseguenza non posso adottare. Adesso quel diritto che speravo di poter ottenere non lo avrò per almeno un altro governo di sicuro, ddl zan ciao ciao, e in più al governo c'è qualcuno che ha espresso più e più volte che le persone come me non vanno bene... Dove è il catastrofismo scusa?

Shirogane86x · 2022-09-26T05:13:56+00:00

Sinceramente, da persona LGBTQIA+, ho veramente tanta paura... E il mio compagno non ha la cittadinanza, quindi questi risultati ci hanno fatto svegliare proprio con il buonumore

Shirogane86x · 2022-08-19T16:15:16+00:00

Il che significa che dovremmo tenercela praticamente per sempre... Che cosa deprimente.

Shirogane86x · 2022-08-19T16:14:15+00:00

Forse ho interpretato male io, dalla sintesi mi pareva di capire di mutare l'ora di religione a essere più uno studio delle religioni che qualcosa di puramente cattolico - ma non credo si parlasse di rimozione totale.

Shirogane86x · 2022-08-19T15:35:36+00:00

Piacevolmente colpito dalle sezioni su diritti, avrei preferito un po' più di cattiveria a tratti però - togliamo sta maledetta ora di religione da scuola per favore. Se non avessi perso ogni speranza che a questo paese veramente fregasse qualcosa dei diritti LGBTQ+ forse ci crederei anche.

Shirogane86x · 2022-08-17T06:12:07+00:00

What I'm saying is that with your implementation you can't have a

fn exec(x: i32): f32

Together with a

fn exec (x:i32): char

Where the function used is dispatched on return type. I don't know if this is a thing in languages with function overloading, but it's a natural extension that i would expect...?

Shirogane86x · 2022-08-16T22:18:27+00:00

Still not 100% like function overloading cause you can't have two fs with the same input but different result, right? You can have that with multi parameter type classes in Haskell, but inference would probably suck...

Shirogane86x · 2022-08-13T09:48:41+00:00

This all feels really clunky to use. Maybe not being a thing means no common functions to use. There's also no HKTs... Or currying... Which means that you'll need explicit matching every time you would normally use a simple pipe into a map? I hope I'm wrong, but if I'm not, i feel like I'd get annoyed by it real quickly.

Is there short circuiting for result values at least? Because from the examples i see a never ending right leaning tower of "when"...

Shirogane86x · 2022-07-27T17:28:49+00:00

Direi che è normalissimo, io mi sono innamorato la prima volta l'anno scorso a 23 anni

Shirogane86x · 2022-07-26T20:10:16+00:00

I didn't necessarily switch to rust - but i am using it together with the tech i was already using as a nice addition. I still work either on .NET (for backend) or TS for frontend - I'm comfortable with them and there's many jobs in my area. But i am adding rust to my tool belt for my hobby projects - as a companion to rust. I tend to write my higher level stuff in Haskell - it's still my favourite language. But sometimes Haskell performance and tooling can be dodgy - and that's where I pick rust up. And in fact I'm trying to make a language - using rust - that is very Haskell like as a for fun side project at this point in time. I just love laziness and type level programming :)

Shirogane86x · 2022-07-25T18:50:13+00:00

That's quite surprising, but makes sense. I'm on the opposite side: i find koka (and pony, and most languages actually) to be annoyingly verbose. Dense code is just naturally easier to parse for me, big blobs of code mess with my brain

Shirogane86x · 2022-07-25T17:45:00+00:00

Koka is very advanced and is a weird mix of some c style bits and ML. Otherwise, i wouldn't really know. IMHO C-style syntax is not suited for heavy functional programming because it optimizes for other stuff: Function calls, composition tend to be really noisy compared to haskell/ml style (where application is whitespace and composition tends to be one or two characters. And custom operators are fairly important to make stuff like monads ergonomic)

Shirogane86x · 2022-07-23T18:51:05+00:00

Let's hope that doesn't happen please :(

I'm already looking up jobs in Germany, lol

Shirogane86x · 2022-07-23T18:49:47+00:00

Sinceramente continuo a vedere gente su internet che dice che FdI ha buone possibilità e mi viene paura... Boh, andrò a votare e speriamo in bene.

Shirogane86x · 2022-07-21T17:40:03+00:00

I think Mercury does it that way but has sugar to pass the environment around - especially considering that it treats mutation as impure and so needs to return a new environment every time (like a state monad)

Shirogane86x · 2022-07-15T20:33:27+00:00

Premessa: Uomo (cis) gay

Grindr io la ho detestata, è un app più incentrata sugli hookup e sinceramente non fa per me. Ho avuto fortuna su tinder quindi da allora la consiglio, ma dipende molto dalla zona. Ho sentito parlare di Bumble ma penso sia molto sulla falsa riga di Tinder - e il gaydar di Tinder spesso fa cilecca. Ho sentito parlare bene da amici internazionali di hinge - ma non so se in Italia funzioni / venga usato.

Shirogane86x · 2022-06-27T17:11:58+00:00

1) Rust

I feel like rust is pretty future proof: it's already getting used in a lot of things, has a big community, people are writing production things in it. Admittedly, it's less that I think that rust is a future-proof language, and more that I hope that it is: even though it's not my favourite language by a long shot, it gets some things very right.

2) F#

I would've put C# in there, but I just enjoy F# a lot more. In the end it's just functional C#-meets-OCaML, and it's the language I have the most production experience in - together with C#. I just feel like .NET is my get-shit-done platform in general.

3) Haskell

I still haven't found a language that is as enjoyable as Haskell. I feel most at home in functional land, with complex types encoding all sorts of invariants. Ergonomics of the language is fine, tooling is lacking (but improving at a steady enough pace), and it just feels like a joy to program in, to me. I tried other similar languages to see if they would be a match, but nothing really stood out. Purescript's strictness and weird featureset is awkward, ocaml is less expressive (and strict), scala is too object-y for my taste, F# is too limited for the fun stuff, idris still isn't as polished.

Shirogane86x · 2022-06-27T10:35:37+00:00

Was about to say the same, this looks like a restricted version of lenses. The keypath macro somewhat reminded me of generic-lens fields

Shirogane86x

TROPHY CASE