freenode/#lisp - IRC Chatlog
Search
1:37:12
aeth
To complicate things a bit, you'd want one of the symbol conflict resolution options to be "don't use the latest, use this specific version instead"
1:37:43
aeth
So if you USE my-package and it stops working because of a symbol conflict (and, yeah, USE is bad in general), then you can just use my-package.2 or whatever.
1:41:58
fiddlerwoaroof
Personally, I tend to distinguish "code that I might eventually put into quicklisp" from "application code"
1:42:17
fiddlerwoaroof
And only use implementation-specific features in the latter sorts of projects
3:35:07
mfiano
https://common-lisp.net/project/asdf/asdf/The-package_002dinferred_002dsystem-extension.html
6:13:09
beach
frodef: See http://metamodular.com/SICL/environments.pdf for a description of first-class global environments.
6:13:14
troydm
okey this might sound like a dumb question but it seems that there are two local-projects directories when using roswell
6:20:15
troydm
it seems like top level local-projects directory is not part of ql:*local-project-directories*
6:26:27
troydm
or rather roswell adds ~/.roswell/local-projects to ASDF registry but not ql:*local-project-directories*
6:32:34
troydm
moon-child: I do use slime, but sometimes I start repl just to quickly check something
6:53:06
fiddlerwoaroof
Tab complete for symbols and M-i for documenting the current symbol is pretty handy
6:54:15
fiddlerwoaroof
As for "why": I occasionally use lisp on servers where I don't have emacs installed
6:54:52
fiddlerwoaroof
And, if I'm already doing stuff at the shell, sometimes it's easier just to use the REPL in the context of my current session rather than context-switching into emacs
7:01:22
no-defun-allowed
Although a touch convoluted, you could start SWANK on the server, then use SSH to port forward and M-x slime-connect to that.
10:05:43
sauvin
in sbcl, I'm suddenly getting hit with an "undefined variable" error or warning when I try (setq a '(1 2 3 4 5)). What could be wrong?
10:06:35
phoe
define your variables before setting them - globals via DEFVAR or DEFPARAMETER, locals via LET or LET* or the other utilities for binding
10:07:25
sauvin
Yeah, well, folks in this channel about 24 hours ago told me about that, which is why I'm asking. Worked in gcl, ain't working in sbcl, wtf!?
10:10:02
phoe
it's a good thing on one hand, and on the other, it has caused a fair share of breakages in libraries that were working before but then SBCL found ANSI CL conformance bugs in them
10:11:40
sauvin
Well, see, this was one of the reasons the folks here gave yesterday for me to move to sbcl: more conformant to the standard.
10:13:12
phoe
the question with SETQ on symbols always is: where is this particular symbol defined to be a variable?
10:13:37
beach
sauvin: It's kind of the other way around. It "works" in SBCL, since it signals a warning, and it does not "work" in GCL because it lets a detectable undefined situation pass silently.
10:17:34
sauvin
Because I don't understand it. I'm just now learning how to assign variables in lisp, and it's a lot more complex than in perl, and it's more complex than in the AutoLISP that I used to use heavily but haven't seen in twenty years.
10:18:12
no-defun-allowed
You are going to understand it even less, if you attempt to intentionally break it.
10:18:30
sauvin
So, anyway, let works at the top level. I'm a big fan of lexical variables anyway. I avoid globals wherever I can.
10:18:41
beach
sauvin: How is (setq <variable> <value-form>) more complex than <variable> = <value-form>?
10:19:39
no-defun-allowed
You are not breaking anything with LET. You're also not really breaking things with SETQ on undefined variables on its own, but attempting to dispose of the warnings your implementation makes for using SETQ in that way is breaking it.
10:19:59
no-defun-allowed
my $thing = ... would be like wrapping the rest of the body in (let ((thing ...)) ...)
10:20:20
phoe
declaring local variables in Lisp is done via LET and LET* and some other similar operators
10:21:16
no-defun-allowed
However, note that DEFVAR and DEFPARAMETER are always used to declare special variables, which are dynamically scoped. I think Perl is another one of the few languages with dynamically scoped variables.
10:22:03
no-defun-allowed
Yes, DEFUN, DEFPARAMETER and DEFVAR usually don't do what you want them to do, if you put them inside a function body.
10:22:08
sauvin
perl DOES have dynamically scoped variables, but there are very few circumstances under which their use encouraged.
10:22:49
no-defun-allowed
That is not so far off in Lisp; you use lexically scoped variables by default, but dynamic scoping is useful for cross-cutting "customization" of things.
10:23:21
sauvin
Yes, and i perl, I'd have to have some pretty convincing reason to use 'local', which means 'dynamic'.
10:24:39
sauvin
I'll look at that later. For now, many years spent swearing at the machine (and destroying more than one keyboard in the process), I tend to disfavour global variables. I just wind up tripping over them.
10:25:02
no-defun-allowed
For example, you can re-bind *standard-output* to send printed text somewhere else (provided it is printed to *standard-output*).
10:26:28
sauvin
Had to do that already. *default-external-format* defaults to utf-8, but trying to read a couple of files I have caused sbcl to puke, so I had to change that variable to ISO-mumble.
10:27:10
no-defun-allowed
But I use a fair few global variables in my work, mostly to put weak hash tables somewhere, so that I can de-duplicate objects I use.
10:27:28
phoe
and use dynamic variables either for passing context information along your call stack, and almost only for that.
10:28:28
sauvin
I tend to prefer passing parameters. Dynamic variables (in my other-language experience) are just another morass.
10:29:35
phoe
(with-output-to-string (*standard-output*) ...) hijacks the output stream and returns everything that was printed as a string
10:30:24
phoe
(let ((*package* (find-package :keyword))) (prin1 x)) prints X with all symbols being fully qualified, so with all package prefixes
10:30:53
phoe
it can contain functions which call functions which call functions which print to standard output
10:31:16
phoe
and, no, they aren't printing to standard output anymore; they're printing into the stream that collects stuff into a string
10:32:55
phoe
(defun foo () (princ :asdf)) (with-output-to-string (*standard-output*) (princ :qwer) (foo) (princ :zxcv))
10:32:56
no-defun-allowed
I am aware that Haskell (or GHC maybe, who can tell the difference) has dynamic binding, so they're not totally useless.
13:10:52
heisig
If I had a nickel for every bug I introduced because I closed over a LOOP variable, thinking it would create a fresh closure for each iteration, I'd have have two nickels. Which isn't a lot, but it's weird that it happened twice.