Clojurians Log v2

@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 https://twitter.com/dustingetz/status/1068513550753296384

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

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?

Yes

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)

lol

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