Timeline for Is there any practical use for the empty type in Common Lisp?
Current License: CC BY-SA 3.0
26 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 17, 2024 at 16:18 | comment | added | coredump | @gsl if you evaluate the form then it's logical that you have such a message. The expression in the context where a type expression is expected should not do that. Probably you need to quote the form by having an apostrophe before when using it to declare the type of array elements | |
| Jul 17, 2024 at 10:28 | comment | added | gsl | @acelent In LispWorks, (values &optional) returns "The variable &OPTIONAL is unbound."? | |
| Sep 14, 2016 at 13:47 | history | edited | coredump | CC BY-SA 3.0 | edited body |
| Sep 14, 2016 at 12:46 | history | edited | coredump | CC BY-SA 3.0 | Too long |
| Oct 8, 2015 at 18:29 | history | edited | coredump | CC BY-SA 3.0 | edited body |
| Oct 8, 2015 at 15:40 | history | edited | coredump | CC BY-SA 3.0 | deleted 4 characters in body |
| Oct 8, 2015 at 14:40 | history | edited | coredump | CC BY-SA 3.0 | deleted 1 character in body |
| Oct 8, 2015 at 14:26 | history | edited | coredump | CC BY-SA 3.0 | added 11 characters in body |
| Oct 8, 2015 at 13:54 | history | edited | coredump | CC BY-SA 3.0 | added 122 characters in body |
| Oct 8, 2015 at 13:47 | history | edited | coredump | CC BY-SA 3.0 | added 122 characters in body |
| Oct 8, 2015 at 13:30 | history | edited | coredump | CC BY-SA 3.0 | added 1950 characters in body |
| Aug 22, 2014 at 8:40 | comment | added | coredump | @PauloMadeira The answer is now edited, for the better I hope. Thanks for your comments. | |
| Aug 22, 2014 at 8:34 | history | edited | coredump | CC BY-SA 3.0 | added 996 characters in body |
| Aug 21, 2014 at 16:06 | comment | added | acelent | Consequences are undefined even if the actual data is never effectively used, as in: -- But in that case, the data is effectively accessed, used to create a list of one element. But (length (list (make-array 10 :element-type nil))) should still reliably return 1. | |
| Aug 21, 2014 at 15:45 | comment | added | acelent | I get SBCL's point of view, that the only way to satisfy a nil return type is to not return at all, but it's a deduction or even a choice, since it's undefined behavior (versus clearly meaning the function can't return anything) to deal with a return value that is not of the declared type. So if a compiler can prove such a function may return, it could error on definition, on compilation and/or on load. | |
| Aug 21, 2014 at 15:36 | comment | added | acelent | (1) I don't know, some SBCL error functions are already declared as such, so I guess you can trust SBCL will not error on such declarations. (2) The only reliable, portable way to say that a function returns no values is that, but there is no portable way to say that a function doesn't return at all. (3) Declarations may be completely ignored, but they may also be completely trusted, so it goes that it's implementation dependent, hence you can't trust it won't error, but you can't trust it will error either, and it might error either at the declaration point or during compilation. | |
| Aug 21, 2014 at 12:43 | history | edited | coredump | CC BY-SA 3.0 | added 335 characters in body |
| Aug 21, 2014 at 12:24 | comment | added | coredump | @PauloMadeira Thanks for the detailed explanations, I wasn't aware of this. (1) Does it mean for SBCL that some declarations, like error, will eventually be changed to use (values &optional)? (2) You said that "there is no portable way", yet values is "the only reliable way"; I am little lost here, isn't it portable? (3) you say that since it is impossible to have a value of type nil, the function definition with nil is necessarly wrong: but functions are allowed to not return values; wouldn't signaling an error/warning for the declaration be incorrect, by over-approximation? | |
| Aug 21, 2014 at 11:25 | comment | added | acelent | Just for the record, the rationale behind the need of &optional at the end of a compound values type declaration to declare no further return values has been discussed in one of SBCL's mailing lists. Basically, the presence of lambda list keywords indicates the amount of parameters to a function that would be correctly called with the returned values as if by multiple-value-call. The lack of them allows further return values (of type t). The consequence is that (values &optional) is the only reliable way to declare no return values. | |
| Aug 21, 2014 at 11:09 | comment | added | acelent | I'm not confusing. The way to declare you return no values, is correctly done with (values &optional). With nil, you declare it returns a first value of type nil, which is impossible and the implementation could signal an error or at least a warning right on the declaration. If it was null, the only valid first return value would be nil. There is no portable way to declare that a function doesn't return. | |
| Aug 21, 2014 at 8:35 | history | edited | coredump | CC BY-SA 3.0 | added 21 characters in body |
| Aug 21, 2014 at 8:09 | history | edited | coredump | CC BY-SA 3.0 | added 700 characters in body |
| Aug 21, 2014 at 7:49 | comment | added | coredump | @PauloMadeira (i) You might be confusing the NULL type with the NIL type (aka. "empty type"); (ii) It is true that this is an undefined behaviour. I'll edit to make it clear, thanks. | |
| Aug 20, 2014 at 18:53 | comment | added | acelent | (function ... nil) declares a function that returns a value of type nil. To declare a function that returns no values, it's (function ... (values &optional)). Also, it's undefined behavior to access uninitialized array elements. | |
| Aug 2, 2014 at 15:15 | vote | accept | Pedro Rodrigues | ||
| Jul 18, 2014 at 14:01 | history | answered | coredump | CC BY-SA 3.0 |