libera/commonlisp - IRC Chatlog
Search
8:18:01
ns12
Why do Common Lispers tend to (:use :alexandria) instead of using package local nicknames or using the full form (e.g. #'alexandria:extremum)?
8:22:22
ns12
Before the existence of PLN, why didn't CL programmers use the full name of Alexandria symbols (e.g. #'alexandria:extremum)?
8:23:46
ns12
"the symbol names are pretty importable and very commonly used" - Oh. Sorry. It didn't click for me. What do you mean by symbol names being "importable"?
8:23:50
White_Flame
it is recommended style to use PLNs for ease of use nowadays. the actual abbreviation is up to you
8:24:15
White_Flame
they don't conflict, as they're named pretty globally appropriately to what they do
8:24:53
White_Flame
and if you have your own personal suite of library functions that do conflict with alexandria, it's recommended to use alexandria instead and standardize your code
8:25:01
ns12
"it's effectively treated as an extension to the standard CL functions" - I guess this is the answer.
8:26:32
White_Flame
yep, but I do predict that a: will become more used as people port things to and write new things with PLNs
8:28:57
ns12
Suppose I am using library X, which USEs function F from Alexandria. If I USE Alexandria in my main program and accidentally define my own function having the same name as function F from Alexandria, will there be disaster?
8:30:38
White_Flame
your (defun f () ..) will read as (cl:defun alexandria:f () ...), and your defniition will overwrite it (unless you reload alexandria later)
8:32:35
ns12
"your (defun f () ..) will read as (cl:defun alexandria:f () ...)" - Why does this happen? When I USE a package, its symbols are merged into the current package's symbol table?
8:35:22
Krystof
using two packages that export different symbols with the same name leads to conflict
8:35:42
moon-child
(this is one reason why it is no longer considered good practice to use packages, and use of PLNs is encouraged)
8:37:07
ns12
"your (defun f () ..) will read as (cl:defun alexandria:f () ...)" - Is there a way to display this interactively? As in "(defun f () ..)" -> "(cl:defun alexandria:f () ...)"
8:38:04
Krystof
(let ((form (read-from-string "(defun f () ...)")) (*package* (find-package "KEYWORD"))) (prin1 form))
8:44:16
pjb
(let ((form (read-from-string "(defun foo (x) (if (minusp x) (- x) x))"))) (let ((*package* (find-package "KEYWORD"))) (print form))) #|
8:44:16
pjb
(common-lisp:defun common-lisp-user::foo (common-lisp-user::x) (common-lisp:if (common-lisp:minusp common-lisp-user::x) (common-lisp-user::- common-lisp-user::x) common-lisp-user::x)) --> (defun foo (x) (if (minusp x) (- x) x)) |#
8:45:07
pjb
(let ((form (read-from-string "(foo if :keyword)"))) (let ((*package* (find-package "KEYWORD"))) (print form))) #|
8:45:28
pjb
you don't get a keyword: prefix, but keywords are still printed as :keyword so it's clear.
8:47:59
ns12
I see, out of the three standardized packages, only the keyword package is suitable causing the printing of prefixes. http://www.lispworks.com/documentation/lw50/CLHS/Body/11_ab.htm
14:56:41
phoe
Which part of the specification mentions that (MULTIPLE-VALUE-CALL (LAMBDA (ONE TWO) (LIST ONE TWO)) (VALUES 1 2 3)) should be an error?
15:12:23
ns12
Is it valid to add a particular keyword to *features* more than once? e.g. (push :foo *features*) (push :foo *features*)
15:17:04
ns12
Is it conventional to prefix custom feature symbols with the name of the library that adds the feature symbol to *features*?
15:47:41
_73
The symbol that denotes the condition type is internal, so I get an undefined symbol error.
15:48:49
beach
Symbols can not be undefined. If the symbol is internal, you need to use a double package marker to refer to it. That's not great with respect to modularity, but that's what you need to do.
15:49:14
pjb
You don't even have to use the right symbol in the handling form, if you know a superclass of those conditions that is named in another package!
15:50:03
pjb
(define-condition foo::condi () ()) (define-condition bar::error (foo::condi) ()) (handler-case (will-signal-bar-error) (foo::condi (err) (handle-bar-error-here err)))
15:50:12
_death
you can also consider whether the name should actually be external and if so export it and possibly submit a patch
15:53:29
phoe
maybe the condition itself is something like si::simple-reader-error and you are actually supposed to handle cl:reader-error instead
15:53:56
phoe
or maybe somebody forgot to export the condition name/accessors if it's some publicly available library, which would warrant a bugticket
15:55:23
phoe
in particular, package LEXER should export lex-error along with lex-error-{reason,line,source}
15:57:02
phoe
for whatever reason people tend to forget that conditions and their accessors are also a part of a library's API