Fork me on GitHub

@alexandrkozyrev A debate we are having internally is about how hyperfiddle eval currently returns Either Left(compiler error) or Right(result). We considered it might be nicer if we just returned an (ex-info) or the result. The problem is, coders might never see an ex-info in their testing, and thus write code that crashes in production because it assumed an ex-info never happened. Lifting everything into wrapper types forces the call site to handle the error


I'm pretty sure I'd see those ex-info at least a few dozen times while coding. 😄 ...I suppose you're rethinking this a bit because of Rich's keynote...


We are trying to find a worldview in which Rich is right! Haven't found it yet!


Wow! I'm surprised by this. I loved Haskell's Maybe/Eithers until Rich said those things that he said. I was forced to recognize that C#/Kotlin's type system is better on that front, obviously.


We agree with the attribute centric worldview


however, we have a function eval-str, would he like us to wrap the result in a map so we can name the result with an attribute?


Not to put too much pressure on you, but I hope you'll write up your thoughts somewhere - I'd love to be exposed to your arguments, and not just me, but the public too.


Or perhaps he would like us to use metadata (a great idea!) but ........ to use metadata you need to wrap the result in a container


E.g. here – note the value is wrapped in :Error key


Wrapping the return value of eval-str into {:Error x} is no better than wrapping it in a Left


Well, actually, maybe it is, i have not fully considered it until now


His main goal is : whatever you do, if you change your API, do not break your existing clients. I think it's good to keep that in mind. Since you're already starting with a strict set of return value possibilities, you might be fine wrapping them in whatever (Either, or Map).


IMHO, That is not the use case that people use Either for. He has cherry picked the wrong use case


We are using Either to force the call site to write robust code that accounts for the possibility of error


Yeah and he was more speaking about Maybe than about Either (although I've always struggled a bit remembering which one is which one)


Your imposing an Either wrapper on us is no big deal, especially since we could write a macro that handles our error handling if we wanted.


it's not even imposed on userland, it's an internal API, but we suffer a great deal of pain writing funcool/cats everywhere in our internals that deals with Either types, and Rich's series of lectures on this subject have not demonstrated to me at least that he understands the problem we're trying to solve


We want badly to see a better way, it really hurts us having to deal with container types from clojure


ok - I think I'll write past your real concerns, then - I think I don't have enough knowledge and experience to help you find a better way - I risk only repeating what Rich said, without really understanding your needs. 🙂


What would be perfect is, putting metadata on nil. That way we get clojure's nil punning philosophy (monadic short circuiting on errors with nice syntax) while also having the ability to collect the error messages and report them


But clojure understandably does not support metadata on host primitives


haha, which would require a wrapper container on top of null, due to Java not being a truly OO system. 😄


...ok so you really require some kind of wrapper. Now you've got a very concrete and specific one: Either. I could see some argument where switching to a flexible wrapper (a map) might give you something.


Yeah, interestingly cljs/eval i think returns a map


Not sure if you'd need the "something", though.


The next thing we'd need to do is implement mlet, either/branch, fmap etc on the container type, which seems straightforward enough


but you'd be in a parallel world instead of perusing the standard fonctions - I suppose you're already quite a lot in such a world with your usage of cats.


typeclass polymorphism isn't really something we need (e.g. having mlet work on arbitrary monad) – we can hardcode the utility lib


that's what's annoying with custom types - they invade everything that must be redesigned to accommodate


Now that I've reached my potential usefulness limit, I suggest you start a new thread to signify that new feedback might be welcome!


on r/clojure ?


hmmm yes this would give a wider perspective


@U0514DPR7 we had “a vs [a]” discussion with Dustin, the essence is: why is it ok to accept dumb functions, functions that can’t wrap/unwrap input values


take Rich’s example: x -> y changed to x -> Maybe y and existing callers - break


in real life if someone gives a scissors you don’t really care about package (if any), you care about cutting


much better notation (for callers) is something like: y <- whatever x


I do care about “y” so much that I will reap-off whatever apart to get “x”


can’t get rid of the thought that Rich was talking (Maybe Not) about poor cousins of Datomic - schema and select


and that Clojure/Datomic is a kind of false separation


Just deployed changes to the links datamodel. • link/rel has been removed, use link/class for that now • * The following have been removed: hf/affix hf/detach hf/self hf/rel * Remaining link/class choices are: is hf/new, hf/remove, hf/iframe * link/class is now optional, we infer the correct semantics from context, only new/remove/iframe require additional specification


* link/path is no longer a path, but rather the ident of an attribute. So if you put a link at :neighborhood/district, it will appear for any :district at any depth in the pull


* fiddle/renderers can now much more easily name a link. Instead of requiring you to name links by :link/class you can now also name them by :fiddle/ident, :link/path (attribute), and also by :link/tx-fn (to name a button)


Data mode no longer automatically merges in extra links, it just uses your fiddle links, we have big plans for data mode in the future that are, dare I say it, compatible with REBL?


TLDR: Links are way way simpler, much more is inferred from namespace keywords than before


does it mean that the hypermedia model gets down to 3-4 concepts instead of 7?


Hahaha I deferred learning those 7 a few months ago, you almost made my day hahaha


* link/formula is scheduled for removal, direction is don't use it (We aren't ready to hide it from UI yet)


* txfn hacks have been cleaned up, e.g. this txfn is now clean:!counter/#:hf.src!ns


looks much more clear