This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-10-22
Channels
- # announcements (4)
- # babashka (1)
- # beginners (35)
- # biff (1)
- # calva (34)
- # clj-kondo (21)
- # clojure (38)
- # clojure-europe (49)
- # clojure-norway (8)
- # clojurescript (12)
- # emacs (21)
- # events (1)
- # fulcro (16)
- # joyride (1)
- # malli (1)
- # nbb (7)
- # observability (2)
- # pathom (4)
- # polylith (6)
- # reagent (4)
- # releases (1)
- # shadow-cljs (16)
- # squint (23)
- # tools-build (7)
hmmm I'm working on > and not sure how to wire a function up to that
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
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
maaaaaybe, probably won't be able to look for another 8 hours or so
I'd love to hear what your thoughts are on this @borkdude and @lilactown https://github.com/squint-cljs/squint/issues/63#issuecomment-1287644470
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)
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
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
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
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
the js spec explains sort here https://262.ecma-international.org/13.0/#sec-array.prototype.sort
and it converts values to strings in the default compare using this process https://262.ecma-international.org/13.0/#sec-tostring
for objects it uses toPrimitive if it can and falls back to toString
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
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