Clojurians Log v2

@noprompt My pleasure.

@noprompt, OK, I filed the issue about nil vs. (). I don’t seem to have a way to tag the issue with anything, so I think you’ll have to do that.

Got it

I merged the interpreter work. It’s light on the docs and on the tests. There are some things about CLJS that need to mentioning but it’s working and we can tweak that later.

Again, I would call this experimental.

There’s some sci symbol resolution that needs to be fixed to have this work in babashka but it works well enough.

Well, once that problem is fixed.

@droberts3 I’m going to merge your doc patch. It’s outstanding. Thank you for that.

@noprompt I'm currently refactoring some code in sci where I'm also hitting that code. So maybe I'll just fix it if you don't mind

@borkdude Ah, that would be great. Actually, I was planning on trying to make it a bit more declarative and surprise you but that might take longer than you just getting it done. 🙂

I’m looking forward to that because I think with bb and the direction the code is now going in, there’s going to be an opportunity to make some fun data shredding/querying stuff on the CLI.

bb also got a new feature last weekend to add deps directly in a script: https://book.babashka.org/#_add_deps so it will be very easy to try out meander with bb

@droberts3 I’ve extended an opportunity for you to work on branches connected to the main project, etc. Take advantage of it if it reduces friction in the contribution process for you. All that I ask is that you continue to open PRs and have them reviewed before pressing the merge button. 🙂

Kick ass!

Yeah, that’s really sweet.

@noprompt, OK. I’ll just continue to submit PRs unless I find a strong reason otherwise.

Heh, we’re gonna need to figure out how to make one of these cool new markdown books that seem to be en vogue these days.

The docs look pretty nice on clj-doc I gotta say.

I was actually going to suggest perhaps looking at adoc. It’s also supported by github and CIDER is using it.

I don’t know if clj-doc supports it.

It has some nicer support for doing examples

IIRC adoc came up previously. If clj-doc supports it and that is a better format then I’d be open to checking that out.

If not, I’d prefer we stick to what they support for now pending a script or something to roll into the build process.

Yep. I can take a look and we could trial a conversion of one of the docs to see how it looks. We could also convert incrementally.

There is a bin/build-release script and we can wire in that compilation to markdown if need be.

Ultimately adoc is a lot more powerful than Markdown.

Alrighty, yeah, have at it. 🙂

I suck at docs so this an area where I can use all the help I can get.

With the big asterisks “no pressure, family first, etc.” attached.

Cool. I’ll focus on content for now. I think the priority should be on the matching macros, patterns, and then substitutions. Once we have those well-documented, that will be huge.

I also want to pull over some of the ideas in some of @jimmy’s blogs. I was reading through those a couple days ago and there’s some really great content there. The Meander in Meander post was very thought-provoking.

Awesome. I’ll continue to loop folks here in on what is coming down the line. The most significant changes are going to come with local and project and dissolving the differences between the left and right sides such that any pattern can be used on either side.

I enjoyed that post too.

We’ll definitely be applying some of those techniques in zeta however. With the functional API established, we can use that internally for all sorts of things like parsing and compiling.

I really wanted to write zeta with epsilon but, yeah, it’s just not there yet, however, it does get really close.

Another thing is, I would like the ground floor to be inclusive of folks existing Clojure chops.

Yea, certainly.

We want to educate folks, not scare the crap out of them with the advanced class right out of the gate.

Starting at Meander and working up might having a chilling effect on folks looking to contribute.

Hahaha, yes. 🙂

But I think nothing would show the power of Meander than writing Meander in Meander. Not to mention the meta-recursion points you’d earn. 🙂

Here’s the parser: https://github.com/noprompt/meander/blob/zeta/dev/meander/dev/parse/zeta.clj#L59

And the match compiler: https://github.com/noprompt/meander/blob/zeta/dev/meander/dev/match/zeta.clj#L18

And operating those things: https://github.com/noprompt/meander/blob/zeta/dev/meander/dev/zeta.clj

This is informative stuff, it works, and it performs decently, but there are some developer creature comforts missing.

In previous discussions with @e749 a big issue with large systems like this is that you don’t have a good way of diagnosing what is happening.

However, this problem should mostly be solved now by the approach taken by factory code: building up a pattern factory and using dependency injection to pass in how it should operate at runtime.

You can pass a runtime that prints or collects information about rewriting/matching/etc.

Yea, deep macrology is always awesome. Right until it blows up. And then you’re wading through 10,000 lines of macroexpansion and wondering how expensive it is just to write it all from scratch.

True.

My hope though is that with explainability, composability, interpretability, compilability, and being able to mix and match those things both at runtime and compile time it’ll solve those problems.

The goal is to have something like spec style explainability and conform without the terrible performance.

Makes sense.

But also, I don’t want to necessarily need to use clojure.test.check either and have my specs and code be separted.

I should be able to define a pattern and use it aggressively at every level.

Now I’m just rambling.

I probably need to eat. 🙂

LOL

So, soon you’ll be able to say (yield <pattern> [bindings]) and have it spit out a stream of all the ways to construct pattern from those bindings.

Interesting. That would be cool.

I think 3 to 6 weeks from now depending on how much hacking I do during the upcoming winter break.

Meander is a weird love child of a term rewriting system, a logic programming language, and Lisp.

It is easy to find excuses to play games when you have a Geforce 3080 😛

Yes!

And that’s kind of where I want it. Term rewriting is awesome but many devs will start dropping packets the moment you start talking to them about it. Logic programming is also great but its hard to ignore that devs also have to invest a lot of their own time to learn new tricks, something that’s not always appealing without and obvious pot of gold on the other end. Lisp is close enough to “normal” programming that you can sneak devs in with stuff they know.

One thing we all understand is data literals.

just pushed the fix to sci and bb

Yes, agreed. See, I love all those “old” technologies. Everybody else has basically forgotten about them, but there are a ton of really, really useful ideas lurking in those old CS papers.

So how can we leverage the things that are easy to grok for everyone?

Yes, yes.

You’re the bomb @borkdude 🙂

Logic variables and data literals are easy to understand. Pattern matching is also pretty easy for people to pick up because it is often a subtle tweak on what they already know about those two things.

One reason I like Meander, I think, is that it doesn’t try to be more than it needs to be. For instance, I would probably hate to write a large program in nothing by Prolog. But I’d love a great logic engine embedded in Clojure that you can call out too (unfortunately, core.logic has too many limitations and seems almost abandoned at this point).

It’s funny you mention that.

Ditto with a term rewriting system.

I want to be “in Clojure” and be able to say, “Here’s a logic problem that I need solved. Solve it.” Or “Here’s a data structure I need rewritten. Rewrite it.”

Then, take the answer and slam it into Hiccup or whatever.

Maps alone, which arguably are the bread and butter structure of most Clojure programs, are just flat out annoying to work with in stock core logic. And that’s not say something bad about core logic; it’s just the case.

Yep.

Right. Stuff can be very blunt and very forward.

Which, arguably, you can see in Prolog and even Haskell or ML style language in the pattern matching oriented parts fo the language.

Well, and core.logic doesn’t have some good things that Prolog has (notably missing are things like findall, bagof and setof.

I think Mark Engelberg did a great job with his Rolling Stones library, wrapping sat4j up. I’ve used that as a nice way to incorporate a SAT solver.

I should check that out.

Yea, it’s nice. It’s all data driven, so, you could actually describe your problem in another data format and then use Meander to (help?) construct the SAT problem.

Ah, man, that sounds cool.

Then throw the SAT problem at Rolling Stones, which then translates it into Java objects for sat4j.

Interesting. Putting that on the todo list.

Dude, you have a GeForce 3080. Where are you going to find the time? 😛

Hahaha yeah.

But I’m paranoid all the time now.

I’m afraid somehow water is going to magically get poured on top of my case and ruin it.

And mostly because everything next-gen is sold out everywhere.

2020 in spades.

Yea, well, 2020 just needs to die right now. Here’s to 2021.

Cheers to that.

Seriously, things like TRS, Logic Programming, SAT, etc. are power tools. And today’s coders are worried about the latest Javascript framework. :face_with_rolling_eyes:

Yes. We need to have LP catch on the way FP has in recent times.

I’ve been thinking that I would be neat to take the direction Meander is going in, emphasizing the forward concepts with an LP slant, mix in some data flow and call it a prototype language.

But, in general, it would be nice to see more of LP catching on. I think it will.

Yea, agreed. One of the hardest parts is to (re)train yourself to think in those ways, however. Honestly, it’s like coming from imperative OOP to functional, but worse.