Fork me on GitHub
#hyperfiddle
<
2018-12-17
>
Dustin Getz18:12:46

@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

Daniel Jomphe19:12:08

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...

Dustin Getz19:12:49

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

Daniel Jomphe19:12:42

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.

Dustin Getz19:12:23

We agree with the attribute centric worldview

Dustin Getz19:12:14

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?

Daniel Jomphe19:12:28

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.

Dustin Getz19:12:28

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

Dustin Getz19:12:55

E.g. here – note the value is wrapped in :Error key https://twitter.com/dustingetz/status/1068513550753296384

Dustin Getz19:12:21

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

Dustin Getz19:12:00

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

Daniel Jomphe19:12:27

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).

Dustin Getz19:12:02

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

Dustin Getz19:12:34

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

Daniel Jomphe19:12:57

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

Daniel Jomphe19:12:59

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.

Dustin Getz19:12:57

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

Dustin Getz19:12:02

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

Daniel Jomphe19:12:34

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. 🙂

Dustin Getz19:12:42

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

Dustin Getz19:12:02

But clojure understandably does not support metadata on host primitives

Daniel Jomphe19:12:22

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

Daniel Jomphe19:12:55

...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.

Dustin Getz19:12:33

Yeah, interestingly cljs/eval i think returns a map

Daniel Jomphe19:12:40

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

Dustin Getz19:12:19

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

Daniel Jomphe19:12:26

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.

Dustin Getz19:12:07

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

Daniel Jomphe19:12:11

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

Daniel Jomphe19:12:04

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

Dustin Getz19:12:18

on r/clojure ?

Daniel Jomphe19:12:52

hmmm yes this would give a wider perspective

alexandrkozyrev15:12:56

@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

alexandrkozyrev15:12:23

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

alexandrkozyrev15:12:59

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

alexandrkozyrev15:12:41

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

alexandrkozyrev15:12:54

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

alexandrkozyrev20:12:03

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

alexandrkozyrev20:12:31

and that Clojure/Datomic is a kind of false separation

Dustin Getz20:12:46

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

Dustin Getz20:12:58

* 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

Dustin Getz20:12:02

* 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)

Dustin Getz20:12:23

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?

Dustin Getz21:12:07

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

Daniel Jomphe21:12:23

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

Daniel Jomphe21:12:50

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

Dustin Getz21:12:05

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

Dustin Getz21:12:51

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

alexandrkozyrev07:12:45

looks much more clear