<mbj>
each 'key' of the nested hash root, gets pushed down to a value under the key expression.
<mbj>
key 'expression' ;)
<mbj>
snusnu: Its also handy for document databases
<mbj>
snusnu: So I'm not sure if that node should validate for hash children in the input
<mbj>
snusnu: Or if we should patch in a guard via the preprocessor
<snusnu>
mbj: the node looks good imo, i can see how it's useful for stuff like config etc
<snusnu>
mbj: what's the specific document database usecase you have in mind tho?
<snusnu>
is it related to wrap/group ?
<mbj>
snusnu: partially
<mbj>
snusnu: Its not wrap/group in the RA-sense
<snusnu>
yeah
<mbj>
snusnu: ES for example returns facet results in that format.
<snusnu>
btw, i stopped my spike for wrap/group, mainly because group would've been "a different beast", i mean, not really, but it'd operate on an array/set/relation .. and i ended up thinking that it might not be the right layer anyway
<snusnu>
i see
<mbj>
snusnu: What do you wanted to archieve?
<snusnu>
so re the validation for hash, imo morpher should yell at us if the input is no hash ..
<mbj>
snusnu: I think morpher should infer all type validations that are dependencies for transforms
<snusnu>
mbj: initially i wanted to avoid doing wrap/group in my relations because the don't get optimized currently
<snusnu>
i decided that i will just be strict myself in my current app, and maybe at some point find the time to implement proper optimization rules in axiom-optimizer
<mbj>
snusnu: so a hash_transform, would automatically add a (guard (primitive Hash)) etc.
<snusnu>
imo that's the right thing to do
<snusnu>
via preprocessor
<snusnu>
same for key_{push, pull}
<mbj>
snusnu: yeah
<mbj>
snusnu: Also we can have an optimizer that collapses type checks.
<mbj>
snusnu: They are *very* fast anyway.
<mbj>
snusnu: The type checks will happen just before the actual transform, so the memory locations are *hot* already.
<snusnu>
btw, recently i've been thinking more and more about some sort of "type system with constraints" built with morpher
<snusnu>
the idea being, that a type is expressed via a set of constraints, which themselves are morpher predicates
<snusnu>
the only thing is how to fit coercion in the mix
<snusnu>
the way i see it, a coercion is just another precondition that must be true
<snusnu>
so it's a transform op, that must not fail
<snusnu>
and after applying it, the type's actual constraints must hold
<mbj>
snusnu: You just described axiom-types ;)
<snusnu>
i had a discussion with solnic on gitter, where we talked about finding name for types (i prefer that), or passing options over and over, solnic (at least initially) preferred that
<snusnu>
i will NOT do that tho
<snusnu>
yeah but i don't really like axiom-types
<snusnu>
i want to be able to build types, have them in some registry, be able to access them by (symbol) name
<snusnu>
classes as well as instances seem confusing for this sort of thing
<snusnu>
i wanna freely define types, without having to introduce constants for them
<snusnu>
no inheritance, is_a?, whatever
<mbj>
snusnu: yeah
<snusnu>
take some unconstrainted type object, add constraints, register it somewhere under some name, access it by that name
<mbj>
snusnu: I build morpher with axiom-types in mind. I think we can replace axiom-types with morpher predicates if we wanted.
<snusnu>
that's basically what mom does now
<mbj>
yeah, I expected so.
<mbj>
And it makes sense, we could also "box" values.
<snusnu>
wdym?
<mbj>
So I dislike we are passing Strings that qualify to a certain regexp around: To represent an email address.
<mbj>
I think, for domain modelling we should have a box that takes a value and the predicate.
<mbj>
snusnu: But TBH, we are inventing another language.
<mbj>
snusnu: I get bored by ruby programming the more haskell I do.
<snusnu>
lol
<mbj>
snusnu: Mutant and my commercial stuff is the only thing that holds me back.
<snusnu>
it's still interesting to me fwiw, fusing functional, oop, type theory, RA concepts
<mbj>
Yeah, but around 80% of our code is about creating a type theory, functional suitable building blocks, ...
<mbj>
We are doing that work, IMO on the wrong abstraction level.
<mbj>
I do not want to *have* to write an adamantium!
<snusnu>
wrong is relative, in a language like ruby, it needs to be done if you wanna do it, switching to another language, is not comparable imo
<mbj>
mhh, you should try haskell.
<snusnu>
hah, re adamantium, i stopped using it
<mbj>
I'm implementing morpher on haskell is many times more easy.
<snusnu>
that doesn't surprise me
<mbj>
I still use it, as it caches bugs.
<snusnu>
dunno what you mean by that
<snusnu>
i found it unnecessary, i'm doing immutable by default anyway
<mbj>
Adamantium and the purely functional style it imposes => Caches bugs when someone suddennly begins to mutate.
<snusnu>
i dunno, for me, i guess it's not worth it (anymore) .. i always liked to setup my object state in #initialize, i very much rely on that, so i don't need #memoize that often, and with my little classes, i can easily grasp if i'm mutating or not
<snusnu>
all the freezing, seems useless oftentimes
<mbj>
snusnu: Depends if you need to integrate with 3rd level stuff that ruins your style, without knowing.
<mbj>
I need to integrate with rails, that happily mutantes around ;)
<snusnu>
poor you
<mbj>
so its best to mee to pass in frozen constructs
<snusnu>
yeah, that's a different arena
<snusnu>
i don't get near rails, at all
<snusnu>
never will
<snusnu>
(again)
<mbj>
snusnu: I said the same ;)
<snusnu>
i know lol
<snusnu>
but i'm keeping my promise :p
robert_ has joined #rom-rb
<mbj>
snusnu: I thought the same ;)
<snusnu>
mbj: btw, can morpher be changed to simplify these: v