libera/#sbcl - IRC Chatlog
Search
15:31:55
_death
latest sbcl gives me https://plaster.tymoon.eu/view/4125 and I wonder if someone can reproduce.. I saw there were some ftype-related changes recently.. in my case I noticed this issue due to esrap:parse returning no values
15:46:03
Gleefre
Note that if I understand correctly, the main problem is not the style warning, but that no values are returned at all...
16:01:16
Gleefre
Works properly on 2.4.0.86, but shows buggy behavior on 2.4.0.87 (x86-64, linux, ./make.sh called without any additional flags)
16:17:30
Gleefre
Same for arm64 / android... So the offending commit seems to be this one: https://github.com/sbcl/sbcl/commit/4af52ef54103b4dbedc7c4d89e784040b6fbf417
16:18:40
_death
thanks.. my connectivity suffers at least until next week, hopefully stassats will get the memo
16:54:48
pfdietz
It means there's automatically a violation of the type constraint if the optional parameter is present? So I guess is means the optional parameter must never be provided.
17:03:11
stassats`
not returning is a subtype, but should a non-returning function produce a warning if its ftype specifies some return valeus?
17:05:41
pfdietz
Maybe? It's not actually invalid, since every value it does return (which is an empty set) is in that type, whatever it is.
17:05:59
Gleefre
I only found a very short non-describtive CLHS entry: https://www.lispworks.com/documentation/HyperSpec/Body/t_values.htm
17:06:22
Gleefre
It seems that SBCL treats (values &optional) differently than most other implementations?
17:07:32
pfdietz
Perhaps in general if one can show the actual returned values of a function are a smaller type than specified in ftype, that should be a style warning.
17:08:56
_death
I would say that it shouldn't produce a warning.. there's the possibility of redefinition or change in the future
17:09:09
stassats`
i think some portability libraries define nil stubs, so i guess can't do that practically
17:10:55
_death
the purpose of the ftype declaration may then be to signal to the user and the compiler that the function may at some point return some values that it currently doesn't
17:18:57
Gleefre
...but I still can't find anything about &optional in values type-specifier in a way SBCL treats it.
17:20:30
Gleefre
Actually, right, rereading the entry for VALUES type specifier "...when given to multiple-value-call along with the values, would correctly receive those values", it seems that (values 1 &optional) indeed requires the form to return exactly 1 value.
17:27:41
Gleefre
Hm, do I understand correctly that (values &optional) then means the same thing as (values &rest null) ?
17:31:39
Gleefre
I'm asking because (subtypep '(function () (values &rest null)) '(function () (values &optional))) returns NIL, T; and not T, T or NIL, NIL as I'd expect.
17:33:08
Gleefre
But then it is not limited to sbcl, so I guess I'll go ask in #common-lisp as well :)
17:39:53
Gleefre
Hm, I see, so &rest / &optional in values are like type specifier for argument list