<nij->
sb-cltl2 module provides compiler-let and environment access functionality described in Common Lisp The Language, 2nd Edition which were removed from the language during the ANSI standardization process. http://www.sbcl.org/manual/
<mfiano>
FCGE's are an implementation technique
<nij->
Here we do have env access.. what's making it not first-class given sb-cltl2?
myrrh has quit [Changing host]
myrrh has joined #commonlisp
kevingal has quit [Remote host closed the connection]
<mfiano>
I would just read the paper.
<nij->
mfiano: which paper? Beach's paper?
<moon-child>
mfiano: first-class global environments are a language feature that happens to be useful for bootstrapping one implementation
<mfiano>
Right
<mfiano>
THe paper explicitly mentions it did not research their use for application developers, and defers to problems in doing so in related works.
<EdLangley[m]>
Trucler is probably better designed, IMO
<EdLangley[m]>
Anyways, sicl already uses them to bootstrap itself. So, someone could probably figure out how to write an ASDF component that uses a similar technique.
<jasom>
Hmm, reading the environments paper, the package system is not affected; does that mean you couldn't have two environments in which the set packages would have conflicting imports?
<jasom>
s/reading/skimming quickly/
dra_ has joined #commonlisp
karmichammer has joined #commonlisp
<EdLangley[m]>
Yeah, ideally you'd also use a separate reader like Eclector to virtualize the package system too
dra has quit [Ping timeout: 240 seconds]
<jasom>
well I wasn't sure because it says "For a given package P and symbol name N, there is at most one symbol with the name N in P" but does not clarify what "in" means; I could potentially see that not applying to imports, though the surrounding text implies it does.
occ has joined #commonlisp
mgl has quit [Ping timeout: 256 seconds]
AeroNotix has quit [Quit: WeeChat 3.4]
AeroNotix has joined #commonlisp
karmichammer has quit [Ping timeout: 256 seconds]
dra_ has quit [Remote host closed the connection]
<dbotton>
Does IN-PACKAGE work with in an EVAL? in a PROGN? I get strange results one time no, one time yes
karmichammer has joined #commonlisp
<White_Flame>
what do you mean by "work"? affect *package* for the calling environment, or for peer forms within PROGN?
notzmv has quit [Ping timeout: 240 seconds]
<dbotton>
yes
<dbotton>
I evel a (progn (in-package :xyz) (something)) where something = xyz:something
<dbotton>
sorry eval not evel
<Catie>
Would (let ((*package* :the-package-you-want)) ...) do the same thing?
<White_Flame>
what's the current package? and is 'something already ayx:something?
<White_Flame>
*xyz
<dbotton>
no some other package
karmichammer has quit [Ping timeout: 240 seconds]
<dbotton>
it is valid code, ie xyz:something exists
<White_Flame>
the literal symol whose symbol-name is "SOMETHING" in that expression; that's an extant symbol in a sexpr list that is xyz:something, or that is a string on the REPL that is being read?
<dbotton>
a function
<White_Flame>
are you typing this at the repl?
<White_Flame>
or is this literal source code in a file?
<White_Flame>
or this is a sexpr that's built up programmatically that you're EVALing?
<dbotton>
#3
nij- has left #commonlisp [#commonlisp]
<White_Flame>
ok, so while (something) is executing, *PACKAGE* should be XYZ, as well as when it returns
<EdLangley[m]>
IN-PACKAGE would affect package, but by the time you call EVAL, it's too late to adjust the package read symbols belong to
<White_Flame>
right, if it's a constructed sexpr, though, I don't think the reader is involved
<White_Flame>
hence asking if the symbol xyz:something is already constructed before that EVAL form is reached
<dbotton>
So I am generated code as text, let the user modify it, the submit it to be eval'd
<White_Flame>
in terms of the literal symbol in the s-expression
<White_Flame>
(whee all sorts of overparticular words :-P)
<White_Flame>
ah
<EdLangley[m]>
You have to also bind PACKAGE around READ
<White_Flame>
so you are going through the reader
<EdLangley[m]>
Although, hmm, does READ-FROM-STRING handle IN-PACKAGE?
<EdLangley[m]>
It should have to
<White_Flame>
so, when you read "(eval '(progn (in-package ....)...))", the value of *PACKAGE* will be used to construct the symbols well before EVAL or the inner IN-PACKAGE is evaluated
<White_Flame>
no, the reader doesn't handle in-package. The compiler/evaluator does
<EdLangley[m]>
It has to, though because it has to know where to intern read symbols
<White_Flame>
so when running a file, the reader needs to be called per toplevel form and then executedevaluated before the next toplevel form is read
<White_Flame>
*executed/evaluated
<EdLangley[m]>
Hmm, that makes sense
<EdLangley[m]>
So, you, you'll have to do (let ((package ...)) (read ...))
<Alfr>
EdLangley[m], in-package sets cl:*package*, and the compiler has to treat top-level in-package specially to have the same effect, that's about it.
<White_Flame>
loading a .lisp file has to do the same per-form handling
<EdLangley[m]>
Theproblem is READ has to intern symbols
amk has joined #commonlisp
AeroNotix has quit [Quit: WeeChat 3.4]
<EdLangley[m]>
So, you have to basically run top-level forms sequentially
<EdLangley[m]>
(at least ones with load/compile-time effects)
jeosol has quit [Ping timeout: 256 seconds]
<Alfr>
White_Flame, forms within a top-level progn are also considered top-level forms.
<White_Flame>
EdLangley[m]: yes, lisp source code forms are mutators against the running image
<EdLangley[m]>
Interestingly, you could use eval-when for mischievous tricks here
<EdLangley[m]>
e.g. pick different packages for load and compile time
<moon-child>
see masinter comments in #lisp
<White_Flame>
there's also the notion of compilation-unit, which i'm not too up on
<EdLangley[m]>
White_Flame: Although, arbitrary toplevel forms don't necessarily run, right
<EdLangley[m]>
e.g. (setf package (find-package :foo))
<EdLangley[m]>
I don't think that necessarily does anything at load or compile time
<White_Flame>
at compile-time? correct. I'm not sure that behavior is defined for that
<White_Flame>
load time is probably sequential
<EdLangley[m]>
And DEFUN doesn't necessarily create a function that can be used at load time
<EdLangley[m]>
which is why you have to EVAL-WHEN DEFUNs you use in macros
<White_Flame>
the compilation unit aggregates peer DEFUNs
<White_Flame>
no, macro use of functions are compile-time, not load time. so eval-when boosts it earlier
<EdLangley[m]>
Yeah
<EdLangley[m]>
sorry
<White_Flame>
dbotton: more confused or less now? ;)
<Bike>
if (setf package (find-package :foo)) is a toplevel form with no eval-when etcs around it, it will run at load time
<dbotton>
sometimes you are so confused you don't know you are
<Bike>
you can kind of think as :load-toplevel :execute as being the default state before any eval-whens come in
<White_Flame>
dbotton: heh. Well, when you _read_ the string in to a list, that's where the packages are assigned to the symbols
<White_Flame>
and that happens before eval. So you need to (let ((*package* (find-package :xyz))) (read-from-string "(progn ...)"))
wyrd has quit [Ping timeout: 276 seconds]
<White_Flame>
and then those default symbols in there will be from XYZ package
karmichammer has joined #commonlisp
<White_Flame>
then you can EVAL that list
<White_Flame>
so yeah, if you have a variety of packages you might want to read inside of, then that'll generally have to be sideband information outside the string
<White_Flame>
"(progn #.(in-package :xyz) ...)" is also a terrible hack that will work, but also leave the caller's package changed
<dbotton>
did a let *package* (find-package :foo) around the eval and works
<White_Flame>
cool
<White_Flame>
that's the proper way
<White_Flame>
specifically, that it's around the read-from-string (or whatever READ-based thing) that makes it work
<dbotton>
It means that I can't allow the user to play with packages
<dbotton>
but is ok in this case
<White_Flame>
yep, just like toplevel .lisp (in-package ..), the compiler has to stop and swap packages before continuing the next read
<Alfr>
dbotton, you could use read and consume what you get form by form and check for an in-package form.
karmichammer has quit [Ping timeout: 250 seconds]
<dbotton>
I'll keep that in mind Alfr
<dbotton>
Thank you all
<Alfr>
dbotton, if you have a string, you may want to use with-input-from-string, so that READ will like it.
wyrd has joined #commonlisp
mon_aaraj has quit [Ping timeout: 268 seconds]
<EdLangley[m]>
I've been trying to figure how much of this is important
<EdLangley[m]>
Because I'd like to implement a system for loading code from non-file inputs
<EdLangley[m]>
e.g. a database or a zipfile
<EdLangley[m]>
(without unpacking the zipfile to disk)
<EdLangley[m]>
Yeah, because the first eval changes the package and then the second one evaluates in the right package
<dbotton>
that should not affected code already running correct? (ie it has already been read)
karmichammer has quit [Ping timeout: 256 seconds]
<EdLangley[m]>
hmm, must be something else
<White_Flame>
you probably should :use :cl
<White_Flame>
it is pretty roundabout, though to go string->read->print->read
<EdLangley[m]>
I was doing this when I was serializing the code to a db and wanted it to be as unambiguous as possible
<White_Flame>
if there is #. or #= it won't round-trip and might mess with the timing & identity of objects
<EdLangley[m]>
:use :cl has the downside of making the code a bit ambiguous, because you have to assume it's always going to be read in a package that doesn't shadow symbols from :CL
notzmv has joined #commonlisp
Catie has quit [Remote host closed the connection]
Catie has joined #commonlisp
Catie has quit [Remote host closed the connection]
<White_Flame>
yeah, hence the "probably"
Catie has joined #commonlisp
karmichammer has joined #commonlisp
random-nick has quit [Ping timeout: 256 seconds]
xsperry has quit [Killed (NickServ (GHOST command used by asdfasf!~xs@cpe-188-129-71-242.dynamic.amis.hr))]
lispy has joined #commonlisp
perrierjouet has quit [Quit: WeeChat 3.4]
karmichammer has quit [Ping timeout: 268 seconds]
pieguy128 has quit [Ping timeout: 268 seconds]
perrierjouet has joined #commonlisp
xsperry has joined #commonlisp
pieguy128 has joined #commonlisp
pieguy128_ has joined #commonlisp
pieguy128 has quit [Ping timeout: 250 seconds]
EsoAlgo has quit [Ping timeout: 256 seconds]
jeosol has joined #commonlisp
karmichammer has joined #commonlisp
Inline has quit [Ping timeout: 240 seconds]
<EdLangley[m]>
If I ever really return to this, I'm going to try to figure out how to use eclector to make a reversible reader
<EdLangley[m]>
Adding a sort of IR that represents the side-effecting reader macros
<White_Flame>
a reversible reader, assuming things don't mutate in the meantime, and just store the original string it read and print that as its representation :-P
<White_Flame>
a reversible printer is the hard part ;)
<EdLangley[m]>
By "reversible" I mean there's a bijection between input and output
<EdLangley[m]>
So, it has an inverse operation
<White_Flame>
just to be specific/pedantic, the brunt of the work goes in the printer, not necessarily extending the existing reader
<moon-child>
EdLangley[m]: that's not different
<moon-child>
(defun reversible-read-from-string (s) (cons s (read-from-string s)))
<mzan>
I were writing optimized code (it was for a benchmark).
<mzan>
I like the (iter ...) macro a lot. But the (iter ...) macro initialize some variables to "nil" sometime, and the SBCL compiler refuse to apply some type optimizations because it sees an initial nil value and sometime it is not smart enough to figure out that the "nil" value will never be used.
<mzan>
But usually, I liked a lot programming in CL. A very fun language.
karmichammer has joined #commonlisp
<mzan>
My impression is that the majority of macros works well together but sometime there is some leak. It is acceptable, but it is rather frustrating if one coded in more rigid languages like Haskell.
<mzan>
In this case specific, the leak was only related to optimizations, but not real semantic. Probably there are no many leaks on the side of the semantic.
<beach>
mzan: You are learning Common Lisp, and the first thing you do is with CFFI? Wow!
<moon-child>
mzan: in such 'rigid' languages, you would probably not be allowed to write such code in the first place
karmichammer has quit [Ping timeout: 240 seconds]
<mzan>
moon-child: yes fair. In fact using CL is exhilarating :-)
<moon-child>
re iter/optimization: there was some loop/iter-like macro that purported to generate good code for pipelines of transformations. I can not now remember what it's called, but someone else may...
<beach>
mzan: There are several irritating style problems with your code, like mysterious blank lines, wrong number of semicolons in comments, incorrect indentation.
<sm2n>
mzan: have you read the section of the iterate manual on type declarations?
<mzan>
moon-child: yes, I tried SERIES. In the end I prefer the "iterate" macro.
<mzan>
SERIES by default do not compile to optimized code (IIRC).
Jing has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<beach>
mzan: What is your reason for showing your code?
<mzan>
nothing in particular
<beach>
mzan: Ah, so you don't want remarks on it?
<mzan>
I have problems to go to bed/sleep tonight (I'm not kidding)
<mzan>
beach: If you want remark something, it is very good. My I'm mainly here for chatting.
aartaka has joined #commonlisp
<beach>
I see.
<mzan>
sm2n: I read something about type declarations in "iterate", but I will study it better. Thanks!
<mzan>
BTW, in case of doubts I can expand the code generated by the "iterate" macro, so for sure the problem was not obfuscated by the environment.
waleee has quit [Ping timeout: 240 seconds]
<mzan>
Probably in future I will try to micro-optimize the code, removing left notes signaled by SBCL, and benchmark the difference.
<mzan>
Now it is good enough, and better than I were expecting.
<mzan>
moon-child: I tried SERIES. In theory they should be superior to "iterate", because you can reuse chunks of code transforming data in different places. SERIES support this.
<mzan>
In practice, up to date, rarely I feel to write more code in "iterate" than in SERIES. And "iterate" is more flexible and more in line with the imperative semantic of some parts of CL.
<sm2n>
I agree with this
xsperry has joined #commonlisp
occ has joined #commonlisp
* moon-child
just uses loop
<EdLangley[m]>
I think the sort of implicit stream-fusion SERIES does ends up being pretty limited in CL
s-liao has quit [Quit: Client closed]
<EdLangley[m]>
I've been experimented with transducers (from Clojure) that work more explicitly by passing a continuation around, and I think they're a better fit for lisps
<EdLangley[m]>
If you want to use MAP and friends
<mzan>
Are there transducers also for CL?
<EdLangley[m]>
I've been working on a port, but it's not really ready to shar
<EdLangley[m]>
*share
<mzan>
nice
<mzan>
Another thing I didn't liked to CL, it is that there is some lack of basic data-structures. In Haskell there is a rather efficient IntMap for example, and other data structures. C++ has plenty of them.
<EdLangley[m]>
mzan: various libraries implement datastructures
<EdLangley[m]>
I think FSET is one of the older ones
<EdLangley[m]>
Also, Sycamore, which I've never used
semz_ has joined #commonlisp
<mzan>
ahhh "(1+ ...)". I din't know there were this function, but I suspected there were something of similar! :-)
semz has quit [Ping timeout: 250 seconds]
dre has quit [Read error: Connection reset by peer]
<mzan>
EdLangley[m]: I don't know TRANDUCERS, but you example seems anti-intuitive to me. You are usinng a "reduce", but you pass a function that creates a stream (a vector in this case).
<mzan>
In SERIES you work with streams, and there is fusion.
<mzan>
In your example, "compose" apparently do not work on streams using fusion, but only on the entire result.
<mzan>
I'm not able to grasp the paradigm.
lispy has quit [Quit: Leaving]
<mzan>
In my ideal world, I would like stream transformers with an optional internal state, that can be fused. Then some final reducers.
<EdLangley[m]>
So, functions like MAPPING return a function that takes a continuation as an argument
<EdLangley[m]>
Conventionally, this is called RF, for "reducing function"
<EdLangley[m]>
This returns a function with the signature you'd pass to REDUCE: (ACC NEXT) -> whatever
<EdLangley[m]>
This function, instead of building up a result with an explicit constructor, calls RF and passes an appropriate value of ACC and NEXT to it
<EdLangley[m]>
So, for MAPPING, this means something like (funcall rf acc (funcall transform next))
<EdLangley[m]>
Where transform is the argument passed to MAPPING
s-liao has joined #commonlisp
Jing has joined #commonlisp
<mzan>
I don't know CL enough for understanding all your code. But it is usefull reading it for me.
<EdLangley[m]>
But (compose (mapping f) (mapping g)) doesn't build up an intermediate collection
<moon-child>
then it seems to me that compose distributes over mapping
<moon-child>
i.e. instead of (compose (mapping f) (mapping g)), you can say (mapping (compose f g))
<moon-child>
so it does not matter so much anyway
<EdLangley[m]>
Yeah, that's just an example
<moon-child>
err, mapping distributes over compose
<EdLangley[m]>
With a full library, you can do like: (compose (mapping #'1+) (filtering #'evenp) . . .)
<moon-child>
(loop for x in xs if (evenp x) collect (1+ x))
<moon-child>
:^)
<EdLangley[m]>
Basically, any operation that can be expressed through the lambda you pass to REDUCE, you can do this way
<EdLangley[m]>
Yeah, but the point is to preserve the (mapcar (lambda (b) ...) (mapcar (lambda (a) ...))) style
<EdLangley[m]>
without the extra garbage
<moon-child>
I worry more about indirect calls than garbage
<EdLangley[m]>
If you don't care or like that style, it matters less :)
<EdLangley[m]>
This also abstracts from the concrete result type and from limitations like "the input sequence must be finite"
<EdLangley[m]>
You can express an operation once and pick whether it builds a list, a vector or puts results on a channel of some sort at the use-site
<moon-child>
my primary exposure to this sort of style is apl (not clojure), which is very strongly oriented _away_ from streams
<mzan>
EdLangley[m]: SERIES are composable, in the sense you can reuse a complex SERIES definition as starting point of another SERIES. Is your paradigm composable?
<EdLangley[m]>
Yeah, that's the point
karmichammer has quit [Ping timeout: 240 seconds]
tyson2 has quit [Remote host closed the connection]
<mzan>
so something like (defun even1+ () (compose (mapping #'1+) (filtering #'evenp)) can be reused, while a "loop" no.
semz_ is now known as semz
hineios1 has joined #commonlisp
hineios has quit [Ping timeout: 256 seconds]
hineios1 is now known as hineios
karmichammer has joined #commonlisp
karmichammer has quit [Ping timeout: 250 seconds]
lispy has joined #commonlisp
dre has joined #commonlisp
lispy has quit [Client Quit]
karlosz has joined #commonlisp
karmichammer has joined #commonlisp
Inline has joined #commonlisp
karmichammer has quit [Ping timeout: 256 seconds]
karmichammer has joined #commonlisp
karmichammer has quit [Ping timeout: 250 seconds]
myrrh has quit [Quit: leaving]
occ has quit [Remote host closed the connection]
s-liao has quit [Quit: Client closed]
occ has joined #commonlisp
karmichammer has joined #commonlisp
occ has quit [Remote host closed the connection]
karmichammer has quit [Ping timeout: 240 seconds]
pranavats has left #commonlisp [Error from remote client]
mon_aaraj has quit [Ping timeout: 240 seconds]
mon_aaraj has joined #commonlisp
ahc has joined #commonlisp
shka has joined #commonlisp
s-liao has joined #commonlisp
Inline has quit [Ping timeout: 240 seconds]
karmichammer has joined #commonlisp
karmichammer has quit [Ping timeout: 240 seconds]
s-liao has quit [Ping timeout: 256 seconds]
MajorBiscuit has joined #commonlisp
karmichammer has joined #commonlisp
karmichammer has quit [Ping timeout: 256 seconds]
karmichammer has joined #commonlisp
pranavats has joined #commonlisp
karmichammer has quit [Ping timeout: 240 seconds]
Cymew has joined #commonlisp
mgl has joined #commonlisp
karmichammer has joined #commonlisp
s-liao has joined #commonlisp
karmichammer has quit [Ping timeout: 250 seconds]
Major_Biscuit has joined #commonlisp
luna-is-here has quit [Ping timeout: 240 seconds]
karmichammer has joined #commonlisp
MajorBiscuit has quit [Ping timeout: 250 seconds]
attila_lendvai has joined #commonlisp
karmichammer has quit [Ping timeout: 256 seconds]
ahc has quit [Ping timeout: 256 seconds]
karmichammer has joined #commonlisp
Dynom has joined #commonlisp
pve has joined #commonlisp
karmichammer has quit [Ping timeout: 268 seconds]
wyrd has quit [Quit: Lost terminal]
karmichammer has joined #commonlisp
xantoz has quit [Ping timeout: 256 seconds]
karmichammer has quit [Ping timeout: 250 seconds]
karmichammer has joined #commonlisp
rogersm has joined #commonlisp
lisp123 has joined #commonlisp
karmichammer has quit [Ping timeout: 240 seconds]
Jing has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
attila_lendvai has quit [Read error: Connection reset by peer]
attila_lendvai has joined #commonlisp
karmichammer has joined #commonlisp
Algernon69 has joined #commonlisp
Jing has joined #commonlisp
karmichammer has quit [Ping timeout: 240 seconds]
karlosz has quit [Ping timeout: 256 seconds]
<shka>
i need example of building with roswell
karmichammer has joined #commonlisp
karmichammer has quit [Ping timeout: 250 seconds]
szkl has joined #commonlisp
rogersm has quit [Ping timeout: 240 seconds]
karmichammer has joined #commonlisp
karmichammer has quit [Ping timeout: 250 seconds]
karmichammer has joined #commonlisp
lisp123 has quit [Remote host closed the connection]
karmichammer has quit [Ping timeout: 256 seconds]
lisp123 has joined #commonlisp
karlosz has joined #commonlisp
Equill has joined #commonlisp
lisp123 has quit [Ping timeout: 240 seconds]
karmichammer has joined #commonlisp
karmichammer has quit [Ping timeout: 240 seconds]
s-liao has quit [Ping timeout: 256 seconds]
Cymew has quit [Ping timeout: 256 seconds]
Catie has quit [Ping timeout: 240 seconds]
wyrd has joined #commonlisp
s-liao has joined #commonlisp
Algernon69 has quit [Ping timeout: 268 seconds]
Cymew has joined #commonlisp
Lord_of_Life_ has joined #commonlisp
Lord_of_Life has quit [Ping timeout: 256 seconds]
Lord_of_Life_ is now known as Lord_of_Life
s-liao has quit [Ping timeout: 256 seconds]
jeosol has quit [Ping timeout: 256 seconds]
karmichammer has joined #commonlisp
mon_aaraj has quit [Ping timeout: 268 seconds]
mon_aaraj has joined #commonlisp
shozo has quit [Ping timeout: 268 seconds]
kevingal has joined #commonlisp
pillton has quit [Remote host closed the connection]
tyson2 has joined #commonlisp
shozo has joined #commonlisp
karmichammer has quit [Ping timeout: 250 seconds]
rogersm has joined #commonlisp
rain3 has joined #commonlisp
karmichammer has joined #commonlisp
scymtym has quit [Ping timeout: 240 seconds]
random-nick has joined #commonlisp
karmichammer has quit [Ping timeout: 250 seconds]
gamaliel has joined #commonlisp
karmichammer has joined #commonlisp
<gamaliel>
Hi, does anyone have experience with the vgplot system? I don't know how to return a plot as a tk widget. When I run (vgplot:plot) it returns an empty string.
karmichammer has quit [Ping timeout: 256 seconds]
lisp123 has joined #commonlisp
gamaliel44 has joined #commonlisp
gamaliel44 has quit [Client Quit]
gamaliel78 has joined #commonlisp
karmichammer has joined #commonlisp
gamaliel has quit [Ping timeout: 256 seconds]
vats has joined #commonlisp
lisp123 has quit [Ping timeout: 256 seconds]
mon_aaraj has quit [Ping timeout: 250 seconds]
mon_aaraj has joined #commonlisp
s-liao has joined #commonlisp
karlosz has quit [Quit: karlosz]
Cymew has quit [Ping timeout: 240 seconds]
scymtym has joined #commonlisp
Algernon69 has joined #commonlisp
gamaliel78 has quit [Quit: Client closed]
Cymew has joined #commonlisp
s-liao has quit [Ping timeout: 256 seconds]
s-liao has joined #commonlisp
frodef has quit [Ping timeout: 268 seconds]
frodef has joined #commonlisp
vats has quit [Ping timeout: 256 seconds]
varjag has joined #commonlisp
Algernon69 has quit [Ping timeout: 268 seconds]
karmichammer has quit [Ping timeout: 240 seconds]
<qhong>
gamaliel: why you want to get a widget object? vgplot (or gnuplot) seems to rely extensively on global state and I think there’s no way to do that
<qhong>
gamaliel: iirc vgplot doesn’t manage its own GUI, it just sends command to a separate gnuplot process. I could be wrong. I was using it a lot for scientific computing but I had no need to hack it
s-liao has quit [Ping timeout: 256 seconds]
<ns12>
qhong: That user is no longer online ...
Algernon69 has joined #commonlisp
gjvc has quit [Ping timeout: 250 seconds]
lisp123 has joined #commonlisp
karmichammer has joined #commonlisp
lisp123 has quit [Ping timeout: 240 seconds]
Bike has joined #commonlisp
karmichammer has quit [Ping timeout: 240 seconds]
nij- has joined #commonlisp
<nij->
I just watched beach's talk again on FCGE. A main issue it addressed is that it's not easy to implement FCGE without sacrificing run-time performance. But I fail to understand how his implementation resolves this issue.. any idea?
s-liao has joined #commonlisp
VincentVega has joined #commonlisp
<Bike>
FCGE?
<contrapunctus>
Bike: First Class Global Environments
s-liao has quit [Client Quit]
<Bike>
oh. well, beach's implementation uses cells, so that at runtime to look up a definition you just grab it from a cell that was compiled in, which is pretty quick. that's not in the presentation?
VincentV` has joined #commonlisp
VincentVega has quit [Ping timeout: 240 seconds]
mon_aaraj has quit [Ping timeout: 240 seconds]
mon_aaraj has joined #commonlisp
karmichammer has joined #commonlisp
ec has quit [Remote host closed the connection]
<nij->
I did stop and re-watch many parts of it, but still failed to see the reason. Hmm.. I also need to think more about what you said.
ec has joined #commonlisp
<nij->
If not using this "cell method", what else did people try?
<Bike>
well the obvious way is like a hash table lookup
OlCe has quit [Ping timeout: 256 seconds]
Algernon69 has quit [Read error: Connection reset by peer]
karmichammer has quit [Ping timeout: 256 seconds]
Algernon69 has joined #commonlisp
<beach>
nij-: An indirection through as CONS cell has the same cost as an indirection through a symbol, which is what most implementations do.
<beach>
nij-: And as Bike said, previous work used a hash-table lookup for each function call.
<nij->
And by grabbing it from a cell, do you mean the same thing as (slot-value ..) in CLOS? I'm not sure how CLOS is implemented.. but whenever (slot-value ..) is evaluated, under the hood isn't it doing a hash table lookup?
tyson2 has quit [Remote host closed the connection]
<Bike>
no, it's like a cons cell
<Bike>
like you compile #'foo as (car cell). cheap
<beach>
nij-: More like (funcall (internal-car (load-time-value (find-function-cell <name>))) arg...)
<beach>
nij-: Where INTERNAL-CAR is one instruction.
Inline has joined #commonlisp
<nij->
How does it perform #'find-function-cell ?
<nij->
I suppose there should still be a mechanism for it to look over a collection of cells, right? That doesn't make it as inefficient as a hash table lookup?
<phoe>
you are skipping the LOAD-TIME-VALUE
<phoe>
by the time INTERNAL-CAR is called at all, LOAD-TIME-VALUE has already called FIND-FUNCTION-CELL and installed the reference to the concrete Lisp object in its stead
<nij->
Tbh not fully understood yet. But notes taken. Thanks :)
<phoe>
the real work here is done by LOAD-TIME-VALUE
<phoe>
do you know how the #. syntax works?
<phoe>
being able to evaluate stuff at read-time?
<nij->
Yeah. Read that in cltl2.
<nij->
Hmm.. so the goal is to make it efficient in run-time. And the heavy work has been done before run-time..?
<phoe>
then L-T-V is very similar, except evaluation happens at load-time
<phoe>
so when you get to runtime, the heavy work has already been done, yes
<nij->
Oh great :)
karmichammer has joined #commonlisp
ec has quit [Ping timeout: 276 seconds]
<beach>
nij-: A typical Common Lisp implementation has an indirection through a symbol. The work to find that symbol at load time is the same as that of FIND-FUNCTION-CELL.
ec has joined #commonlisp
<nij->
Got it. I look forward to SICL. Thanks :)
<beach>
Pleasure.
OlCe` has joined #commonlisp
lisp123 has joined #commonlisp
<phoe>
it's fun to be a bystander to this, because I'm working on an article documenting a library utility that directly depends on LOAD-TIME-VALUE
<beach>
It is also fun to see how it is not widely known what a typical Common Lisp implementation has to do at load time in order to find the symbol corresponding to a function call in source code. Nor is it widely known how a typical Common Lisp implementation represents the global (null-lexical) environment, as opposed to the lexical compile-time environments of CLtL2.
<phoe>
I think it's generally not widely known what a typical CL implementation has to do in order to achieve X, unless you're something of an implementer yourself
<lisp123>
TIL one of the inventors of Lisp Machines (Tom Knight) has founded a company worth $17bn as last year
<lisp123>
But their IT page has only mention of JavaScript and other crap
<lisp123>
I do wonder if there is some secret LISP code in there that they are keeping a trade secret
<nij->
Sigh. I start wondering if JS is really that bad. Is there any formal argument that shows JS is inferior to Lisp?
<phoe>
I think #lispcafe will be happy to tell you that it is the former
<beach>
nij-: Programming languages can't be compared on a linear scale like that.
<beach>
And yes, off topic.
Cymew has quit [Ping timeout: 240 seconds]
lisp123 has quit [Quit: Leaving...]
attila_lendvai has quit [Ping timeout: 240 seconds]
pjb has quit [Remote host closed the connection]
shozo is now known as szos
Algernon69 has quit [Read error: No route to host]
<qhong>
beach: “On the expressive power of programming languages”
<nij->
qhong: In that paper, the author created a framework.
<nij->
I failed to get how the framework is judged..
waleee has joined #commonlisp
<qhong>
nij-: it’s just formalizing the well known notion of macro-expressibility actually
Algernon69 has joined #commonlisp
<qhong>
and it can yield bunch of sensible result, like mutation is real power, call/cc is real power, and delim/cc = call/cc + mutation > call/cc
lisp123 has joined #commonlisp
<lisp123>
Not that I plan on doing it, but is it possible to call generic functions in a eval-when form (you know the ones that run code at load time)
kevingal has quit [Ping timeout: 268 seconds]
pjb has joined #commonlisp
ec has quit [Ping timeout: 276 seconds]
<Alfr>
lisp123, the default behavior is for forms only to be evaluated when a compiled file is loaded, not when they are compiled.
zbrown[m] has quit [Quit: Client limit exceeded: 20000]
<lisp123>
Alfr: I mean this one (eval-when (:compile-toplevel :load-toplevel :execute) … )
zbrown[m] has joined #commonlisp
pjb has quit [Ping timeout: 250 seconds]
<lisp123>
Seems to work
<lisp123>
(eval-when (:compile-toplevel :load-toplevel :execute) (defgeneric test (a)) (defmethod test ((a list)) (print "test")) (test '(1 2 3)))
<White_Flame>
all functionality works at all run/load/compile-times. the question is whether or not that functionality is loaded/present at that time
karmichammer has quit [Ping timeout: 256 seconds]
<lisp123>
White_Flame: Thanks
<White_Flame>
in terms of specific defun/defmacro/defvar/etc being completed at that point
<White_Flame>
it's all the same language runtime
ec has joined #commonlisp
pjb has joined #commonlisp
<lisp123>
Makes sense
nij- has left #commonlisp [commonlisp]
<lisp123>
So as soon as the basic "CL" image is loaded, everything is kinda already in runtime?
<lisp123>
And then one loads into / compiles with against that live image?
<White_Flame>
everything standard for the implementation exists when the base image starts
karmichammer has joined #commonlisp
<phoe>
if your question is "is CL loaded after CL is loaded", then the answer is "yes"
<White_Flame>
it's a snapshot of the constructed system and has very little initialization per runtime
<lisp123>
Got it
<lisp123>
White_Flame: But now I am curious, what do you mean by "very little initalization per runtime"
<White_Flame>
(relatively speaking. it initializes the heap and whatever, but all the code is extant)
<White_Flame>
lisp123: I mean it doesn't do any loading at that point. everything was already loaded before the image was made
<lisp123>
I see
<White_Flame>
now, further REQUIRE forms might pull in more stuff from the implementation, but generally speaking it's all already there
<lisp123>
Thanks!
Cymew has joined #commonlisp
<Alfr>
lisp123, for the interaction and about what may or may nor be available/done to your running image when you compile a form or file, see
<Alfr>
lisp123, especially those parts regarding environment.
cosimone has joined #commonlisp
waleee has quit [Ping timeout: 240 seconds]
karmichammer has quit [Ping timeout: 268 seconds]
waleee has joined #commonlisp
waleee has quit [Ping timeout: 256 seconds]
szkl has quit [Quit: Connection closed for inactivity]
lispy has joined #commonlisp
ahammer has joined #commonlisp
ahammer has quit [Ping timeout: 240 seconds]
didi has joined #commonlisp
gioyik has joined #commonlisp
karmichammer has joined #commonlisp
<didi>
The last version (2.2) of SBCL eliminated my problems with ENOMEM errors. Thank you, SBCL developers. <3
<phoe>
didi: #sbcl might want to know about it too!
<didi>
Right on.
jeosol has joined #commonlisp
ahammer has joined #commonlisp
Cymew has quit [Ping timeout: 256 seconds]
lisp123_ has joined #commonlisp
lisp123 has quit [Ping timeout: 250 seconds]
ec has quit [Ping timeout: 276 seconds]
ahammer has quit [Ping timeout: 240 seconds]
karmichammer has quit [Ping timeout: 240 seconds]
lisp123 has joined #commonlisp
lisp123_ has quit [Ping timeout: 240 seconds]
Algernon91 has joined #commonlisp
Algernon69 has quit [Read error: No route to host]
karmichammer has joined #commonlisp
lisp123 has quit [Remote host closed the connection]
karmichammer has quit [Ping timeout: 256 seconds]
kevingal has joined #commonlisp
mon_aaraj has quit [Ping timeout: 250 seconds]
Inline has quit [Ping timeout: 250 seconds]
frgo has joined #commonlisp
mon_aaraj has joined #commonlisp
Josh_2 has joined #commonlisp
<Josh_2>
'ello
<phoe>
hey hi
karmichammer has joined #commonlisp
<beach>
qhong: Why are you telling me that?
mon_aaraj has quit [Ping timeout: 240 seconds]
<drakonis>
phoe: congrats on becoming a cdr editor
mon_aaraj has joined #commonlisp
<drakonis>
may lots of CDRs be written :V
<phoe>
drakonis: we'll see where this goes - CDRs need implementations much more than they need authors
<phoe>
(or editors, truth be told)
<drakonis>
that is true, yes.
karmichammer has quit [Ping timeout: 256 seconds]
<didi>
Do CDRs come with implementations?
occ has joined #commonlisp
<drakonis>
SRFIs typically do.
<didi>
Indeed. ^
<phoe>
some sometimes do, but some ideas are hard or impossible to implement in portable CL
<drakonis>
portable CL is not the same as portable scheme, sadly.
ec has joined #commonlisp
<drakonis>
some of the existing CDRs are related to runtime functionality rather than language functionality
Algernon91 has quit [Read error: Connection reset by peer]
<drakonis>
they also leave the actual implementation up to the implementors
artchad has joined #commonlisp
<beach>
Maybe I am wrong here, but if something could be implemented as portable Common Lisp code, wouldn't it just be a library rather than a CDR?
attila_lendvai has joined #commonlisp
<drakonis>
it probably could i guess?
<beach>
It seems to me that the CDR exists specifically because it can't be just a library.
<drakonis>
unless you want to roll that into the implementation to enhance it?
<didi>
Really? So it's different than SRFIs.
<beach>
I am just guessing.
<EdLangley[m]>
Some of them could
<phoe>
it seems to me that the CL ecosystem depends on de-facto libraries much more than Scheme depends on SRFIs
<beach>
drakonis: What do you mean by that?
<EdLangley[m]>
Like the one that specifies an interface for custom hash table tests
<EdLangley[m]>
Sorry, a protocol
<sm2n>
Yes, SRFIs are kind of scheme's standard library mostly; which is not an issue in CL
Inline has joined #commonlisp
<phoe>
and e.g. Ironclad has customized code that is compiled only on SBCL for performance reasons
<etimmons>
It seems CDRs are not focused on things that require implementation support.
<etimmons>
> For example, a CDR document can contain specifications of libraries, language extensions, example implementations, test suites, articles, etc.
<etimmons>
^ from the CDR home page
<drakonis>
you can either write it as a generic library that's pure scheme/CL or write an implementation that takes advantage of features provided by the implementation
<beach>
etimmons: I can believe what the home page says, but it still seems to me that the main point would be as I guessed.
<phoe>
if Ironclad was a SRFI, which it could, then it would provide some API for accessing crypto functions, and then either SBCL would ship ironclad-performance-specific code with itself as a contrib or ironclad would carry SBCL-specific code with itself
<phoe>
...and the latter is exactly what happens now!
<drakonis>
that's how it works with srfis
<etimmons>
beach: Agreed! And I thought that was the point as well until only recently
<phoe>
drakonis: so, uh
<drakonis>
i guess
<random-nick>
there was that one CDR about generic EQUALS
<beach>
etimmons: I see.
<phoe>
CL already has SRFIs, except they're named differently
<drakonis>
yes i know
morganw has joined #commonlisp
<random-nick>
that would I guess be a CDR for library writers and not for implementation writers
<phoe>
random-nick: oh yes, and I dislike it, specifically because it has no way of conveying intent (see kmp's writeup on the topic)
<drakonis>
CDRs, the suite of portability libraries called trivial-*
<pve>
Hi, is there a Zork-like game (text-based adventure) written in CL that I could study? Zork itself was written in some other dialect of lisp.
<drakonis>
hmm
<drakonis>
hold on
<EdLangley[m]>
One of the things about generic equality is that it's usually possible to right a :key function that lets you use the standardized equality predicates
<EdLangley[m]>
can't spell: s/right/write/
<drakonis>
i think there's a zil interpreter someone wrote years ago
<random-nick>
phoe: right, but it makes me wonder if presentation types could be generalised a little to allow for things such as equality, hashing, serialisation, etc.
<pve>
drakonis: Thanks for the links, I'll check those out. It doesn't necessarily have to CL code, architecture is interesting too.
<phoe>
random-nick: presentation types, you mean CLIM ones?
<phoe>
if yes, then I'm not wise in the ways of CLIM so I cannot really answer that
<random-nick>
yeah, the equality essay has a section at the end
<drakonis>
its impressive imo
<random-nick>
basically, commands are defined to accept arguments of specific presentation types and all presentations have a presentation type attached
<drakonis>
the real question here is, what can be turned into a CDR that isn't already a library everyone uses?
<random-nick>
and presentation types also have defined a way of getting accepted (other than clicking on a presentation of the given type)
karmichammer has quit [Ping timeout: 268 seconds]
<phoe>
drakonis: the real real question here is, what CDRs can be turned into a library everyone uses
<drakonis>
that's a reversal, but good point/question.
<phoe>
in particular, how to make something that's useful, as in, actually usable and used by people to solve real-world problems
<phoe>
I kinda guess that "notarizing" already de-facto standards into CDRs is the easy part and also the part that brings little overall benefit
<phoe>
the hard part is making stuff that works
<pve>
drakonis: The reason I asked (or one reason, anyway) is I'd like to find out if there are "standard" solutions to how to make creatures etc react to certain events. Say I'm in a room and drop a piece of gold. Then the greedy gnome in the same room should notice this and immediately try to grab the gold. Stuff like that.
<random-nick>
also, it would be nice if the compatibility libraries decoupled their implementation support from their main systems
<phoe>
random-nick: decoupled, as in? e.g. swank already does this
<mfiano>
pve: Dijkstra maps. That's all you need to research :)
<phoe>
it doesn't mean that you can use swank without an implementation-dependent piece of code, but the API is separated from the backend
<drakonis>
there are large features that could be lifted from the schemes
<random-nick>
mezzano has to use a bunch of patched compatibility libraries because its internal interfaces aren't stable enough to upstream the patches
<drakonis>
a cdr for something like the suite of hygienic macros?
cage has joined #commonlisp
<drakonis>
but its not something widely loved by the CL community because they all prefer regular macros
<phoe>
drakonis: that sounds mostly implementable as a standalone library on top of CL
<pve>
mfiano: thank you
<phoe>
is there anything that would require strict implementation support for that?
<EdLangley[m]>
I think you'd need enviroment information of some sort
<EdLangley[m]>
To reliably get bindings in a bit of code?
<EdLangley[m]>
Or a good code-walker
<phoe>
we have good code walkers now
<mfiano>
It's called symbol-macrolet
<phoe>
:D
<random-nick>
drakonis: well I think a lot of the use for hygienic macros isn't there in CL because of CL's package system
<EdLangley[m]>
Also, hygienic macros are harder to read, IMO
<mfiano>
Much harder
<random-nick>
where packages contain symbols instead of the scheme way of having a global symbol table and modules mapping symbols to values
<EdLangley[m]>
Especially racket's syntax-parse macros which always involve some complicated parser DSL
<qhong>
beach: so there’s a partial order at least
<didi>
You know what we need? A TAB format directive.
<qhong>
And maybe even a lattice
<didi>
Or even a TAB string literal.
<phoe>
FORMAT Tilde Backspace, the quantum format directive that erases itself the moment somebody looks
* didi
erases phoe
<mfiano>
~🐈
<random-nick>
mit-scheme has a hygienic macros system where you write macros like with defmacro but symbols which you want to be exposed to user code (like the anaphoric IT or anything similar) you include as a "syntactic closure" instead of just as the symbol object itself
<drakonis>
to be fair, racket is vaguely a scheme now
<random-nick>
such a style would be nicer imo, but still not that useful considering the package system
<phoe>
drakonis: that might already be a bit over the offtopic line
<drakonis>
yes
<drakonis>
but back to the topic at hand
<drakonis>
it is certainly hard to find something to crib from elsewhere
<didi>
Come to think about it, I would welcome a implementation extension that implemented string literals.
<phoe>
...
<phoe>
you mean like "foo"?
<drakonis>
make continuations a cdr
mgl has quit [Quit: Client closed]
<didi>
Not, like "foo\tbar" meaning "fooTABbar".
<phoe>
didi: (ql:quickload :cl-interpol)
<didi>
phoe: Thanks.
<drakonis>
that one had a library written eons ago
<random-nick>
drakonis: UNWIND-PROTECT doesn't support reentrancy
<didi>
I want batteries, not libraries!
<drakonis>
i see
<mfiano>
I would welcome an extension for extended number literal syntax
<phoe>
then (cl-interpol:enable-interpol-syntax) #?"foo\tbar"
<moon-child>
didi: you can just write tabs literally in your source code
<didi>
moon-child: I do. They are not ideal.
<moon-child>
mfiano: how would you extend the number syntax?
<phoe>
moon-child: 1_000_000_000_000_000
<phoe>
instead of 1000000000000000
<mfiano>
1_000_000 or 1000_1010_0001_1011
<moon-child>
ah yeah that would be good
<mfiano>
err #b for the last
<phoe>
that's actually one idea that sounds really suitable as a CDR
<phoe>
because of the "possible number syntax" part of the spec that could kinda allow it
<phoe>
continuations could be a CDR, too - I've seen a few discussions about how to solve the U-P reentrancy problem
<random-nick>
it was a feature on some old lisp I remember reading about, basically defining a lambda macro FOO would get called when you do something like ((FOO BAR) BAZ)
<random-nick>
s/defining //
<phoe>
oh, so extra syntax for when an operator call argument is a list - like ((lambda ...) ...) is supported in standard CL
<drakonis>
lexical macros?
<phoe>
drakonis: you mean MACROLET?
<didi>
phoe: If I recall correctly, schemers don't like continuations no more. Apparently "delimited continuations" are the way to go. I understand neither.
<mfiano>
lexical generic functions
<EdLangley[m]>
Yeah, continuations aren't really as useful
<mfiano>
phoe: I read the code and the use of LOAD-TIME-VALUE makes me question its usefulness
lispy has quit [Quit: Leaving]
<phoe>
hmmmm
<phoe>
I think I have an idea
<phoe>
make the GF itself a load-time-value, but initialize the GF by adding methods to it the moment control first reaches it
<phoe>
this will allow the method functions to freely capture lexical environment
<phoe>
kinda sorta just like the thing I'm doing with Serapeum's STATIC-LET right now
<EdLangley[m]>
Yeah, I think that works
* phoe
adds to his TODO list
<EdLangley[m]>
Although, the problem you might run into is a memory leak
<phoe>
where exactly?
<EdLangley[m]>
If the methods aren't cleaned up
<phoe>
they don't need to be cleaned up though
<phoe>
just like a "normal" GF's methods aren't cleaned up
<EdLangley[m]>
Every time you add a method to the L-T-V generic function, the size of the generic function increases in memory
karmichammer has joined #commonlisp
<phoe>
this is why I only want to do this once
<phoe>
and the moment I reevaluate a form containing L-T-V, a new GF will get created
<EdLangley[m]>
If the method has an EQL specializer on a lexically-created object, the generic function will pin the method and the method will pin the object
<phoe>
and the old GF will eventually get collected
<EdLangley[m]>
At the very least, the generic function will pin the method
<EdLangley[m]>
> the moment I reevaluate a form containing L-T-V
<phoe>
yes, but this isn't a problem if the GF becomes unreachable, right?
Jing has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
tyson2 has joined #commonlisp
<EdLangley[m]>
Yeah, but (loop repeat 1000 do (something-with-anonymous-gf)) will leak
<EdLangley[m]>
reevaluating the definition of SOMETHING-WITH-ANONYMOUS-GF only really happens during development
<phoe>
that's why I only want to initialize the GF once
<phoe>
that is, add the methods once, and then never do it again
<phoe>
and I know how to do that
<EdLangley[m]>
In production, the generic function will last forever
<EdLangley[m]>
I think I need a pastebin to explain the problem :)
<EdLangley[m]>
If the generic function is created by generic-flet is created once, at load time
<EdLangley[m]>
Then it's possible to implement the (:method ...) part in a way that that EQL specializer adds a new method every time the function runs
<EdLangley[m]>
So, first of all, you'll have an indefinitely growing collection of methods attached to the l-t-v generic function
<EdLangley[m]>
And the EQL specializer of each method will keep an instance of BIG-OBJECT alive as well
<EdLangley[m]>
So, basically, you need an UNWIND-PROTECT to cleanup the methods
<phoe>
yes, I see
lisp123 has joined #commonlisp
<phoe>
still, sounds doable
<lisp123>
For some reason, every time I restart my Lisp image, I need to reset the ASDF configuration to load a recently defined pacakge
<lisp123>
Sounds like an error on my side?
vats has joined #commonlisp
<lisp123>
Fixed it - Ignore me!
<Bike>
if nothing else, you could probably reset or whatever in your rc
<Bike>
too late!
<Bike>
so: are we bringing back generic-flet
<lisp123>
:D
<phoe>
Bike: kinda sounds like it!?
<Bike>
i've never quite understood what it would be good for, so i'd be interested in seeing usage
<EdLangley[m]>
I find generic-lambda more interesting
<phoe>
generic-lambda would simply return an instance of GENERIC-FUNCTION, right?
<phoe>
an anonymous one
<EdLangley[m]>
For me, at least, it's more a nicer syntax for a typecase inside a lambda, when you're mapping over a bunch of objects of different types
<phoe>
the main issue is closing over stuff
<EdLangley[m]>
Yeah
<EdLangley[m]>
The main difference with a typecase is you can use :around and stuff
<EdLangley[m]>
I have a sample somewhere...
<phoe>
sounds doable then - the main issue is avoiding multiple compilations I guess
<phoe>
so, like, try to compile the method functions once, and then just close over the arguments that the GF needs to close over
<phoe>
that's the main performance hurdle I see
<EdLangley[m]>
the issue I ran into was figuring out how to capture the lexical environment correctly
<phoe>
this, and EQL specializers
<EdLangley[m]>
but, I was trying to do it through the MOP rather than using DEFGENERIC and friends
<phoe>
doing it through the MOP should also be viable I think
<phoe>
the main hurdle I see is COMPILE being a butt in presence of lexical bindings, if we want to be strictly compliant
<phoe>
which is an issue me and Bike talked about some time ago here
<phoe>
s/the main hurdle/a minor hurdle/
<phoe>
but, yeah, even if we go through the MOP, that should be doable
<phoe>
I mean, if DEFGENERIC can properly capture the lexical environment, then the MOP must be able to as well
<EdLangley[m]>
Yeah, I couldn't figure out how to make the stuff inside COMPILE able to access the lexical enviroment
<EdLangley[m]>
But, I was probably doing something wrong
<phoe>
that's the neat thing, you don't
<phoe>
special opeartor FUNCTION itself must access the lexical environment; if anything, you just COMPILE whatever is the result of it
<phoe>
in particular, (FUNCTION (LAMBDA ...)) must access it
<phoe>
and you need to compile the function object that pops out when you evaluate a call to FUNCTION
<EdLangley[m]>
Hmm, maybe that works
<mfiano>
Can I change the displaced-index-offset of an existing displaced array object to be able to updated the displaced-to array at different locations without constructing multiple displaced arrays?
<mfiano>
I don't work with displaced arrays much at all. Thanks
<phoe>
this, and there's the interaction with MAKE-METHOD-LAMBDA that needs to be taken into account
<EdLangley[m]>
I remember I spent a long time looking at the macroexpansion and definition of DEFMETHOD trying to figure this out
<phoe>
mfiano: doesn't seem possible, ARRAY-DISPLACEMENT is a reader and not a writer
<mfiano>
That makes me sad
<phoe>
EdLangley[m]: I think the macroexpander needs to call MAKE-METHOD-LAMBDA and splice the result of calling it into the macroexpansion
<phoe>
then the compiler will be capable of making lexical closures
Catie has joined #commonlisp
<phoe>
hmmmmm, this actually seems doable
<EdLangley[m]>
I think ADJUST-ARRAY can change the displacement
<Bike>
the rules for this are a large part of the definition, even, since it's kind of complicated
<EdLangley[m]>
I used this a couple times to slide a window over a string
<mfiano>
Does asjust-array specify if a new array object is created or if the index pointer is moved?
<Bike>
also, yes, for generic-flet you'd want to go through the make-mmethod-lambda rigamarole and avoid actually calling COMPILE.
Major_Biscuit has quit [Ping timeout: 250 seconds]
<Bike>
mfiano: a new object is only created if the array isn't "actually adjustable". you can assure an array is actually adjustable by specifying :adjustable t in make-array.
<mfiano>
Ok, and I can make the displaced array adjustable without affecting the displaced-to simple-array?
<Bike>
Yes. You're not actually altering the underlying array in any way.
<mfiano>
This is excellent. I just found a really good use for displaced arrays for once.
<mfiano>
Thank you!
<Bike>
No problem
karmichammer has joined #commonlisp
rain3 has quit [Ping timeout: 268 seconds]
karmichammer has quit [Ping timeout: 240 seconds]
Algernon91 has joined #commonlisp
szkl has joined #commonlisp
AeroNotix has joined #commonlisp
karmichammer has joined #commonlisp
azimut_ has joined #commonlisp
azimut has quit [Ping timeout: 276 seconds]
karmichammer has quit [Ping timeout: 250 seconds]
dra has joined #commonlisp
Algernon91 has quit [Ping timeout: 268 seconds]
mmk2410 has joined #commonlisp
mmk2410_ has quit [Ping timeout: 256 seconds]
karmichammer has joined #commonlisp
Algernon91 has joined #commonlisp
kevingal has quit [Remote host closed the connection]
waleee has joined #commonlisp
karmichammer has quit [Ping timeout: 256 seconds]
karmichammer has joined #commonlisp
Algernon91 has quit [Ping timeout: 268 seconds]
attila_lendvai has quit [Ping timeout: 250 seconds]
didi has quit [Ping timeout: 240 seconds]
karmichammer has quit [Ping timeout: 268 seconds]
lisp123 has joined #commonlisp
lisp123 has quit [Ping timeout: 240 seconds]
mon_aaraj has quit [Ping timeout: 240 seconds]
mon_aaraj has joined #commonlisp
varjag has quit [Quit: ERC 5.4.1 (IRC client for GNU Emacs 29.0.50)]
karmichammer has joined #commonlisp
karmichammer has quit [Ping timeout: 240 seconds]
raeda has quit [Read error: Connection reset by peer]
raeda_ has joined #commonlisp
amb007 has quit [Ping timeout: 250 seconds]
amb007 has joined #commonlisp
karmichammer has joined #commonlisp
karmichammer has quit [Ping timeout: 240 seconds]
pieguy128_ has quit [Ping timeout: 240 seconds]
amb007 has quit [Ping timeout: 256 seconds]
amb007 has joined #commonlisp
xantoz has joined #commonlisp
pieguy128 has joined #commonlisp
varjag has joined #commonlisp
karmichammer has joined #commonlisp
lispy has quit [Quit: Leaving]
mon_aaraj has quit [Ping timeout: 268 seconds]
mon_aaraj has joined #commonlisp
Oladon has quit [Quit: Leaving.]
Oladon has joined #commonlisp
amb007 has quit [Ping timeout: 256 seconds]
amb007 has joined #commonlisp
mgl has quit [Quit: Client closed]
cage has quit [Quit: rcirc on GNU Emacs 27.1]
aartaka has quit [Ping timeout: 250 seconds]
ec has quit [Ping timeout: 276 seconds]
Inline has quit [Ping timeout: 250 seconds]
ec has joined #commonlisp
parjanya has joined #commonlisp
karmichammer has quit [Ping timeout: 268 seconds]
ec has quit [Ping timeout: 276 seconds]
Colt has quit [Quit: Leaving]
wheelsucker has quit [Remote host closed the connection]
mgl has joined #commonlisp
karmichammer has joined #commonlisp
lisp123 has joined #commonlisp
lottaquestions_ has quit [Remote host closed the connection]
lottaquestions_ has joined #commonlisp
lisp123 has quit [Ping timeout: 268 seconds]
xsperry has quit [Ping timeout: 256 seconds]
Inline has joined #commonlisp
Dynom has quit [Quit: WeeChat 3.4]
<phoe>
EdLangley[m]: it won't work
<phoe>
or, rather, it will only work if we can detect that the GF is DX
<phoe>
imagine (generic-flet ((foo ... )) #'foo)
<phoe>
if there are EQL-specialized methods, UNWIND-PROTECT will remove them
<phoe>
and if any method closes over an argument, then we're screwed, because we need to return different objects for different closures - so we cannot preallocate a single LOAD-TIME-VALUE GF, we need to create them from scratch
<phoe>
...but the good news is, we can expand GENERIC-FLET into a FLET of method functions and have these precompiled - we only need to create the method and GF metaobjects, add methods to the GF, and FBIND the GF - and we're good to go
artchad has quit [Read error: Connection reset by peer]
<phoe>
and, if we can detect that the local function is DX (either via a user declaration or by code-walking, if we do not notice any FUNCTION calls referring to that free function binding) then we can use the optimized approach with a single LOAD-TIME-VALUE GF and, in case of closures via EQL specializers, adding or removing methods on entry/exit of dynamic scope
dilated_dinosaur has quit [Ping timeout: 256 seconds]
dilated_dinosaur has joined #commonlisp
<Bike>
so generic-flet only ever makes a new function, rather than adding to an existing one?
<phoe>
adding to an existing one? what do you mean?
<phoe>
even the CLtL2 GENERIC-FLET always creates new local GFs, it doesn't augment any preexisting ones
<phoe>
and I assume that we are aiming for a CLtL2esque API here
<EdLangley[m]>
Yeah, I think dynamically changing the methods of a pre-existing generic function is asking for sadness
<Bike>
i see
<phoe>
EdLangley[m]: actually I think it is possible, BUT
<phoe>
that GF must be DX - it cannot escape the dynamic scope
<Bike>
just wondering, since i still don't have a good understanding of what this is for
<phoe>
because then we can preallocate a single GF along with N methods and just switch their guts around on demand
<phoe>
Bike: AFAIK it's syntax sugar + optimization chances over creating anonymous GF objects and using these
<EdLangley[m]>
On reflection, anonymous GFs aren't very useful because the reason to use a GF is to let 3rd party code interoperate with your own code
<EdLangley[m]>
By extending your protocol
szos is now known as shozo
<EdLangley[m]>
But, if the GF is defined hidden inside a function, there's no way to do this.
<phoe>
by this logic, neither are lexically scoped GFs
<EdLangley[m]>
So, it just becomes a slow TYPECASE
<phoe>
yep
<EdLangley[m]>
Anonymous classes might be useful, though
scymtym has quit [Remote host closed the connection]
<phoe>
unless you add metaclasses into the mix to get some customized slow TYPECASE
<EdLangley[m]>
To implement a protocol inside a function
<phoe>
and we come back to CLASS-LET!
<EdLangley[m]>
Of course, in Java, anonymous classes mostly exist so you can do callbacks
<phoe>
in Java, methods belong to classes; we don't do that here
shka has quit [Ping timeout: 240 seconds]
dre has quit [Quit: Leaving]
dre has joined #commonlisp
<phoe>
so I think it should be possible to write (and even optimize) GENERIC-FLET and GENERIC-LABELS using portable CL, MOP, and a code walker to detect FUNCTION calls; GENERIC-LAMBDA is also obviously possible
Algernon69 has joined #commonlisp
<phoe>
the question is, do we have any practical reasons other than going full Cave Johnson on this
<phoe>
and by Cave Johnson, I mean, quote, "Science isn't about WHY. It's about WHY NOT. Why is so much of our science dangerous? Why not marry safe science if you love it so much."
<Bike>
the lack of extensibility is basically what i was wondering about yeah
<Bike>
and i think that was one of the reasons generic-flet/labels was originally removed?
<phoe>
yes
<Bike>
along with "nobody understands what the heck this is"
<phoe>
yes
<phoe>
I mean, you could in theory grab a local GF object via #' and then forcibly ADD-METHOD some stuff into it
<phoe>
the question is, again, why
<EdLangley[m]>
A lot of the generic-flet stuff could probably just be written as a fancy macro for a typecase
<phoe>
yes, and then maybe some people would enjoy the local :METHOD syntax and qualifiers for method combinations
dra has quit [Remote host closed the connection]
<EdLangley[m]>
Yeah, but a lot of that stuff could be done statically during macroexpansion
<phoe>
in the most general case? yes
<phoe>
you should be able to statically analyze this, especially if no qualifiers are used, and just turn this into a non-generic function with a big ole TYPECASE inside
Oladon has quit [Quit: Leaving.]
<phoe>
and optionally fall back to standard MOP wizardry in case any unrecognized options are present, e.g. a custom metaclass
<phoe>
...or #'CALL-NEXT-METHOD
<phoe>
I have no idea how a single TYPECASE would handle that
cosimone has quit [Quit: ERC (IRC client for Emacs 27.1)]
lisp123 has joined #commonlisp
<phoe>
crazy stuff
lisp123 has quit [Ping timeout: 240 seconds]
dra has joined #commonlisp
AeroNotix has quit [Quit: WeeChat 3.4]
Jach has quit [Read error: Connection reset by peer]
karmichammer has quit [Ping timeout: 250 seconds]
<Bike>
fbind a function of one argument for each "method". have that one parameter be #'call-next-method. the typecase calls a method appropriately
<phoe>
hmm
<phoe>
yes, that works
occ has quit [Ping timeout: 256 seconds]
<Bike>
next-method-p is a little more involved but not much. passing no-next-method a method would be trickier
karmichammer has joined #commonlisp
Algernon69 has quit [Read error: Network is unreachable]
Jach has joined #commonlisp
scymtym has joined #commonlisp
pjb has joined #commonlisp
kevingal has joined #commonlisp
dra has quit [Remote host closed the connection]
akoana has joined #commonlisp
<dbotton>
Is there a convention used in code for a variable named "this" or "self" by Common Lispers?
<Bike>
i don't think so. generic functions are not strongly tied to any argument in particular.
<phoe>
dbotton: what do you mean by "this"?
raeda_ has quit [Quit: Leaving]
<dbotton>
similar to C++ this that refers to the object that a method was called on
<phoe>
which one?
<phoe>
like, in (defgeneric foo (bar baz quux)), do you mean BAR, BAZ, or QUUX?
<dbotton>
likely bar - even though in CL it could be all of them
<phoe>
that's the thing, it could be any of them
<phoe>
so, the notion is to call BAR, well
<phoe>
BAR
<dbotton>
Since this is in code that is generated for the user, originally I did that
dre has quit [Ping timeout: 240 seconds]
<phoe>
I think that generating code for the user is going to be harmful if it teaches the user that there is some sort of "self" in methods
<dbotton>
however since the name of BAR can change with a configuration change it means every thing has to generated again
<EdLangley[m]>
Some things like PRINT-OBJECT use OBJECT or similar for the parameter the user is expected to specialize
<EdLangley[m]>
PRINT-OBJECT disallows specializing on the stream, iirc
<phoe>
"methods should therefore not depend on the identity of this stream." is the only thing that's mentioned
<EdLangley[m]>
Yeah, sbcl warns because of that
<dbotton>
well object is already being used
<EdLangley[m]>
but, if you can't depend on the identity of the stream, you can't rely on it being the class you expect it to be
<phoe>
ooh
<phoe>
yes, I see
<phoe>
that makes sense
<EdLangley[m]>
e.g. the pretty printer will wrap the stream with internal classes
<mfiano>
initialize-instance uses INSTANCE
<phoe>
dbotton: the main issue I see is, what meaning do you want to convey - argument names can be completely dumb like ARGUMENT-1 ARGUMENT-2 ARGUMENT-3 and so on, but they are meaningless
<phoe>
if you are telling the user to configure something, use the argument names to tell them what they are configuring
<dbotton>
I could use "panel" and that would avoid phoe's issue of bad "lesson" in self/this
<phoe>
and what kind of operations they should be able to perform there
<mfiano>
Just name it what the most specific thing that it can be, not something generic like THIS or SELF that has a single-dispatch connatation
<phoe>
^
<mfiano>
Hell I'd use single letters over that. That would send the wrong message to a newcomer.
<dbotton>
so panel it is.
kevingal has quit [Remote host closed the connection]