Morrn. Jag tycker iof att prefix är lättare att läsa. Infix är komplext p.g.a. operatorprecedens.... så det där makrot kommer nog inte funka i allmänhet?

Håller med. För mig är det just när man ska jämföra två tal i en komplext uttryck som jag råkar tänka fel. Så fort man vill se ordningen på flera så (< 2 5 4) så är det naturligt. Operatorprecedens slipper vi med ett enkelt språk. 🙂

Du kan ju testa det här libbet: https://github.com/rm-hull/infix

Nah. Ska man implementera formler så att lekman förstår, så .. Min fråga var mer, behöver ni också tänka till när ni ser < ?

Nope

Som fan! Någon gav mig rådet att bara hålla mig till den ena av <och >. Men jag har inte följt det, så jag kan inte säga om det funkar (minns inte ens vilken av dem som föreslogs 😄). Men jag tänker till ordentligt, och blir allt bättre på att få det rätt.

Hmm. Jag tänker, vi testar ordningen. (< 1 2 3) men på bara två värden, för att få det rätt. Kanske göra ett alias (growing? 1 2 3) för att tänka rätt istället för att skapa ännu mer kaos med infix.

Så istället för less than, måste jag tänka om till growing?

Jag tänker om till growing. Men ett alias för det skulle inte hjälpa mig. Jag tittar på symbolen och ritar ut förlängningen av den i huvudet. Ett alias skulle inte vara lika effektivt. Mitt problem, som jag analyserat det, är min infixa träning.

Visst. Problemet ligger väl mycket i context switchandet mellan prefix och infix. Vissa symboler har fastnat i den infixa världen, som mattematiska symboler. Jämförelse i storlek är lite mer komplext än t.ex. likhet, = , så vi snurrar väl till det lite och gör misstag på < ibland. Jag har råkat göra tvärt om, när jag hjälpte min yngsta med matteläxor, och försökt förklara med prefix notation.

Jag tror att jag mentalt sätter in operatören efter varje siffra så att det blir som infix i huvudet.

(> 4 3 2 1) =>
(4 > 3 > 2 > 1)

😄 Vi har underbara sätt att tänka

Det viktigaste svaret är att hamra i REPLN tills det funkar 🙂

Anledningen till att jag tog upp frågan var i det här fallet att jag läste kod och tänkte fel. Jag blev inte klok på mitt egna resonemang, och snodde snabbt ihop, och använde detta gamla infix macrot för att jag skulle kunna känna mig trygg i vad jag läste. Därefter kom funderingen. Blir det tryggare för andra om jag har kvar infixad jämförelse? Naturligtvis slutade det med en lite kraftigare refaktorering som gjorde koden lättare att förstå. Men, eftersom infix-tricket hjälpte mig i mitt resonemang, så är det kanske ett vedertaget trick som folk använder. Över lag är prefix att föredra för mig, i all sin enkelhet, med ibland saknar jag det fria valet som i Haskell, t.ex.

... och det är väl inte andra tillfällen än < > <= >= jag har känt behovet 🙂

Det är kanske något som editorn skulle kunna hjälpa till med? Typ om man hovrar över en form med < så visas uttrycket i infix i hovern… Eller nåt.

Jag håller med om att just större än och mindre än (och tillhörande likamed-operatorer) är de operatorer som kräver att man tänker till. Jag tror jag skriver om i huvudet när det är två argument. Övriga operatorer föredrar jag infix.

Det skulle nog bara underlätta när man har två parametrar till < >.

Så man har inte problemet när man läser saker som (< 1 x 3), menar du? Det kanske stämmer, jag har inte tänkt på det.

(`s/föredrar jag infix/föredrar jag prefix/` såklart i mitt svar ovan. 😄)

Man kanske har problemet med flera parametrar, men det försvinner nog när det är skrivet i en enkel form som (< 1 x 3). Det blir svårare när varje element är ett längre uttryck, och man behöver hålla fler saker aktuella i resonemanget. Men (1 < x 3) hjälper heller inte särskilt mycket. Kanske @U6T7M9DBRs tankegång med operator mellan varje parameter. Vackert med förmodligen bara förvirrande Ha en riktigt trevlig helg på er

Jag tycker inte det är förvirrande med 1 < x < 3. Det blir tydligt, 1 är mindre än x om är mindre än 3 och jag kan lätt översätta det till x ligger mellan 1 och 3. Men det är lika lätt med att se med prefix-notationen. Men, visst, för (< 1 x) är det kanske mer hjälp med att få se att jag råkat skriva 1 < x och testar att x är större än 1. Hmmm, kanske att jag börjar förstå det där rådet med att hålla mig till bara en av dem bättre nu…

Ja, 1 < x < 3 är inte förvirrande i sig. Det är bara det att koden inte ser ut så, alls. Jag tror den "automatiska översättningen" är förvirrande, även om den skulle visas i någon slags popup fönster eller liknande. Men varför inte. Du kanske får till det snabbt 🙂

Men du råkar väl snabbt ut för det där med operatorprecedens...

När man sedan börjar med <= så sprängs huvudet

> [x] > [x y] > [x y & more] > Returns non-nil if nums are in monotonically non-decreasing order, > otherwise false. Glasklart ju. 😃 Undrar när man behöver arity 1 och mer än 2… OK, jag kan nog se situationer när men vill kolla saker som [1 1 1 1 2 3 4 4 4 5 5], men (<= -1), vad ska man med det till? Ärligt nyfiken för jag fattar ju att Rich Hickey inte bara råkat stödja det.

Vilken kod man än tittar i, tittat man riktigt djupt så hittar man John McCarthy stirra tillbaka på en.

(apply < xs) Jag tycker även [] borde vara en arity

... eller kanske inte. Kanske finns anledning till att inte stödja [] faktiskt

Ja det är definitivt by design. Jag tror det är för att få uniformitet. Jämför med andra operatorer som + . Med 0 argument så får du "identitet" i din domän (0 är identitet för +), liknande så får du 1 med *. Om funktionen < betyder "är strikt monoton", så måste den ju hantera aritet 1, som alltid är en monoton sekvens. Borde ju hantera aritet 0 också, kan inte komma på varför det inte är med.

Vad är identiteten av <?

För mig blir det konstigt med arity 0 på <. Kanske är det false, men varför. Det borde inte vara true heller eftersom vi inte jämför något över huvud taget. ett element är i ordning med ingenting. Det är ok

https://ask.clojure.org/index.php/12441/should-clojure-core-have-a-zero-arity

Vad är det för skillnad mellan en fisk?

Kunde inte låta bli att undra samma sak på ask-tråden. 😃

Det är en val

@U0D1EU0EL Jag tänkte spontant att det borde vara sant, eftersom man kan implementera list-versionen som (defn lt [xs] (->> xs (partition 2 1) (every? #(apply < %)))). every? är sann om listan är tom, eftersom true är identiteten för and. Vänder man på det så får man att lt skall vara falsk om det finns något par där det vänstra inte är mindre än det högra. Är listan tom så finns det inte något sådant par, d.v.s. då är det sant. För mig blir det lättare att tänka på sådant här om man tänker lite mer abstrakt i termer av "forall" och "exists" (https://en.wikipedia.org/wiki/Universal_quantification#Negation).

Jag håller nog med. Allt i en tom samling är lika mycket ordnat som en samling med ett element, och allt i samlingen är lika, lika mycket som vid ett element.