libera/#commonlisp - IRC Chatlog
Search
14:20:39
gilberth
nij-: Indeed. This is on purpose. You need to type at least three chars iirc. This apropos interface is not obvious though. You can type e.g. "+ fun" or "+ va". Or e.g. "mu bind". Also it lacks keyboard navigation. Thanks for noting!
14:22:29
beach
I would also be interested in finding an X3J13 issue that was not approved, but is listed in the Common Lisp HyperSpec.
14:24:54
beach
nij-: Yes, but it would prove my point that those issues are not related to any difference between the Common Lisp HyperSpec and the standard.
14:24:56
mrcom
nij-: beach *is* a language lawyer, by choice and profession. Which is an important thing for the ecosystem. Without procesion we would have Perl. Or YAML.
14:27:13
beach
I think it is important for the purpose of communication to use some consistent terminology, especially if that terminology is defined by the standard.
14:29:03
mrcom
It is. And since human communication naturally "drifts" concepts and terms, it's important for someone to yank terminology back.
14:30:07
mrcom
That's not going to keep people from naturally saying "object" when referring to instances of stuff that meats the CLOS protocols. Nor should it.
14:34:18
beach
The problem with "CLOS object" is that it can mean either a standard object (i.e., an instance of the class STANDARD-OBJECT) or an instance of a standard class (i.e., an instance of an instance of the class STANDARD-CLASS) and they are not the same.
14:35:18
beach
The problem with "CLOS class" is that classes were introduced to Common Lisp as a result of incorporating CLOS, so every class can reasonably be thought of as a "CLOS class".
14:53:41
mrcom
beach: OK, I've thought about it, and you were right to correct me about "thing" and "object". It's OK, and good to couch unfamiliar concepts by way of other familiar but fuzzy concepts,
15:01:43
bike
that means your code has a problem (specifically, that problem). it will load but if you ever actually run the code the problem is in you'll get an error.
15:02:01
bike
asdf treats warnings as failures by default, but you can still load the fasl if you don't mind that your code is wrong.
15:04:34
bike
emaczen: that is what a derived type is, yes. asserted type means something declared. this might not be a declaration you wrote. for example you'd get a warning like that if you wrote (nth n sequence) where sequence is derived to be a vector, since NTH asserts that its argument is a list.
15:16:31
bike
sort itself can take a vector fine, so the problem is something else about the call, probably
15:51:27
emaczen
if I change mapcar to map 'list with sort being a subform it works. SBCL is making me change my code on multiple places
15:52:34
bike
if you give it a vector, it returns a vector. so (mapcar foo (sort vector ...)) will not work, as you are calling mapcar on a vector.
15:53:24
bike
mapcar only accepts lists. map accepts any kind of sequence, so using it instead of mapcar should be fine
15:54:29
emaczen
Yeah, so why would SBCL give an error then? Is it just mad because sort could return a non list sequence?
15:59:07
aeth
The compiler is (almost) always right... it's returning a vector. Maybe it couldn't detect this at compile time (instead of at runtime) until a relatively recent version.
16:02:28
bike
the compiler is probably right, but sbcl sometimes indicates its rightness inscrutably
16:02:54
beach
emaczen: I think it is hard to tell anything from that code. Plus, the indentation is off. Your code may contain TABs.
16:03:53
bike
it doesn't seem immediately problematic. SBCL says the warning is specifically on the SORT line? not the mapcar, for instance?
16:05:16
bike
the if is also redundant, since hash-values checks if the hash table is nil. but that's probably unrelated to the warning
16:05:17
beach
emaczen: IF should always have both branches, because if it is used for value, then it is good style to include both branches, and if it is not used for value, it should be replaced by WHEN or UNLESS.
16:06:20
emaczen
I probably have the if there when I got an error and tried a few things and never took it out.
16:06:46
beach
emaczen: And (WHEN HT is a direct violation of the rules stated on page 13 of the LUV slides by Norvig and Pitman.
16:07:39
beach
emaczen: The indentation is probably off for other reasons as well, because COLLECT is not aligned under FOR.
16:26:59
bike
well, i can compile this code with no warnings, if i use identity functions and have the mapcar be the entire body of a function
16:32:05
emaczen
conflicting with its asserted type LIST -- possible declarations on children? children is the accessor to a slot named children
16:32:40
bike
there's also the fact the warning refers to a variable named SEQUENCE, which is not apparent in your code
16:40:28
emaczen
Thanks for looking -- I think it is worth forgetting about and to just use map 'list
16:55:59
flip214
Is there a codewalker library that allows to wrap each value form (so in PROGN, variable bindings in LET, etc.; recursively) in some code?
16:56:26
flip214
Ie. Is there a library that I pass some form and a function and the function is called with each value form therein?
17:12:10
nij-
Will WSCL issues ever get "integrated" into dpANS3? Or it's planned to have them remain as independent patches?
18:02:06
beach
nij-: They are already integrated in (at least one version of) the document created by scymtym that is at the same "level" as the Common Lisp HyperSpec and the Nova Spec.
18:04:00
nij-
Oh! For example - https://github.com/s-expressionists/wscl/commit/04da4ec2cdcb58beab386e5d98bb3eb9b3731048#
18:05:08
beach
That's how we format the WSCL issues so that they will have the same format as the X3J13 issues, but that's not the document I was talking about.
23:42:04
yitzi
attila_lendvai: wscl is aimed at specifying the unspecified aspects of CL, not changing the behavior or adding extensions.