freenode/#lisp - IRC Chatlog
Search
10:05:09
luis
White_Flame: no _need_ for a separate package.lisp file I don't think, just a common convention.
10:06:03
White_Flame
I tend to put exports where things are defined. In such a case, a reevaluated defpackage whines about the empty exports not matching (in sbcl)
12:53:52
jmercouris
and of course I could do `(markup:markup ,(user-interface::object-expression q))
12:54:17
jmercouris
however, I want to just be able to do something like (markup:markup (user-interface::object-expression q))
12:55:40
jmercouris
I want to take an object, and have it emit some SEXP by some function and have that be processed by cl-markup
13:18:40
jmercouris
I wwas thinking evaluate if it is one of my user-interface library forms, otherwise do not
13:20:10
jackdaniel
if I understand correctly, you will need to change the code anyway, so "lot's of code" argument goes away -- in that case what is the problem with using the function markup* in the library?
14:11:33
nij
In the source code, it seems that #'apply is ill-defined. https://bpa.st/NYNBC .. Indeed, the first cond drops you in an infinite loop apparently. And indeed, by copying the code and change each "apply" to "my-apply", I obtained a function #'my-apply that never ends. What's going on here?
14:13:38
edgar-rft
nij: (answer to your clschool question from a few hours ago) if you *need* AND/OR functions, for example as arguments to FUNCALL or APPLY, the the intended way is to use EVERY (function) instead of AND (macro), and SOME (function) instead of OR (macro)
14:14:27
Bike
this definition is for the case where the actual apply function is called, like because it's used as an argument to some higher order function.
14:15:55
phoe
https://github.com/sbcl/sbcl/blob/d4740e38bd4e541c29827d922737147b6813e8b3/src/code/list.lisp#L30
14:16:38
nij
edgar-rft: Oh! Indeed! #'SOME and #'EVERY are almost what I want, only did I need a curried version. I have (finally) implemented one myself.. but will switch back to currying those two standard functions. thanks :)
14:18:44
jackdaniel
it is ugly also from the programmer background - this definition is not technically correct and relies on information that is not available locally
14:19:21
Xach
nij: as kent pitman once said, the model you can use initially is: "built-in functions are given by god"
14:19:35
nij
Let's just talk about CAR as it's much shorter, and the problem seems to be the same :)
14:20:47
jackdaniel
beach: could it be implemented if we exploit the fact, that call-arguments-limit is an integer?
14:22:06
Bike
you can have (apply function arg1 ... argl) as (multiple-value-call function arg1 ... (values-list argl)), which is what sbcl does. and then since multiple-value-call is a special operator it's "fine" in that the magic is on the special operator
14:23:21
jackdaniel
n.b ecl does that to a certain number of arguments (64 if I recall correctly), after that it indeed passes arguments by other means
14:24:09
phoe
and also the namespaces for functions, macros, and specops are actually the same namespace.
14:24:58
phoe
beach noted in the previous discussion that it should have been written differently if this were clean code
14:25:12
Bike
here's a better example for you. write your my-apply, and then do (define-compiler-macro my-apply (function &rest arglist) `(multiple-value-call ,@(butlast arglist) (values-list ,(first (last arglist)))))
14:25:28
Bike
that's pretty close to how sbcl works, if you assume that the compiler macro expansion is always used.
14:25:32
beach
nij: Maybe you prefer the SICL definition of CAR: (defun car (x) (if (consp x) (cleavir-primop:car x) (if (null x) x (error...))))
14:27:41
beach
aeth: You would still have to connect the CAR function to whatever the hardware does.
14:29:50
phoe
the implementation can do whatever it wants while it implements the functionalities provided by symbols in the CL package
14:29:53
beach
nij: When you look at system code, in order to understand it fully, you need to understand how the system does compilation and bootstrapping.
14:29:59
jackdaniel
nij: you may treat it as an implementaiton detail - what Xach quoted is very accurate
14:30:56
nij
But I hope there's a way to tell if something magical is happening, without looking into the source of the implementation.
14:31:13
beach
nij: Again, when you look at system code, in order to understand it fully, you need to understand how the system does compilation and bootstrapping.
14:31:15
phoe
as I said X weeks ago, a Lisp implementation can implement the function CL:+ by sending a question to Mechanical Turk over the internet.
14:31:49
phoe
the list specifying where magics are would need to be maintained by each implementation, and I have no idea of what benefit would be other than for maintainers and implementers.
14:31:55
jackdaniel
nij: from the "outside" behavior operators specified as functions work like functions, period - nothing dirty happens
14:32:02
phoe
nij: yes, studying the implementation and asking people who are knowledgeable in how it works.
14:32:06
jackdaniel
you may spot something magical when you actually look into the implementation code
14:35:51
beach
I think you will find similar "magic" in every implementation. In SICL for instance, you will see (defclass standard-class (...) (...))
14:37:30
nij
But fine, as it's not practical too much, it depends on the implementors if they want to make it clear or not. And that's their personal choice.
14:37:37
phoe
if you see a CL symbol being defined somewhere, it means that you're already in the magic zone
14:38:46
beach
nij: Then, I would have to annotate pretty much every class definition of a system class. That can become quite annoying to read.
14:40:02
Bike
as jackdaniel noted, it's not magic that has any conceivable effect on a conforming lisp program.
14:40:27
Bike
that's why there's no provision for telling you about it. You only need to care if you're curious about how sbcl is written.
14:40:54
beach
nij: My defclass example is "magic" in that the metaclass of standard-class is standard-class so it has to exist in order to be defined this way.
14:41:31
Bike
things that are only special operators ARE magic in a sense that you can actually discern, which is why special-operator-p exists.
14:42:40
nij
beach: I don't understand class yet so I can't say.. but I believe it's doable. (but not practical)
14:44:32
beach
nij: That definition makes perfect sense in that it uses the meaning of well defined operators, so it's ideal that way. But it is not operational for the reason I mentioned. It is the purpose of bootstrapping to make it operational.
14:45:09
beach
nij: The code would have been much less understandable if I had used some specific notation for something that can be perfectly well notated with DEFCLASS.
14:45:22
jackdaniel
n.b that's one of many reasons why programmer is not allowed to redefine operators in cl package (that is - the package is locked)
14:48:24
jackdaniel
(defmacro defmacro (&rest args) (cerror "Are you sure?") (error "Macros are bad for you"))
14:52:45
_death
(handler-bind ((sb-ext:symbol-package-locked-error #'continue)) (defun () () ())) ... (()) => ()
14:54:40
nij
To see what 'car really contains, in particular, i want to see a piece of it as a specop.
14:54:51
jackdaniel
nij: the operator you are looking for is: (defun magical-p (symbol) (eq (find-package 'cl) (symbol-package symbol)))
14:55:41
jackdaniel
there are more magical packages surely, like sicl's primop package, but you know the drill
14:57:26
Bike
nij, i don't think you've really absorbed that there is NO CONFORMING WAY to see car as anything other than a function.
14:58:18
Bike
you cannot construct a conforming program in which the fact sbcl does compiler transformations sometimes is relevant. In a way that's the entire point of compiler transformations.
15:02:14
jackdaniel
I don't want to spoil the fun for you, but it may be even implemented as a C function :_)
15:02:17
phoe
in a way, that's where it stops being #lisp and starts being #sbcl or #ccl or #ecl or wherever else
15:05:18
Bike
if you want to get into sbcl guts, you'll need to find a corresponding source-transformation, ir1 transform, or ir2 transform. there are a few functions that approximate getting at them but nothing that's easy to use since it's all sbcl guts. if you just do M-. in slime it'll usually pop up that stuff.
15:06:35
Bike
for car in particular you want the source transform in srctran.lisp, and then if that fails it goes to the ir2 convert in generic/vm-macs.lisp which is hard to get details on because it's a "reffer" into a primitive structure.
15:07:49
Bike
this is in addition to other transforms and things that can sometimes elide calls to the car function that are spread throughout the system.
17:37:29
jackdaniel
hurrey, alpha-blended dashed path via xrender in McCLIM :) https://files.mastodon.social/media_attachments/files/105/634/554/978/109/689/original/cc3bbb1a7ed936b6.png
17:42:10
amerlyq
Hello, today I have two more questions on forms evaluations ;) 1) what will (defun f () (a) (b) (a)) will do if we replace
17:43:24
amerlyq
I expect (a) will keep previous value because stack frame stores pointer to whole previous environment of (f) ?
17:43:56
jackdaniel
amerlyq: I don't understand your question; I think that you could gain more insightful feedback if you put more effort in writing it
17:44:51
amerlyq
jackdaniel: It's not that I'm lazy, it simply is fuzzy in my head. Sorry. I will try to rephrase it.
17:45:34
OlCe
amerlyq: Hi. I don't think so. But also depends on whether you're compiling a whole file or not.
17:45:35
jackdaniel
my point is that it would be better if you first figure out what you are wondering about and then try to ask a precise question; that gives you a better chance of learning something
17:47:28
OlCe
amerlyq: then the second (A) could refer to the top-level definition of A, as well as the first.
17:49:01
OlCe
amerlyq: Then, if (A) is declared inlined, second call to A will be same as the first.
17:49:31
OlCe
And if you don't declare anything, and are not in the COMPILE-FILE case, then it's up to the implementation.
17:49:59
amerlyq
jackdaniel: so, I know, that (f) is executed in one thread, and we try to replace (a) from another thread. Current instruction pointer is at (b), so (a) was executed once already, and whole (f) is already on stack and captured pointer to environment, so further replacement of (a) must not have effect on current execution of rest of (f). But is it true?
17:50:15
jackdaniel
OlCe: thanks, that part about "regardless of whether (A) was declared inlined or not"
17:50:54
jackdaniel
amerlyq: common lisp standard does not talk about multithreading, so you are already in the unspecified territory
17:51:59
OlCe
jackdaniel: "A call within a file to a named function that is defined in the same file refers to that function, unless that function has been declared notinline. The consequences are unspecified if functions are redefined individually at run time or multiply defined in the same file."
17:52:35
jackdaniel
and whether environment capture, I don't think that there is such term in common lisp either - I doubt that environment is stack-allocated in case of global functions
17:52:55
OlCe
jackdaniel: So NOTINLINE blocks this behavior. And there is no real guarantee if there are runtime redefinitions.
17:53:28
jackdaniel
ah, that's what you've meant. I thought that you speak that inline/notinline declarations are ignored
17:53:56
amerlyq
OlCe: if "second (A) could refer to top-level" after compile time -- does it mean all symbols were resolved in compile time?
17:54:57
OlCe
jackdaniel: Although I would bet that, in practice, (F) calls the initial version of (A) in this case. But again, no guarantees about stable behavior.
17:56:07
OlCe
jackdaniel: Yes, I meant, whether there is an INLINE declaration or not (but not including the NOTINLINE case).