Fork me on GitHub
Cora (she/her)04:10:25

hmmm I'm working on > and not sure how to wire a function up to that

Cora (she/her)04:10:49

the implementation is pretty straight-forward:

export function _GT_(x, ...xs) {
  let lastValue = x;

  for (const value of xs) {
    if (value >= lastValue) return false;
    lastValue = value;

  return true;


What is the problem with "wiring"? The > function already is inlined when you use it in function position, but indeed, not when passed as a higher order function

Cora (she/her)17:10:35

hmm it was returning a number last night when I was trying things. maybe I'm doing something wrong. I'll try again later today


maybe an old version?

Cora (she/her)18:10:53

maaaaaybe, probably won't be able to look for another 8 hours or so


Interesting idea


I don't know the "correct" answer yet. Following CLJS semantics could be interesting, but we also don't follow CLJS semantics for = on objects (since they are mutable, etc)


I think CLJS' compare behavior makes way more sense from an application standpoint


most comparisons are done on primitives. people use sort-by to take a complex data type (map, vector, etc) and map it to a primitive for sorting. I think CLJS' compare function is the behavior when comparing primitives


ICompare would be useful to extend this to types like dates


ok, let's do it then

Cora (she/her)17:10:58

agreed that cljs sort(by) makes way more sense. the default js sort is nearly useless for the common case (sorting numbers) without a custom compare function

Cora (she/her)17:10:33

about compare being for primitives, that's actually what js sort tries to do first, it looks for a Symbol.toPrimitive key on the object and uses that result to compare (falling back to toString). js sort breaks on sorting symbols, though, and it makes undefined higher than any other value (I'm pretty sure) which is the opposite of cljs compare w/ nil

Cora (she/her)17:10:58

it would be nice if our sort(by) didn't break on symbol by default... but also symbols are so rarely sorted and it's almost nonsensical to do that so maybe we can let ours still explode on them

👍 1
Cora (she/her)18:10:02

and it converts values to strings in the default compare using this process

Cora (she/her)18:10:03

for objects it uses toPrimitive if it can and falls back to toString

Cora (she/her)18:10:54

I'm fairly sure that that is the same process used by template literals to convert to string, hence my usage of them to convert values to string in the default compare fn in my comment

Cora (she/her)18:10:46

not super important since we're going the smart compare route but I thought I'd share since it's such a weird little bit of js that appears a ton of places and is otherwise hard to grok