libera/#commonlisp - IRC Chatlog
Search
2:59:47
CptJimKirk
why was there never any consideration for a (defreader which would pass the remaining expression to the body of the reader, which would then read the body?
3:00:18
saturn2
if you want your system to be usable by lisp programmers the way they expect, without learning anything new or doing anything unusual, the only way is to explicitly map ordinary all-uppercase symbols to apl function names
3:00:59
hayley
That makes no sense. I mean, if you have "the remaining expression", you already read it.
3:01:51
CptJimKirk
@hayley (defreader (............)) the (...) could be a string completely unevaluated
3:04:13
Alfr
CptJimKirk, the problem with what you expect is, that you think that the call to (defreader .............) sees the dots, it doesn't.
3:04:35
hayley
CptJimKirk: The reader always leaves things unevaluated. But it still has to do some "parsing" in order to find the matching ) eventually.
3:05:19
CptJimKirk
does it have to parse, or just match the count of open an closing parens until the stack is 0?
3:06:12
CptJimKirk
(defreader (....)) could be defined as just "reading a text string" until the matching closing paren, no parsing, then pass the string to the custom reader "macro/function" thing
3:06:56
CptJimKirk
i'm not arguing about how it IS, I'm asking why this wouldn't work in a special-case special-form type thing
3:07:52
CptJimKirk
but IF in this hypothetical form that doesn't actually exist, if it didn't EVALUATE, and only read the contents as a string?
3:08:29
beach
The reader would have to parse the name of the "special form" which is not what the reader does or is designed to do.
3:08:48
Alfr
CptJimKirk, once you identify the special form symbol, the reader already has parsed and returned the list (you-new-and-shiny-special-form-symbol-name maybe some args).
3:10:24
CptJimKirk
what about ##'#'*D->(readermacro ...) as some kind of prefix annotation to tell the reader "hey this thing is something else"?
3:10:51
CptJimKirk
that could trigger something in the readers statemachine, oh this is something else
3:15:35
Alfr
CptJimKirk, you can then quite freely determine how you proceed reading; maybe #@, as #a is already used for denoting arrays.
3:17:54
Alfr
mfiano, what? It's undefined, and I assumed he'd start modifying the standard readtable.
3:18:31
mfiano
Just because it is undefined in ANSI doesn't mean a conforming implementation is not allowed to define it
3:21:58
CptJimKirk
I think what I'm learning is I need to stop trying to treat CL as having a pure subset
3:26:45
beach
CptJimKirk: The other thing I recommend you do is avoid phrases such as "a glaring oversight/misstep" about how Common Lisp was designed.
3:29:54
CptKirk92
how else should I say that having a globally specified hook into the reader macro that doesn't mutate global state would be better than mutating global state?
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