libera/#commonlisp - IRC Chatlog
Search
13:35:39
beach
nij-: By a "datum" it means anything that can be the value of a variable, that can be passed as an argument to a function call, and that can be returned as the value of a function call.
13:36:49
scymtym
i think the question of an "undefined object" doesn't come into play, at least in this context, since the consequences of "reading an uninitialized element of new-array" are already undefined. the operator, for example AREF, doesn't have to return anything at alla. the implementation could just crash
13:37:21
beach
nij-: You are absolutely right. There should be a distinction between "element" as a placeholder of an object and the object contained in that placeholder.
13:38:06
beach
It is the placeholder that may be uninitialized, meaning it does not necessarily contain a valid object.
13:41:13
nij-
But I think what it really means would have been much clearer if they defined "a placeholder" notion in the array. Alas that's not mentioned either.
13:41:52
scymtym
https://novaspec.org/cl/26_1_Glossary#access and https://novaspec.org/cl/t_cell-error could be relevant
13:45:48
beach
Well, I just defined it as "anything that can be...", but then you need to define "thing".
13:45:50
nij-
scymtym Thanks! In #access, it links to #element, which says explicitly "2. [an element] (of an array) an object that is stored in the array."
13:47:46
scymtym
nij-: sure. i'm just pointing out related concepts since you said you wanted to write up an issue. CELL-ERROR talks about "location access" which seems like a good phrasing of the operation that triggres the undefined consequences in the contet of MAKE-ARRAY
13:55:53
nij-
! Any place that documents which X3J13 issues are in the standard, and which are not?!
13:57:24
beach
I also said that the Common Lisp HyperSpec is for all practical purposes the same as the standard.
13:59:24
nij-
"These issue writeups, while not part of the Common Lisp specification, are nevertheless useful for understanding original intent." http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec/FrontMatter/X3J13-Issues.html
14:00:00
bike
when you file a bug on github, and the bug gets fixed, you don't just incorporate the text of the issue into your program
14:00:22
bike
the issue says "hey, let's fix X by doing Y in the standard" and then Y ends up in the standard
14:01:43
mrcom
nij: Unfortunately, there are only two ways (that I can think of) to define something: either a) equate it to some other classification term, hopefully one you're familiar with :)
14:02:55
mrcom
"Datum", unfortunately, isn't a classification term that is widely used. I think that's probablly why the spec uses it; "thing" would be
14:03:25
mrcom
just too widely encompassing. As beach pointed out, stuff he considered "things" aren't datums.
14:04:01
mrcom
"places" are a really good example of a Lisp "thingy" that's not a datum, and so isn't an object.
14:05:14
dlowe
If I heard someone talking about CL objects I would assume CLOS objects, and by that measure not everything in CL is an object.
14:05:31
dlowe
If you cite the glossary I invite you to stuff it up your linguistic prescriptiveness
14:06:00
mrcom
dlowe: that's true, too, but only because other languages define "object" as an instance of a class. But it's a *really* common internalization.
14:06:57
nij-
bike I'm a bit confused here. So, this x3j13 issue approves the macro nth-value to be added into the standard. http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec/Issues/iss250-writeup.html
14:10:53
bike
nij-: i don't know or care about differences between the standard, dpans, and CLHS. i just use the CLHS.
14:12:29
scymtym
nij-: x3j13 issues typically suggest one or more changes to the standard which are written up with supporting information like a description of the background, pros and cons of the proposed changes, etc. if one of the proposals has been accepted, the proposed change is now part of the standard, not the issue itself
14:15:12
dlowe
nij-: language is used as a medium of both communication and specification, and I was speaking in the former mode.
14:19:40
scymtym
nij-: in the sense that dpans is the basis for wscl, i care about improvements that are present in the standard or clhs but not dpans. i haven't seen many of those if any so far. in particular, i don't think any x3j13 issues have been "applied" in the standard but not in dpans
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.