libera/#commonlisp - IRC Chatlog
Search
21:04:30
recordgroovy
I'm targeting it to be readable by humans and asdf, but not by generic scrapers.
21:04:46
recordgroovy
Enough backslashes would make it readable by asdf, but probably not humans without good effort
21:06:12
specbot
Single Escape Character: http://www.lispworks.com/reference/HyperSpec/Body/02_adf.htm
21:09:26
tfeb
ACTION is now planning a tool which will convert code with string literals into code which uses load-time-value in ... interesting ways
21:46:26
lotuseater
I asked myself, when I can do all sorts of symbol names between pipes #\|, how is this done by the reader, cause (get-macro-character #\|) => (values nil nil). also with #\: for reading in keywords. or is this hidden for purpose to not break certain stuff?
21:50:01
jcowan
| is a character of a special type: multiple escape. What it does is not done by the readtable. : is just a token character: its interpretation happens at a higher level.
21:51:45
lotuseater
it was funny some days ago as i showed someone the symbol '|This is a symbol, really, I swear.| :D
21:54:21
jcowan
Yes, it is. But \ and | are not implemented using readtable macro characters. You caan change what characters are used, but the behavior of single and multtiple escape chars is hardwired.
21:54:49
_death
you can (set-syntax-from-char #\| #\a) and then | is no longer a multiple escape character
21:55:39
jcowan
or (set-syntax-from-char #\$ #\|) and then $this is a symbol even though it doesn't look like it.$
21:58:18
White_Flame
of course, the readtable interface isn't always the easiest to extend for every language. Sometimes you need to go raw
21:59:43
jcowan
I should probably have said "non-CL Lisps". CLtL gives the example of !, which is the single escape char for Portable Standard Lisp.
21:59:50
lotuseater
or opening foreign files as streams, reading all lines and break up piece by piece
22:02:24
jcowan
The Compatibility Note at the bottom of https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node188.html explains how | is not a macro character.
22:02:28
lotuseater
so NASA calls you "we need a FORTRAN77 expert" so no problem, now we do Lisp (again)
22:13:32
lotuseater
oh I remembered reading about Symbolics they had their own Lisp implementations for compiling C, Ada, Fortran ^^
22:15:52
jcowan
I found a copy of CLtL2 for $34 at the awesome bookfinder.com (price includes shipping to me, so YMMV)
22:17:13
lotuseater
but also something like Feynman Lectures on Physics, Knuth's Concrete Mathematics or TAoCP, expensive ...
22:18:29
lotuseater
have found in the university lib in the book sale (every for 1€) an old version of The METAFONTbook
22:20:24
lotuseater
as much as a new game, but of course more substance: https://www.zvab.com/servlet/BookDetailsPL?bi=30210395030&searchurl=hl%3Don%26kn%3DConcrete%2BMathematics%26sortby%3D20&cm_sp=snippet-_-srp1-_-title2 (just as an example)
22:26:50
lotuseater
but now I found a big book (from 1996) about AutoLISP, could be helpful for the new potential job and I bet this small industry company still runs on much old stuff
22:35:34
lotuseater
moon-child: or finally doing this Hercules task and building a translator for COBOL to Java/C# or whatever banks/insurances mean is good
22:38:15
hayley
I read that it is made very complicated by having rational arithmetic (bad for Java, fine for CL) and being able to change GOTO targets on the fly (very bad unless you give up and compile basic-block at a time).
22:40:36
lotuseater
or the systems behavior must be changed safely stepping away from those hairy things
22:56:25
etimmons
Xach: UIOP 3.3.6 is on the way. Being tested on the systems not yet covered by CI. Will hopefully be out in a day or two
1:33:06
recordgroovy
Hi, I'm wondering if anyone could spare some time to peer-review a library I've been working on. Thanks for any comments :)
1:49:28
moon-child
recordgroovy: I am not so sure of the special-casing of eof. Usually it makes more sense to treat the eof as just another kind of token
6:34:49
phantomics
recordgroovy: Looks interesting at a glance, very neat code. I'll give it a try when I have time
7:25:25
pjb
lotuseater: I've seen big systems defining some dispatching reader macros on $ ; but nowadays, with unicode, you can more often just define a reader macro on a unicode character.
7:46:26
kakuhen
Is it possible for eval-when to implicitly modify arguments of functions like find-class?
7:47:18
kakuhen
I have a macro that transforms a given symbol and creates a class named with this transformed symbol, together with methods specialized on the class.
7:48:20
kakuhen
Say this transformed symbol is X. Both CCL and SBCL throw style warnings that my defmethod's are using the undefined type X, but the class was defined right before I define these methods.
7:49:53
pjb
kakuhen: not eval-when directly, but eval-when implies that the body will be evaluated in different environments, so it's possible that operators that may depend on the environment such as find-class give different results.
7:50:02
kakuhen
So I decided to wrap (defclass X () ...) in an eval-when form. Above in the macro, I check the output (find-class X nil). When I use eval-when, errorp somehow becomes T rather than nil
7:50:09
pjb
It should be the job of the programmer to ensure that the differences are not semantically different.
7:51:10
kakuhen
pjb: Yeah, I suspect eval-when implying a different environment somehow makes the arguments supplied to FIND-CLASS "flip," but it wouldn't explain why this issues goes away when I supply the environment.
7:51:49
kakuhen
anyway, I am trying this because SBCL and CCL are giving me style warnings (ECL doesn't give style warnings), and I assume it could be a bug in both SBCL and CCL's compiler, but I don't want to jump to such conclusions yet.
7:52:14
kakuhen
and I get strange behavior with FIND-CLASS when I include an (eval-when (:compile-toplevel :load-toplevel) ...) in the macro
7:52:26
pjb
You must be doing somethign strange, because a simple toplevel sequence of defclass defmethod should work nicely.
7:53:19
kakuhen
Anyway, I am trying to produce a minimal working example of the style warnings SBCL and CCL produce
7:53:33
kakuhen
SBCL produces twice as many style warnings as CCL, so it's catching(?) something that CCL isn't. Meanwhile ECL just gives zero style warnings.
7:53:48
pjb
kakuhen: so, your macro should expand to (progn (defclass x () ()) (defmethod moo ((x x)) …))
7:55:01
beach
kakuhen: The dictionary entry for DEFCLASS contains a phrase that makes its compile-time behavior very hard to understand.
7:55:37
beach
That might be the reason for the differences in behavior of different implementations.
7:56:23
beach
It is essentially impossible for an implementation to comply with what the standard says.
7:56:28
kakuhen
I see. And, before it gets asked, yes, I set the debug level to 3 before compiling on each implementation.
7:56:38
pjb
"If a defclass form appears as a top level form, the compiler must make the class name be recognized as a valid type name in subsequent declarations (as for deftype) and be recognized as a valid class name for defmethod parameter specializers and for use as the :metaclass option of a subsequent defclass. The compiler must make the class definition available to be returned by find-class when its environment argument is a value received
7:57:57
pjb
kakuhen: But I've seen nothing that implies a need for eval-when in your macro expansion. Just use progn around your defclass and defmethod forms.
7:57:58
kakuhen
The style warnings disappear on both SBCL and CCL once I use (find-class X nil nil) and put the defclass in this eval-when block(?)
7:58:26
kakuhen
but I found an interesting behavior where ERRORP automatically gets set to T (on both sbcl and ccl!) if I just have (find-class X nil) written, and the defclass is in this eval-when block
7:58:47
kakuhen
this behavior mysteriously goes away if I do one of two things: remove the eval-when block, or explicitly provide the environment
7:59:24
kakuhen
I'm trying to produce a minimal working example but so far I haven't been able to reproduce the style warnings, yet.
8:00:43
beach
I would be interested in complete examples of what happens in different implementations and what you expected to happen. But take your time.
8:05:11
beach
kakuhen: It is not enough to say that the definition is in an "eval-when block". The "situations" given in that form are important too.
8:09:46
kakuhen
Ok this will sound really dumb, but I have a macro %FOO and a macro FOO that calls %FOO with a restart-case
8:10:07
kakuhen
Calling (%FOO bar) does not give the undefined type warning. Calling (FOO bar) does.
8:11:35
kakuhen
i understand the importance, but i also want to minimize irrelevant information -- you'll know i've given up in attempting to produce a minimal example when i just send the entire lisp file along with the repl output for each implementation.
8:14:01
beach
You also need to show when the behavior you observe happens, like if it is at compile time, load time, or run time.
8:16:31
beach
lotuseater: Wow, hold on! First errors are not "thrown", they are "signaled". Second, it is not typically the debugger that signals the error, but the application code, which will call the debugger if the error is not handled. Third, no, the same error can be signaled in all three situations.
8:20:21
kakuhen
Expected behavior: I expect the new class' corresponding type to be defined before we define the method specializing on the new class.
8:20:54
kakuhen
ECL does not give any style warnings, but I will nonetheless give output for it soon.
8:23:08
kakuhen
These style warnings disappear when the defclass is compiled and loaded at the top level, that is, we place it inside (eval-when (:compile-toplevel :load-toplevel :execute) ...)
8:23:34
kakuhen
But this opens up a can of worms where FIND-CLASS suddenly sets ERRORP to T despite supplying NIL to it. This goes away if you explicitly provide NIL for both ERRORP and ENVIRONMENT
8:28:31
beach
kakuhen: I see no trace of the argument to FIND-CLASS having been altered. I see essentially the same behavior, i.e. that the class is not recognized. And I think it will take me some time to figure out why. Others here are usually much faster.
8:30:35
kakuhen
Yes. And it seemed fine to me. It was invoking FIND-CLASS exactly as I intended, yet ERRORP would be set to T
8:30:43
beach
kakuhen: And, again, your examples don't show how you compiled and/or loaded the file containing the macro definitions.
8:31:02
kakuhen
ah... I'm running C-c C-c in SLY, and I denoted in the file where I have compiled both
8:35:01
beach
And what makes you think that FIND-CLASS should be invoked as you intended, rather than as the system decided to invoke it?
8:36:55
kakuhen
beach: here is a working example where FIND-CLASS mysterious gets ERRORP set to T http://0x0.st/-WyX.lisp
8:37:04
kakuhen
I will post the output from CCL soon, and this time I am compiling and loading at the REPL.
8:40:31
kakuhen
CCL output http://0x0.st/-WyK.txt and the debugger with a full backtrace http://0x0.st/-Wy8.txt
8:40:59
kakuhen
beach: in the latter link, you will see immediately in the backtrace (FIND-CLASS BAR* T NIL)
8:41:14
kakuhen
I expect (FIND-CLASS BAR* NIL NIL) to be supplied since my macro calls (FIND-CLAS BAR* NIL)
8:42:05
beach
Yes, but I have no reason to believe that this error is a result of your own call to find-class.
8:47:07
kakuhen
Okay, I guess that settles the issue with the FIND-CLASS call. This convinced me that my earlier interpretation is incorrect.
8:50:11
beach
Even if your call to FIND-CLASS is evaluated before the defmethod form, you would not see any output from your find-class call.
8:50:12
kakuhen
I would like to correct myself on what I said at 01:23 PDT. The FIND-CLASS call that ultimately signals an error does not occur when I specify (:COMPILE-TOPLEVEL :LOAD-TOPLEVEL :EXECUTE) in my eval-when block. It occurs when I am missing the :EXECUTE symbol
8:51:07
kakuhen
So this error is more due to myself misusing / not understanding what happens when I use EVAL-WHEN with specific arguments
8:51:40
beach
Also, every new attempt must be done in a fresh image, or else, you may have altered the global state of your environment in previous attempts.
8:52:29
kakuhen
Yes. When I made the separate examples, I made sure to restart my lisp image and delete the FASLs generated by the compiler