Fork me on GitHub
#meander
<
2022-01-28
>
Richie01:01:10

@ben.sless Here’s something for inspiration. Hopefully you can take it from here.

(require '[juxt.pull.core :refer [pull]])
(pull {:x
       [{:y
         [{:z
           [{:w ["a" "b"]}
            {:w ["c" "d"]}]}
          {:z
           [{:w ["e" "f"]}
            {:w ["g" "h"]}]}]}
        {:y
         [{:z
           [{:w ["A" "B"]}
            {:w ["C" "D"]}]}
          {:z
           [{:w ["E" "F"]}
            {:w ["G" "H"]}]}]}]}
      [{:x [{:y [{:z [:temp]}]}]}]
      {:shadow {:temp println}})
prints
{:w [a b]}
{:w [c d]}
{:w [e f]}
{:w [g h]}
{:w [A B]}
{:w [C D]}
{:w [E F]}
{:w [G H]}
{:w [a b]}
{:w [c d]}
{:w [e f]}
{:w [g h]}
{:w [A B]}
{:w [C D]}
{:w [E F]}
{:w [G H]}
and returns
{:x [{:y
      [{:z [{:temp nil} {:temp nil}]}
       {:z [{:temp nil} {:temp nil}]}]}
     {:y
      [{:z [{:temp nil} {:temp nil}]}
       {:z [{:temp nil} {:temp nil}]}]}]}
The problem that I faced is that the api doesn’t let me calculate the new value in place. I’m calculating the value that should fill in that location using the data at that location but it gets inserted unter a new key. i.e. :temp “You can define attributes (values) not exists but calculated by the value of the map, they are shadow attributes:” https://github.com/juxt/pull

Richie01:01:14

I started my journey http://edn-query-language.org/ but I had trouble finding a library that did what I wanted.

Richie15:01:19

I also tried using m/$ with ?context but the ?context had everything and I didn’t know how to get just the path… I think that was the issue.

Ben Sless16:01:08

I figured out both solutions eventually but the grouping had to be cut explicitly because star is greedy

Ben Sless16:01:15

Turned out pretty ugly

Richie16:01:20

I don’t think I understand. Are you talking about the solution with ..n! because … is greedy?

Richie16:01:06

Eh, interesting problem anyway. Lmk if you find anything elegant.

noprompt19:01:24

I've mentioned it before but, yeah, ... is broken on the RHS because it is greedy. It should be frugal as it is on the LHS. This will be "fixed" in the distant future.

noprompt19:01:55

In general, what is on epsilon and prior is, IMO, "wrong" since it does not have distinct operators for greediness/frugalness e.g. * and *? etc.

noprompt19:01:23

The zeta branch does make the distinction and there are tests that demonstrate how it works. The zeta branch was never able to get off the ground though because I had some struggles with the compiler and organization.

noprompt19:01:53

Hopefully Ben and I can make something happen before too long. 🙂

Richie19:01:16

Please let me know if you make tickets or have a meetup. I’m content atm trying to learn what’s already there but I don’t want to miss out if you start moving forward with zeta development.

Richie19:01:26

I’m trying to learn how to make webapps with reagent. I’ve been learning datascript and reading about graph databases…

noprompt19:01:39

Hmm... I wonder if we could make a recurring meeting or something.

noprompt19:01:23

Cool, cool. All good stuff to learn. 🙂

noprompt19:01:21

As a proud heretic in this "community" I'd also recommend learning how type inference works and a bit about type theory at some point in your journey.

Richie19:01:34

I came from Scala.

noprompt19:01:40

Ah, cool. 🙂

noprompt19:01:51

I come from everywhere. 🙂

Richie19:01:08

I was eyeing haskell for a while.

noprompt19:01:28

Too many good ideas out there to be a "$language programmer".

noprompt20:01:03

TBH I'd use Haskell more if it weren't for the whitespace sensitive syntax and lame non-whitespace sensitive syntax.

noprompt20:01:44

I actually used Haskell to inform how zeta and beyond should work. The combination of data and class helped guide me a lot. I can't understate that.

Richie20:01:27

I implied I know about type inference works but I don’t really. Category Theory for Programmers and Seven Sketches in Compositionality have been on my reading list for too long. I’ve not made much progress.

noprompt20:01:33

There's a paper out there by SPJ that teaches how to make a mini version of the HM style type checker in Haskell with code examples. I can't remember the title but was very helpful.

noprompt20:01:08

I think CT is interesting but I've gotten more out of AA (Abstract Algebra) and ST (Set Theory) than CT.

Richie20:01:21

I am now obsessed with https://github.com/abo-abo/lispy style editing and I don’t know how I’d get it without parenthesis.

noprompt20:01:45

The cool thing about learning CT, AA, and ST is that many ideas are portable across languages.

noprompt20:01:52

Monoid always comes to mind.

noprompt20:01:00

Because, you know, they're everywhere.

Richie20:01:08

Yea. I’ll recognize that “I’m sequencing” and realize I have a monad. I appreciate having a language for it.

Richie20:01:31

I know what spj and ct are short for but I can’t think what aa or st mean.

noprompt20:01:54

I also love things like Monoid means "I can divided and conquer".

noprompt20:01:19

> AA (Abstract Algebra) and ST (Set Theory)

noprompt20:01:26

My brain might just be biased to those since I learned them first and pick up some CT stuff later

Ben Sless21:01:34

A nice and concise example is someone wrote a HM inferencer over malli schemas

👍 1
Ben Sless21:01:17

Are you a heretic? Is meander a pattern matching library? 😉

noprompt22:01:06

Hehehe, I don't think I am a heretic. 😄 I subscribe to ideas that I think are good, like type inference, pattern matching, etc.

Ben Sless05:01:35

Type inference is cool, programming with types maybe less so, i.e. I want to know when I messed up with types but let me keep my open dynamic collections. Clj kondo just added map key type inference which is exciting and useful. Wrt pattern matching I can see where it falls apart (expression problem), can still be a very useful and powerful tool

noprompt17:01:29

My take on this is, of course, logic. I think types are awesome, I think dynamic typing is awesome, and I think there is a middle ground that says you can have the best of both worlds. I think that middle ground is terms, rules, patterns. I think it is possible to write programs which are type safe but "feel" dynamic. IMO the expression problem exists when types and functions are coupled to each other such that there is a behavior associated with misapplication e.g. type error at compile time/run time. I think rewrite rules are much better here because they aren't "applied to", "called on", or "sent messages to". The work strictly with data and only "fire" when the left recognizes the input. There's no need to blow up, like, at all.