libera/#commonlisp - IRC Chatlog
Search
2:26:20
CptJimKirk
@alfr if I understand what you're saying, I'm trying to infer the APL name from the name of the (defapl name ...
2:27:05
CptJimKirk
so `(defapl myAplFn (args) (process (to-array (something-else input))))` or some such would pass the result of that body to a function from April called `myAplFn`
2:27:37
CptJimKirk
inside the macro, it expands somewhere `(defmacro defapl name .... (april-c "myApl"fn" results)... )`
2:28:42
CptJimKirk
I thought something like this would work (let ((count 0)) (defun incrmentr () (setf count (1 + count))))`
2:28:49
mfiano
If you have been learning Lisp for a long time, I suggest spending time on the important parts
2:28:58
CptJimKirk
by wrapping the `defmacro` in redefining the reader case, but that def doens't work
2:29:59
CptJimKirk
tell me what other language allows you to manipulate the way its parsed at runtime?
2:30:46
mfiano
I would argue if you don't like the power of Lisp, which requires knowledge to use the power effectively, go back to writing APL in APL
2:31:19
CptJimKirk
@mfiano that is not a concluion that can be drawn from what I'm trying to do here
2:32:22
mfiano
If you're going to argue semantics, I have no more desire to help. This is not #clschool after all.
2:32:58
CptJimKirk
I was trying to direct my line of questioning there before we wound up down this tangent
2:33:26
CptJimKirk
I did change the reader, but it didn't work the way I expected for obvious reasons, the language is read outside of the context of the re defined readtable
2:33:38
CptJimKirk
but also, I don't want the user to have to know to update the read table every time they want to use (defapl
2:34:12
CptJimKirk
and I don't have to toggle a statemachine updating the readtable every time I want to use those
2:34:58
mfiano
Reading happens before everything in the Lisp compiler. I don't know how you plan to accomplish that if you don't want to use a string name.
2:35:00
CptJimKirk
so I'm not playing semantical games, I'm being specific, I want to be able to define in terms of a normal lisp binding form like `defun`, without having to use || or a string
2:35:25
mfiano
Either use the reader, which forces a burden on users, or require them to use strings and do the work at macroexpansion time
2:37:09
lotuseater
CptJimKirk: you could have it with brackets, [define camelCaseFunction ...] so that just the second symbol will be case preserved
2:40:32
Alfr
lotuseater, you'd still have to write |1|, \1 or some such when calling your |1|-function.
2:40:48
mfiano
Which requires the user to switch to your custom readtable, since that is a toplevel form
2:42:22
mfiano
If you do not want to leverage the Lisp reader, you must use what is already available at read time
2:43:04
CptJimKirk
no it isn't doable. The specific conditions I laid out have to this point I've been told that what I specified is not possible
2:43:19
mfiano
You can, you just placed a lot of constraints that only open up 2 paths to a solution.
2:45:04
mfiano
Another option would be to require the user to define their def forms in a file that is not loaded, and manually call #'load in some function, installing a read table around it
2:46:06
CptJimKirk
The user wants to be able to "call apl functions" in their lisp code, appearing like any other lisp function, but which ultimately binds to the April function by the same name, which should be definable ad-hoc without the need to manually update some global state machine for defining, either that or it would need to be defined within a block that
2:46:07
CptJimKirk
shadows the *readtable* which means that not only can I not bind the lisp macro to the april funciton ad-hoc, but its scope specific, and would require a recompilation of the entire reader macro block every time I make any change
2:46:45
CptJimKirk
I can (defun my-fn (args) body) I want to (defapl myAplFn (args) body) just the same
2:48:01
CptJimKirk
I wouldn't assume looking at this expression that there is a lisp function now defined called "myAplFn"
2:48:42
CptJimKirk
and (defapl |caseSensitive| ...) is just a gotcha that you'll have to remember any time there is a apl fn with multiple case
2:49:37
CptJimKirk
I don't understand... Are you suggesting that any time a reader macro is used, that the user of the reader macro has to define all of their code from within the scope of that reader macro?
2:50:15
mfiano
Yes, reader macros are global. There is named-readtables that helps with that a little bit.
2:52:42
specbot
Standard Macro Characters: http://www.lispworks.com/reference/HyperSpec/Body/02_d.htm
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