freenode/lisp - IRC Chatlog
Search
20:34:26
rpg
It's a great idea, but I don't see any information about how to configure the Python process, and the docs are quite limited.
21:15:48
aeth
"trivial-left-pad — Ports the functionality of the very popular left-pad from npm. — MIT"
21:25:14
aeth
I mean, really, it goes full circle when someone ports that to Parenscript because it's more functional than the actual left-pad
21:26:26
aeth
no-defun-allowed: unfortunately, I can't just remove it from Quicklisp without warning once half of Quicklisp indirectly depends on it and instantly break everyone's code
21:28:33
aeth
It really does seem like a dead joke 3 years later. And in a few years, no one will get the joke.
21:32:51
aeth
It's a 3 years old April Fools project that got almost no attention on April Fools 3 years ago.
21:38:28
aeth
In 2017, I did a functional Brainfuck for April Fools, which I think is more useful than trivial-left-pad. I didn't do any jokes for 2018 or 2019 because I think the Internet has kind of killed April Fools Day in general. I didn't even go on the web at all last April 1st.
23:35:10
rpg
Does anyone know if there's a library that would do pattern-matching or unification specifically for hash-tables or property lists? I.e., structures with named components?
23:35:40
rpg
This does not seem like rocket science, but it seems like something someone might well have done before.
23:47:33
rpg
Bike: I imagine it could, yes. I'd like unification better than pattern matching, though, if I can get it.
23:48:26
rpg
cl-unification doesn't really do unification, because of its templates, so it's not a symmetrical operation like unification.
23:52:25
rpg
I'm really just looking for the ability to unify something that's like a hash-table, or a python dictionary...
23:53:17
rpg
that's a lot less demanding than trying to do unification for all of CL like CL-Unification.
23:58:45
White_Flame
yeah, it's not rocket science, but it is a bit more involved than matching positional lists/tuples, so it's a bit more rare
23:59:00
rpg
I think the trickiest bit is that one needs a path language for the results. E.g., if you unify a dictionary with no entry for :x with a dictionary that has an entry for :x which itself has an entry for :y, that is 'foo, then the resulting binding set must have a way of representing the path :x -> :y -> 'foo
0:00:55
White_Flame
the only difference with standard unification is that you need to do a set union+difference of the keys of the 2 hashtables
0:02:06
aeth
For those who want to follow along at home. https://en.wikipedia.org/wiki/Unification_(computer_science) https://gitlab.common-lisp.net/cl-unification/cl-unification
0:04:16
White_Flame
oh, and variable keys would need multiple results: unify {?:3 . ?} with {a:3 b:3 c:3}
0:07:13
aeth
I think the first thing this library would need to do is introduce the trivial HASH macro (or HASH-TABLE or whatever) that turns (hash :foo 42 :bar 43) into (let ((#:hash1234 (make-hash-table))) (psetf :foo 42 :bar 43) #:hash1234) because now we have a concise way to say (hash :a 3 :b 3 :c 3)
0:09:31
rpg
White_Flame: I don't need anything as ambitious as matching on values; just keys + values. It occurs to me that what I'm looking for is DAG unification (well, for DAGs with named edges).
0:10:05
rpg
aeth: One way to think about it is that unification solves equations over a particular kind of symbolic algebrar.
0:10:24
White_Flame
ok, then you just need a representation for an "entry". A cons cell probably suffices
0:11:06
White_Flame
are you always going to "unify" two hashtables where 1 is exactly 1 element shorter than the other?
0:11:40
rpg
White_Flame: The two tricky details are paths in the unifiers, and that the semantics is that if you don't have an entry for a key, then you match *any* entry for that key.
0:12:09
White_Flame
if there is a key whose value is another hashtable... then that entry is simply that key/value pair
0:16:27
rpg
So we extend your example to {x:?X} {p: foo x: { y: {z: bar}}} and we get a unifier that is ?X = {y: {z: bar}} and... I'm not sure what I do with p: foo.... In this case I guess it's the same as if there is an additional, implicit top-level variable -- ?TOP1 = {x: ?X}, ?TOP2 = {p: foo x: { y: {z: bar}}} and ?TOP1 = ?TOP2...
0:17:45
White_Flame
eliminating the keys adn converting them to positional slots, it'd be like trying to unify (?X) with (foo (bar))
0:17:47
rpg
White_Flame: Right; that's what's difficult about this case; the entries are extensible. That's why I was saying that the semantics are odd.
0:18:44
rpg
White_Flame: If this was prolog, I would make these things out of difference lists, like your {x: ?x . ?} -- these are data structures that are extensible.
0:19:16
White_Flame
prolog does have the equivalent of hashtables, with key/values and these sorts of operations
0:19:42
rpg
White_Flame: That's a neat idea, because I can treat these objects as always having a sort of &rest logical variable.
0:20:41
rpg
If I do that, then standardization (making variables unique) will solve my problem, because the logical variable for the "hole" will always end up with a unique name.
0:22:46
rpg
White_Flame: Your suggestion is really like difference lists; thanks for mentioning that -- it suggests a path to a solution.
0:23:22
White_Flame
I've thought about this a long time for our tools, and it actually ends up exacly the same a prolog's tools
0:23:28
rpg
The issue for me is that I want to have operations on something like a python dictionary, *but* I want to be able to backtrack over it, so doing the updates by something functional.
0:24:36
rpg
White_Flame: There were a lot of good ideas in prolog, but it never caught on.... I think for good reasons. But some of the ideas developed for programming it are quite clever...
0:25:02
White_Flame
my biggest problem with prolog is that there's too many imperative practicalities shoved into it, breaking its declarative nature
0:25:42
rpg
White_Flame: Yes, that's true. It's possible that what I need is simply a data structure with an undo-able assignment. More thought is required!
0:26:35
rpg
White_Flame, aeth -- thanks for discussing this with me. I have to go now -- there is a dog scraping at the door. Hope to chat with you again sometime soon. Good night!
0:29:16
rpg
I think homoiconicity requires something stronger -- something intuitively like "the syntax IS the abstract syntax tree."
0:30:36
White_Flame
or put differently, TCL's syntax is degenerate to a point underneath which homoiconicity is determinable :-P
3:27:24
oni-on-ion
anamorphic, something in here ? https://asdf-devel.common-lisp.narkive.com/MuXBBEpq/about-asdf-compile-file-failure-behaviour-and-its-value-on-sbcl
3:32:24
oni-on-ion
"The first implementation of OPS5 was written in Lisp, and later rewritten in BLISS for speed. " <--- are you sure
3:32:39
logicmoo
the problem i have againt Logtalk is merely that it is an experiement with static OO (that never gets to OO)
3:33:34
logicmoo
its very mature.. but all it need is aobut 500 lines of code to do the type of OO i am refering to
3:34:54
logicmoo
in fact at his place of business (Kyndi) he had to pay someone 6k $ to circumvent his not adding it :)
3:37:37
logicmoo
but lets say you want to (make-isntance 'Person :name "Fred") (make-isntance 'Person :name "Joe") .. you cannot do that in Logtalk
3:38:16
logicmoo
you have to litteraly design a "type" with a name of Joe and another type named of "Fred"
3:40:03
logicmoo
and you can _even runtime generate those modules_ (Types = MNodues) in Logtalk.. Instance == modules to
3:41:51
logicmoo
he wanted to show off that neat trick where instances are just inheriting from a parent instance
3:42:32
logicmoo
nothing wrong with this at all! the only problem is that is the only type of instancing/iheritance available
3:43:57
oni-on-ion
logicmoo, hmm well about modules, i'm still learning them in OCaml and their clear difference between "Objects/Classes"
3:44:53
logicmoo
where program programmers normally will pass aorund a term refernce like person("Joe") and person("Fred").. Logtalk does not yet supprt this.. it could ina couple hundred lines
3:46:37
logicmoo
the term reference model is the most propular and there is even low level support .. basically its like a C struct
3:47:42
logicmoo
i go for it about once a year for about 10 years now .. the author is awesome dude.. i love the concept
3:49:42
oni-on-ion
been avoiding the OO-stuff in ocaml (interestingly, objects can be created/instantiated without classes), but learning all the Module stuff
3:50:12
oni-on-ion
prolog KB is a bit static anyway, by nature: what with assert/etc not entirely meant to be "dynamic"
3:52:41
logicmoo
it comes down to Object = Code Modules.. and Logtalk doesnt want to cupprt dynamicly crea5ed isntances.. since veryhting a person might create an object for can be redesigned
3:53:28
logicmoo
i meran anything that needed "dynamic" Code Modules .. are dubious and proabably should be redesigned
3:58:08
logicmoo
I ended up using all 6 data models for CLOS objects (the user can choose!) .. they can keep Fields in the assert/retract database.. they can call static code (for read only fields) .. i support FFI Object OO, Hashmaps, ALists and Prolog-Terms-Refs
4:01:51
logicmoo
Paulo wants *everyone* to use "call static code" so ensures that was all the language could support.. I want *everyone* to use assert/retract since that is the most OPS5-y .. but neither I or Paulo should get our way
4:04:34
logicmoo
hereis all the code Paulo and i would need to create a "getter" https://github.com/TeamSPoon/wam_common_lisp/blob/master/prolog/wam_cl/soops.pl#L643-L689
4:08:12
oni-on-ion
this reminds me of an ocaml library, forget which; that supplies two intrfaces, "Modular" style code and "OO" style code. i think it was ocaml
4:12:20
anamorphic
Yeah, I have a macro that creates a function with signature &rest rest &key ... lots of key args, but the logic inside the uses the rest argument to do the processing of the key args. It's harmless, but I can probably generate a (declare (ignore ...)) as part of that definition
4:33:18
logicmoo
though a clone can still be achived via useage of prototype as long as a prototype field values wont affect the extender (non-prototype object)
4:34:46
logicmoo
in my impl since i have to roll back side effects for "unwinding objects" i litternaly extend the object each time the program sets a feild
4:43:03
logicmoo
I suppsoe every time you clone something you can perhaps create a second clone that takes over for the oringal
4:45:41
logicmoo
(the system in this case makes all callers find the original thru a replaced (repointed to) refernce)
5:01:38
logicmoo
speaking of "clone" if i could clone someting other than a dictionary in Logtalk it'd have all teh features i could ever want https://logtalk.org/library/predicate_index.html#clone-3
5:29:17
logicmoo
If he accepts this https://pastebin.com/DN6X5iYg i will even create a OPS5 binding in Logtalk
5:31:16
oni-on-ion
Objects are interesting, but i've been wondering what "Subjects" would be like. modules perhaps?
5:32:23
logicmoo
Logtalk might call those "protocals" as long as you didnt mean "Subject Predciate Object" :P
5:33:20
oni-on-ion
well if Object were "addition" and Subject were "subtraction", perhaps. im not quite sure...