00:04 <jcowan> But I don't care that the syntax of complex numbers uses a sharpsign particularly.

06:38 <Shinmera> seok: https://github.com/3b/sdf/blob/rewrite/api.lisp#L99

08:35 <pjb> nij-: When the answer is "No", it means it's not trivial to do. You can always do it, with sufficient work. If you want to change the evaluation rules, you may do something like in cl-stepper. https://gitlab.com/com-informatimago/com-informatimago/-/tree/master/common-lisp/lisp

08:36 <pjb> nij-: then instead of (defpackage "MY-PROGRAM" (:use "CL")) you'd write: (defpackage "MY-PROGRAM" (:use "MY-RULES-LISP"))

08:37 <pjb> nij-: have a look at pseudo-scheme to see how you can implement the scheme rules.

08:41 <pjb> nij-: as mentionned, there's no standard way to change the evaluator (ie. EVAL, COMPILE and COMPILE-FILE). BUT you can either feed the evaluator some changed code like cl-stepper does, thru different macro expansions, OR you can use a different evaluator: write your own MY-RULE:EVAL, MY-RULE:COMPILE, MY-RULE:COMPILE-FILE, and the functions that call them such as MY-RULE:LOAD, and use them instead of CL:EVAL, … CL:LOAD.

08:42 <pjb> nij-: note: this is a common occurence, for example, CLIM defines its own objects and methods. A clim application (:use "CLIM") instead of "CL", and you get clim:defmethod instead of cl:defmethod, etc.

08:44 <beach> pjb: Are you sure about that?

08:45 <beach> http://bauhh.dyndns.org:8000/clim-spec/2-2.html#_8

09:04 <pjb> Hmm, in McCLIM, there's both a CLIM-LISP and a CLIM package, that re-exports most of CLIM-LISP stuff.

09:05 <pjb> So, yes, it should be CLIM-LISP, not just CLIM.

11:01 <jcowan> One issue with rewriting code (and this applies both to macros and to run-time rewrites) is that all's well when the input is fine, but a compile-time or run-time error will be given in terms of the transformed code rather than the original code. C and Scheme both have facilities to help with this.

11:09 <dirtcastle> how to remove arch linux's sbcl and install it manually from source.

11:10 <dirtcastle> I want to get stumpwm running. it works but the modules don't work. stumpwm-ql in community package loads properly but I think it's not working as intended.

11:32 <jackdaniel> the package CLIM exports CLIM symbols, CLIM-LISP is a drop-in replacement for the package COMMON-LISP

11:54 <contrapunctus> dirtcastle: removing Arch's SBCL is an Arch package management question (which I'm not knowledgeable about). SBCL has binary releases on its website IIRC.

11:54 <contrapunctus> dirtcastle: https://sbcl.org/getting.html

12:17 <AadVersteden[m]> dirtcastle: if you installed from the AUR you can remove it that way. If you are installing manually because the AUR installation doesn't do what you want, you should be able to build a different release that does do what you want.

12:17 <AadVersteden[m]> I have extra/sbcl installed and it seems to work fine for me, but I'm not running stumpwm.

12:17 <AadVersteden[m]> (good choice though)

12:23 <pjb> jcowan: granted. The same is true when you compile natively to assembly. Then the debugger could give you assembly and hex dumps. In both cases, meta data is addded to the code, to be processed by a source-level debugger. So it's a consideration to take, and add a debugger for your new language.

12:27 <jcowan> Racket has the advantage that it doesn't require any such thing: source information is generated by the front end and the compiler believes it. Similarly, a C preprocessor, either cpp or something else, generates lines of the form "# foo.x 32", meaning that errors in the following line are to be reported as coming from line 32 of the file foo.x. (Note that this is not a preprocessor directive: that is spelled "#line".)

12:28 <jcowan> Granted, debuggers like gdb can't handle just any language: you'd hardly expect them to work correctly with a Prolog compiler, e.g.

12:32 <pjb> and the C processor #line are hardly enough.

12:34 <jcowan> It's good enough for the errors that batch compilers typically generate.

14:20 <Bike> i don't understand how "source information is generated by the front end and the compiler believes it" is different from what most lisps do

15:00 <Bike> although it is not standardized and accessible in the same way as it is in racket

15:04 <seok> shinmera:thanks

15:16 <contrapunctus> Package SHINMERA does not exist.

16:13 <jcowan> Bike: Consider the case in which I am translating some language (Superblub) into Lisp in order to execute it efficiently. When a run-time error takes place, it is reported in Lisp terms rather than in Superblub terms. That is very confusing for the user, who needs to be able to understand program faults according to their mental model, which is based on Superblub, not Lisp.

16:14 <Bike> oh so by "frontend" you're talkinga bout like a superblub frontend, not necessarily the racket frontend.

16:16 <jcowan> If you write a front end in Racket, you talk to Racket in syntax objects, which carry along with them Superblub-level source information.

16:16 <jcowan> So the Racket front end *is* a Superblub front end: there is no real difference.

16:17 <jcowan> e.g. (+ 3 4) is translated by the Racket front end into (%app + 3 4), where %app is a special form representing function application.

16:17 <jcowan> s/Racket/Racket-language

16:17 <jcowan> or more accurately into the result of applying datum->syntax to (%app + 3 4).

16:19 <jcowan> So if your Superblub language is Basic, then sin(x) would be translated into (%app sin (%var x)), whereas rnd is not (%var rnd) but (%app rnd).

16:25 <edgar-rft> jcowan: of course it's possible to signal Common Lisp conditions containing line numbers from Superblub code, but it's task of the fornt-end to set that up when transforming the code from Superblub to Lisp.

16:25 <Bike> uhhuh. so the syntax objects are a bit like CSTs, although CSTs don't have any of the hygeine stuff

16:25 <jcowan> What are CSTs?

16:26 <random-nick> concrete syntax trees

16:26 <jcowan> Ah. Yes.

16:50 <Bike> i looked a bit at racket while doin csts stuff. something like syntax->datum and datum->syntax could be useful in writing some macros, but that would require some major and nonconforming reorganization of how CL macros work

17:00 <jcowan> You'd want to start with Fare's hygienic macros, I think.

17:03 <jcowan> (or maybe they are someone else's, I am not sure)

19:41 <jmes> Hey folks, when you define an initialize-instance :after method and you give it a keyword parameter, does that mean you would be able to pass that keyword parameter to make-instance?

19:53 <pve> jmes: that should be the case, see http://www.lispworks.com/documentation/HyperSpec/Body/07_ag.htm

19:54 <pve> someone more knowledgeable may correct me, if necessary

19:56 <yitzi> jmes: You can pass any keyword parameter to make-instance. INITIALIZE-INSTANCE and others all have &allow-other-keys.

19:57 <Shinmera> That's not true.

19:58 <Shinmera> make-instance must error on unrecognised keyword arguments. A keyword argument is recognised if it is a slot initarg, or if it is defined as a keyword argument on an applicable initialize-instance or shared-initialize method.

19:59 <yitzi> Thanks for the clarification

20:02 <Bike> yeah it's a bit confusing. they have allow other keys but that's only because make-instance does this special checking instead of the normal checking.

20:27 <pjb> Shinmera: that's not true; make-instance takes &rest. It passes them to initialize-instance which takes &rest. It passes them to shared-initialize, which has &key &allow-other-keys !

20:28 <pjb> So you should be able to pass any &key argument to make-instance.

21:00 <Bike> there is an entire subsection on the CLHS specifically describing how make-instance and co reject keyword arguments. this is not ambiguous. you cannot pass any keyword to make-instance.

21:01 <Bike> clhs 7.1.2

21:01 <specbot> Declaring the Validity of Initialization Arguments: http://www.lispworks.com/reference/HyperSpec/Body/07_ab.htm

21:01 <Bike> and of course the page on make-instance says "The initialization arguments are checked within make-instance."

21:05 <Bike> if you're going to try to out-pedant someone please take the effort to ensure you are saying true things

21:11 <Bike> or just boot up a lisp and try it

21:12 <pjb> yes, partial reading of clhs is dangerous.

21:17 <Bike> don't try to play this off with "yes". i am disagreeing with you. someone said something and you tried to correct them with something false.

21:46 <pjb> Sorry.