libera/#commonlisp - IRC Chatlog
Search
3:31:51
beach
Well, phrases like that seem to suggest that you know how Common Lisp was designed and that the people who designed it made a mistake. But in fact, the design is very consistent and the people who designed it were (are?) very smart and very knowledgeable.
3:33:06
CptJimKirk
Clearly, I have tried and failed at implementing my own languages. To create such a universal grammar for a programming language required keen insight. I probably know more about the history of CL and APL than I do about writing quality applications with them... :/
3:34:53
CptJimKirk
but looking at other reader macro examples, it seems clear that mutating global state is the norm in CL, and I should just get acclimated to that.
3:36:01
Alfr
CptJimKirk, why does it have to modify global state? (let ((*readtable* my-readtable)) (read some-input-stream)) can cover may things.
3:36:26
CptJimKirk
only if all of your definitions using that reader macro are defined within that let block
3:37:17
CptJimKirk
but that json reader macro example showed an enable/disable function which overwrote the reader, copying the original to some stack of read-table history
3:37:57
CptJimKirk
but then he corrected himself about named-readtables and said there is only 1 read-table
3:38:55
Bike
well, there's only one current readtable, yeah. i don't know what having more than one simultaneously would mean. there's only one syntax.
3:40:08
CptJimKirk
My current position is basically that a custom reader macro for this particular case is way nuclear of an option for just trying to maintain case
3:40:12
Bike
*readtable* kind of is the globally specified hook into the reader. there are lots of ways to mutate readtables, though.
3:40:25
Alfr
CptJimKirk, but in a program (let's not consider special variables and threads right now) you can only have one effective readtable at any moment.
3:40:33
CptJimKirk
I'll probbaly roll with saturns suggestion from earlier about (defapl (lisp-fn "AplFn") (args) (body))
6:34:39
lisp123
Does anybody know which implementations are unable to successfully extract a function expression from a function symbol via function-lambda-expression?
6:36:05
beach
I am willing to bet that the commercial implementations will not let you get the source code of their compiler that way.
6:37:17
beach
Also, for the generic functions in any implementation, I don't think there is anything reasonable to return.
6:38:14
lisp123
Thanks on both counts, that's useful to know. I hope the commercial implementations will allow it for user functions..
6:39:00
lisp123
I think its a very useful tool, if I want to create a macro that takes a function as an input and does a transformation, it makes it much easier to just use that
6:54:00
beach
lisp123: The TYPECASE would emulate the discriminating function, and each case would be the method function of one method.
7:16:55
beach
lisp123: The only thing they really had to add to pre-ANSI Common Lisp to get CLOS was the STANDARD-OBJECT and the FUNCALLABLE-STANDARD-OBJECT.
7:19:08
beach
lisp123: Classes are just STANDARD-OBJECTs, and generic functions are just FUNCALLABLE-STANDARD-OBJECTs.
8:26:11
pve
Good morning! I was listening to the Lex Fridman podcast where he discusses "Cyc" with Douglas Lenat, and there's a part that may be of interest to lispers.
8:27:25
moon-child
I believe cyc was implemented in common lisp but itself used only an s-expression syntax
8:31:04
moon-child
see also logicmoo, which is an oss continuation of cyc. It includes this gem https://github.com/logicmoo/wam_common_lisp, which '[Allows] Lisp programs to stop implementing an ad-hoc, informally-specified, bug-ridden, slow implementation of less than half of ISO-Prolog' :D
8:31:43
moon-child
pve: just from scanning filenames, it seems the actual inference engine is in java. See https://github.com/asanchez75/opencyc/blob/master/KB%2Binference_engine/opencyc-0.7.0b.zip
8:52:22
White_Flame
yeah, the engine is written in subl, which is a cut-down lisp intended to be translated to C/Java/etc for execution
8:53:08
White_Flame
I'm going through as much as I can get my hands on in terms of figuring out how it works. Especially interesting to me are how its pluggable inference modules work
8:53:51
White_Flame
I'm rewriting it, starting from data imports. The dependency ordered file porting approach was way too unwieldy
8:54:23
White_Flame
at least starting from data import, I can get a better sense of what data is actually there, instead of just a bunch of opaquely named datastructures interconnecting strangely
8:55:12
White_Flame
hmm, I haven't looked for that. Subl itself is documented, so it wouldn't surprise me if that's actually public
8:56:32
pve
White_Flame: he briefly explains in the podcast how the inference modules work, it sounds a lot like a blackboard system
8:57:14
White_Flame
I think lenat himself has gotten away from the actual technical details and mostly gives marketing descriptions nowadays
8:58:01
White_Flame
but with snippets from people who actually work at cycorp, it really sounds like it's a ton of manual labor to hardcode various modules to keep it from spinning to death & focus on specific problems, not that it magically finds its own way
9:13:21
White_Flame
at the very least, the code has excessive legacy & massive technical debt built up, which makes it hard to work on
9:13:56
White_Flame
the design of subl was basically oriented around memory & speed efficiency for much older execution environments
9:14:38
White_Flame
from a knowledge engineering perspective, I hope they've kept everything cleaner, but much of that isn't public
9:14:59
White_Flame
there's been various releases of opencyc, and if they're all unioned together, might cover most of their actual core knowledge
10:29:25
White_Flame
that's a pretty good interview, but yeah the technical details aren't beyond what's described in publicly findable documentation. A good intro, though