This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-03-07
Channels
- # announcements (20)
- # babashka (25)
- # beginners (48)
- # biff (26)
- # calva (5)
- # cider (3)
- # clara (7)
- # clerk (7)
- # clj-kondo (61)
- # cljdoc (3)
- # clojure (6)
- # clojure-austin (1)
- # clojure-conj (8)
- # clojure-europe (58)
- # clojure-nl (1)
- # clojure-norway (4)
- # clojure-poland (1)
- # clojure-uk (9)
- # cursive (2)
- # emacs (11)
- # fulcro (8)
- # graphql (14)
- # gratitude (6)
- # humbleui (10)
- # hyperfiddle (17)
- # integrant (15)
- # introduce-yourself (1)
- # leiningen (5)
- # malli (13)
- # meander (21)
- # nbb (11)
- # off-topic (15)
- # pedestal (15)
- # polylith (15)
- # quil (28)
- # rdf (2)
- # reitit (3)
- # releases (6)
- # sci (21)
- # shadow-cljs (38)
- # spacemacs (3)
- # xtdb (6)
Is the zeta
branch a potential replacement of the main one? Or does it fulfill different goals/use cases than what epsilon
does today?
Not quite. Its been a work in progress on and off for a couple years. I’ve been a bit quiet about it because I’ve been trying to pin down a specific set of ideas in the cleanest way possible. zeta
has been parked for a bit because I got to a point where I realized I the axioms I was starting with were lacking.
Since the last commit to that branch, I have spent more time experimenting, both in code and on paper, and have been working on a project that I hope I can build zeta
on top of.
One of the things that has been nagging me for years is that, up until recently, I didn’t have a set of small step interpretation rules for the underlying semantics of Meander. Those semantics belong to a language I have named “two” which is a non monotonic logic language.
The main things I want zeta
to have are
• disjunction/conjunction on the RHS,
• projection operator (being able to generate and query data without necessarily altering bindings, this is makes let
work on both the LHS and the RHS),
• mechanism for building new operators using only the rewriting language (but also with Clojure functions),
• mechanism for defining new types of variables with rule systems (or Clojure functions) which define how to initialize a variable, update its state, and dispense values from it;
• string pattern matching,
• committed choice (`or` that picks the first solution),
• a uniform interface for search DFS, BFS, DFF, etc.
• any operator that exists on the LHS should have a cooperator on the RHS,
• isolated, non-lexical scope.
Currently, most of these things do exist on zeta
but the implementation is unsatisfactory which I why I went back to the drawing board months ago.
In December, I realized the underlying problem was that the language did not separate the flow control from the patterns. The patterns and
, or
, and let
(`project`) are syntactic sugar; they can be decomposed. Once I separated these, I was able to shrink the size of the implementation.
The controls maps cleanly to the logic monad and almost all of the pattern implementations that exist on zeta
have been captured by two simple abstractions: a function for constructing data, a cofunction for generating a search space. Even better, I almost have a complete operational semantics for this language.
That’s where I am.
And, yeah, I’m sorry everyone that this is how things have been for the past couple years but this just the way it is. I don’t know who said it but it wouldn’t be called research if I knew what the hell I was doing. My goal for this project has always been to get to a practical language for manipulating data without functions using pattern matching and substitution. With AI getting better each year, I sort of believe that, eventually, the time I have invested in this endeavor will be of little value to anyone. Still, I want to finish what I started and get to the next plateau because, for me, I’m not sure if there will be another one.
> it wouldn’t be called research if I knew what the hell I was doing :rolling_on_the_floor_laughing:
It’s a testimony to the usefulness of meander that epsilon has such staying power.
> With AI getting better each year, I sort of believe that, eventually, the time I have invested in this endeavor will be of little value to anyone. Still, I want to finish what I started and get to the next plateau because, for me, I’m not sure if there will be another one. Here, I think I completely disagree with you. I believe that AI is going to need simple languages that both humans and AI can understand. I have yet to see any serious (read revenue generating) AI project where a human doesn’t ask, “how did it arrive at that answer?”
This is exploration, not research And I doubt AI will ever be able to fill that niche
> I need to discuss science vs. engineering. Put glibly: In science if you know what you are doing you should not be doing it. in engineering if you do not know what you are doing you should not be doing it. > Richard Hamming, The Art of Doing Science and Engineering @U06MDAPTP I think this is the reference you're looking for
And personally speaking, I'd much rather have a pattern matching/rewriting language with precise denotational semantics that I can apply in a compositional way than a chatbot I recite incantations to until it "looks right" when processing some data
compositionality is exactly where LLMs fail the hardest (because they're not built for it), so focusing on it is likely to yield benefits for some time to come
@UFTRLDZEW Denotational semantics is not my strong suit but I think going from operational to denotational should probably be straight forward. I’d probably want to look at the denotational semantics for Prolog and borrow from that since the operational definition I have for Two is very similar to the operational definition of mini-Prolog.
What I am slightly stuck on is the function/cofunction algebra. There’s overlap with Hopf algebras and Groupoids but this is not quite it that because the function maps a tuple to a value (though it could be a singleton set) and the cofunction maps a value to a set of tuples. So set union is
(s, s) -> s
and the counion is
s -> { (s1, s2) | s1 ⊆ s, s2 ⊆ s, s1 ⊎ s2 }
So there’s a kind of symmetry here but I’m not exactly sure where to plug it in.Calling this a “counion” doesn’t feel right because its not a “co” kinda thing as commonly seen. But I don’t know what else to call it.
@UK0810AQ2 Yeah, something like that. This is in Coalgebra territory. You have some function (called “multiplication”)
(a, a) -> a
and another function (call “comultiplication”)
a -> (a, a)
So, for example, if the multiplication is integer product, the comultiplication would be the coproduct, or integer factor pair. If change the definitions to use a functor F
F (a, a) -> F a
F a -> F (a, a)
then, yeah, I think this works out better. If F
is a list and (a, a)
are arguments, when I fmap
the multiplication operation I get F a
, a list of products. If I think fmap
the comultiplication operation I would get F (a, a)
, the list of factor pairs.@UK0810AQ2 Here’s an example using into
.
;; F (a, a) -> a
(fmap into [[1] [2]])
;; => [[1 2]]
;; F a -> F (a, a)
(cointo [[1 2]])
;; => [[[] [1 2]], [[1] [2]], [[1 2] []]]
In practice, I just use into
without the functor, so just the (a, a) -> a
and same for the cointo
, a -> F (a, a)
.So cointo
just gives you all of the ways to construct the vector [1 2]
via the arguments [] [1 2]
, [1] [2]
, etc.
The idea can be extended to other data types as well and for operations that take more than two arguments. So assoc
could be all the ways to construct a map via assoc
provided the map has at least one entry. This represents the pattern
(assoc ?m ?k ?v)
But suppose I know the value and have
(assoc ?m ?k "bar")
then I can also imagine a coassoc-v
function which returns a sequence of possible ?m
and ?k
pairs that associate ?k
with the value "bar"
in the map ?m
.Random comment from a long time lurker but just wanted to mention that one of the qualities I admire the most in any project leader is the ability (and resolve) to take a step back and reevaluate fundamental choices, despite sunk costs, for the sake of simplicity and better alignment with the real goals in mind. Meander is very cool, but the journey even more so. Good luck to wherever you're heading, and know that everything so far has been very helpful to many!
Not quite. Its been a work in progress on and off for a couple years. I’ve been a bit quiet about it because I’ve been trying to pin down a specific set of ideas in the cleanest way possible. zeta
has been parked for a bit because I got to a point where I realized I the axioms I was starting with were lacking.
Since the last commit to that branch, I have spent more time experimenting, both in code and on paper, and have been working on a project that I hope I can build zeta
on top of.
One of the things that has been nagging me for years is that, up until recently, I didn’t have a set of small step interpretation rules for the underlying semantics of Meander. Those semantics belong to a language I have named “two” which is a non monotonic logic language.
The main things I want zeta
to have are
• disjunction/conjunction on the RHS,
• projection operator (being able to generate and query data without necessarily altering bindings, this is makes let
work on both the LHS and the RHS),
• mechanism for building new operators using only the rewriting language (but also with Clojure functions),
• mechanism for defining new types of variables with rule systems (or Clojure functions) which define how to initialize a variable, update its state, and dispense values from it;
• string pattern matching,
• committed choice (`or` that picks the first solution),
• a uniform interface for search DFS, BFS, DFF, etc.
• any operator that exists on the LHS should have a cooperator on the RHS,
• isolated, non-lexical scope.
Currently, most of these things do exist on zeta
but the implementation is unsatisfactory which I why I went back to the drawing board months ago.
In December, I realized the underlying problem was that the language did not separate the flow control from the patterns. The patterns and
, or
, and let
(`project`) are syntactic sugar; they can be decomposed. Once I separated these, I was able to shrink the size of the implementation.
The controls maps cleanly to the logic monad and almost all of the pattern implementations that exist on zeta
have been captured by two simple abstractions: a function for constructing data, a cofunction for generating a search space. Even better, I almost have a complete operational semantics for this language.
That’s where I am.
And, yeah, I’m sorry everyone that this is how things have been for the past couple years but this just the way it is. I don’t know who said it but it wouldn’t be called research if I knew what the hell I was doing. My goal for this project has always been to get to a practical language for manipulating data without functions using pattern matching and substitution. With AI getting better each year, I sort of believe that, eventually, the time I have invested in this endeavor will be of little value to anyone. Still, I want to finish what I started and get to the next plateau because, for me, I’m not sure if there will be another one.
Random comment from a long time lurker but just wanted to mention that one of the qualities I admire the most in any project leader is the ability (and resolve) to take a step back and reevaluate fundamental choices, despite sunk costs, for the sake of simplicity and better alignment with the real goals in mind. Meander is very cool, but the journey even more so. Good luck to wherever you're heading, and know that everything so far has been very helpful to many!