freenode/#lisp - IRC Chatlog
Search
20:29:46
makomo
Bike: meaning that if CL:WRITE was compiled in env A and now i'm in B and CL:WRITE is available to me, calling it from B will try to access which env's variables?
20:30:40
makomo
and that would be bad because you couldn't for example rebind dynamic vars in B and have them affect what CL:WRITE would do?
20:31:32
Bike
if you rebind them there's no problem, but if you don't it would use whatever value is global in A
20:32:43
makomo
would it also use B's globals if i defvar'd them in B (i.e. not just make a temp dynamic binding, but a global one)?
20:36:08
makomo
i haven't yet carefully read beach's paper, so maybe i'm missing something, but i don't get why. so if i'm in B and i do (let ((*something* 10)) (something-compiled-in-A)), something-compiled-in-A will see 10. but if i'm in B and i do (defparameter *something* 10) (something-compiled-in-A) then something-compiled-in-A will see whatever *something* is bound to in A?
20:43:44
makomo
Bike: hm, i guess that actually makes sense. so aside from the fact that defvars, defparameters, setfs, etc. might not affect certain functions, is there anything else?
20:44:59
Bike
strictly speaking, any function that signals anything uses the special variable *break-on-signals*
20:46:44
makomo
so every environment would need a complete copy of all the functions, global variables, etc. to behave properly?
20:48:12
makomo
so is a sandbox then hopeless or just tricky (but not as tricky as code-walking and similar) to do?
20:49:59
Bike
You could define a standard library where all the functions take a global environment as an explicit argument and use it scrupulously, and then just give each environment wrapper functions that call those with the environment.
20:53:05
makomo
so not only would the implementation have to support FCGEs, but if you wanted it to be actually usable, it would have to reimplement the whole stdlib to also take these env arguments and then create wrappers that delegate to these
20:54:23
Bike
i guess alternately they could consult a global environment that's in a dynamic binding, which then has to be bound locally for any calls
20:55:33
Bike
Or you could force the sandboxed code to be in a nearly-CL that doesn't have variables like *break-on-signals* and can't use function designators and stuff.
20:55:40
MichaelRaskin
One of the problems with doing sandboxing without full implementation support and without implementing a transpiler from Common Lisp to Common Lisp is that you never know what expanding standard macros can leak
20:57:18
MichaelRaskin
Well, maybe it is reasonable to do implement a self-transpiler as a Common Lisp macro library.
20:59:31
MichaelRaskin
Basically, you would have a package where all the Common Lisp stuff is defined, but all the standard macros expand to something pre-vetted.
21:00:35
MichaelRaskin
For many things the HyperSpec gives semantically acceptable but inefficient expansions, maybe you should make sure that your macroexpand only gives expansions like this
21:02:16
MichaelRaskin
(compilation with optimisations could try making sure the expansions do not leak and using efficient ones whenever it is safe)
21:03:17
MichaelRaskin
Once everything is the wrappers you control, you make sure these wrappers also rebind all relevant global variables to use the desired FCGE contents
21:03:48
MichaelRaskin
And you make sure you use a reader that thinks this masquerade package is the real :common-lisp
21:04:34
makomo
oh, so just making sure that the macros' expansions don't leak then? when you said "self-transpilers as a Common Lisp macro library" i thought you meant something else (but i still don't know what you meant by that, i.e. what is self-transpiling here?)
21:07:18
MichaelRaskin
Well, you write in Common Lisp a set of functions and macros that allow you to compile Common Lisp (with your preferred environment treatment) to Common Lisp (with only standard-based assumptions, and probably some defacto standard extensions)
23:21:13
pillton
Bike: Would copy on write work to solve the sharing of objects across environments?
23:32:54
pillton
Is it not a good idea to maintain a link between the lexical variable and the current global environment in situations like (let ((x 1)) (defun example () (incf x)))?
0:19:24
ealfonso
how does a recursive macro work, is it dynamically expanded at runtime? I wrote a macro to retry an arbitrary form up to n times, retrying in case of a condition signalled. the problem is that n is not known at compile time
0:21:54
ealfonso
so currently I wrote a macro using loop, so it's not a recursive macro. the problem is that I'm storing the result into a variable, and forms that return multiple values don't seem to work correctly
0:22:19
Bike
(defun retrying (n thunk) (tagbody loop (handler-bind ((error (lambda (c) (declare (ignore c)) (go loop)))) (funcall thunk))))
0:37:08
Bike
establishing a bunch of blocks, including one named NIL, aorund arbitrary code is kind of bad though
0:38:46
makomo
Bike: because the blocks don't use gensym'd names, or because it's just complicated/bad style?
0:40:20
ealfonso
i'm trying this, https://pastebin.com/B68fQy5P => "return for unknown block: #:|loop-tag823|"
0:41:17
makomo
Bike: so what stndard looping construct is there that doesn't establish a NIL block? is there one even?
0:50:05
makomo
Bike: then i lose the ability to differentiate between exceeding and succeeding though, no?
0:50:19
makomo
i mean, currently i don't differentiate via the return value in any way, only in "Exceeding" being printed
1:00:29
ealfonso
thanks Bike makomo . I wanted to try it myself, and was only missing the (return-from ) and the named loop tag. https://pastebin.com/g3B3bidW
1:55:33
skidd0
Hello all. Quick question regarding packages and systems with asdf and quicklisp coming up.
1:56:19
skidd0
I have a package.lisp that exports two classes from my project.lisp along with a project.asd that defines the project's system
1:57:45
skidd0
but, when i try to then (make-instance 'class-in-project), i get an error that says the class symbol doesn't exist in common-lisp-user
2:08:30
Xach_
inheritance is done with use-package or :use in defpackage (it must be external in the source package)
2:09:05
Xach_
use-package isn't something you'd use normally - it's more typical to use defpackage to set things up.
2:12:35
Xach_
yes. but import has a bit of an issue where it doesn't matter if it's external. in theory you should import only external things. i'd like an import-if-external or something sometimes.
2:12:54
Colleen
Unknown command. Possible matches: 8, time, set, say, mop, get, login, grant, tell, roll,
2:16:32
simplegauss_
is there a standard way to create callable objects or (equivalently) add some annotation to a function object so that it can still be called by funcall?
2:18:51
simplegauss_
i've actually seen that, but i don't think that's standard, and moreover have no idea how it works (as in I can use it, but I have no understanding of the link between funcall and MOP).
2:18:58
simplegauss_
here is a working example: https://clos-mop.hexstreamsoft.com/concepts/#funcallable-instances
2:19:51
simplegauss_
is there a specification for how funcall actually works in the standard? my main reference is the hyperspec and as far as I can tell it makes no mention of anything to do with the mop
2:21:27
simplegauss_
Bike: i wanted something closer to the standard. i guess it doesn't really matter in practice, but it makes me uneasy that I don't have an understanding of how it works.
2:22:16
simplegauss_
is there a free way to learn about MOP? something like the hyperspec? it seems AMOP is only available for purchase
2:24:43
simplegauss_
Xach_: true :) really all i would need is a generic "funcall" that works on functions and on objects inheriting from a certain class, but that seems uglier and more invasive than using the existing MOP solution.
2:27:41
simplegauss_
Bike: what i'm confused about is, for example, I can't find in the spec you linked how funcall is modified, and this is the sort of thing i'd like to understand. do you know if that sort of info is in AMOP? if so I can try and get it from the library
2:28:38
Bike
it's just specified that if you try to call a funcallable-standard-object, it calls that object's funcallable-instance-function instead
2:30:48
simplegauss_
Bike: but the point is I can't make a "funcallable-simplegauss-object" that doesn't inherit from "funcallable-standard-object" but still works with funcall/apply, right? it just seems like a weird special case in the design.
2:32:10
Bike
you need the metaclass because the objects have an additional semi-slot for the function, which is reflected in the class
2:33:08
Bike
in the standard you can't define objects that aren't instances of standard-object, or classes that aren't subclasses of standard-class, just by design
2:36:10
simplegauss_
so historically CLOS came before and separately from the MOP infrastructure, or they were created concurrently but only certain parts made it into the standard?
2:45:31
simplegauss_
more generally, i have a (mostly academic) interest in the tradeoffs of polymorphism the CLOS/MOP vs typeclass (pioneered by Haskell) way. it seems that in practice the only deficiency of CLOS is return-type dispatch (which would be quite difficult in lisp :))
2:46:43
Bike
generic function calls will also involve a runtime dispatch cost that i believe haskell can avoid.
2:47:45
simplegauss_
I guess there's also the ML modules way, but that seems just a few macros away :)
2:48:47
simplegauss_
Bike: you might be interested in https://github.com/guicho271828/inlined-generic-function
2:49:52
Bike
the basic idea is that it implements CLOS using itself, and exposes some of the generic functions therefore involved.
2:58:16
ealfonso
let's say I want to split a single-package containing some utils into a utils and a 'core' file. defs in the 'core' file depend on defs made in util. do I need to put (defpackage ) in util?
3:32:03
rpg
ealfonso: Often handy to put defclass, defmacro, defvar, defparameter forms in decls.lisp, which depends on package.lisp and then have everything depend on decls
5:56:38
jack_rabbit
shared libraries have certain calling conventions. All the lisp has to do is adhere to those and it's all good.
5:57:12
jack_rabbit
The functions and objects exposed by the library are made visible through an API.