libera/#commonlisp - IRC Chatlog
Search
14:02:37
beach
On the one hand, DECLARE takes a "declaration specifier" which is a list where the CAR is a "declaration identifier", and a "declaration identifier" is a symbol.
14:02:41
beach
On the other hand, the dictionary entry for TYPE says that (typespec var*) is an abbreviation for (TYPE typespec var*) and as far as I can see, it doesn't restrict typespec to be a symbol.
14:02:42
beach
Furthermore, SBCL accepts the example, which suggests that the SBCL maintainers considered the syntax valid.
14:05:10
thuna`
It is convenient if valid but I would say that the more strict restriction applies so it's not valid
14:08:09
beach
Oh, I guess I can ask people to run the example in the implementations at their disposal.
14:18:01
semz
beach: http://www.lispworks.com/documentation/HyperSpec/Issues/iss349_w.htm seems to explicitly allow it.
14:19:50
pfdietz
So, this was something that appeared in the final version, rather than in this draft of the standard?
14:26:11
beach
Brucio-61: The s-expression-syntax library rejects this syntax. Does this fact reflect your choice of interpretation of the standard?
14:30:40
Brucio-61
beach: i simply haven't thought about that case before. i can probably adjust the syntax description to allow the compound type specifier variant
14:31:20
beach
I see. Well, we should think about it at least. I wonder what other Common Lisp implementations do.
14:31:21
Brucio-61
i will probably have to perform some implicit conversion since the resulting node cannot use a compound type specifier as the declaration identifier (is that the term?)
14:47:44
jcowan
I'd say that given a conflict between the main text and the glossary, the main text should normally win
14:51:54
Colleen
Shorthand notation for type declarations http://www.lispworks.com/reference/HyperSpec/Body/03_cca.htm
15:24:46
gilberth
The trouble with that shorthand notation is that there is no way in ANSI-CL to tell whether a symbol names a type nor whether a symbol names a declaration. So you can't have macros that actually look at declarations. This may be troublesome when you want to implement a macro which binds variables serially, yet you want to use nested LETs. As you would need to pull out declarations applying to a specific symbol.
15:26:16
gilberth
Consider e.g. that you want to implement DESTRUCTURING-BIND on your own. You would need to make it turn into just one LET. Can be done, but it may be awkward.
16:59:36
pfdietz
gilberth: I don't understand that objection. You can always recognize declaration forms, since they are conses who car is the symbol declare.
17:01:13
gilberth
Suppose I want to lift all type declarations for 'x', do I need to lift that declaration, or don't I need to do that?
18:13:37
gilberth
I was specifically speaking about ANSI-CL. I'm aware of that olde lexical environment access. And it's not SBCL-specific in any way. In practice I am fine with using implementation-specific means.
18:14:42
gilberth
More severe IMHO is that neither EVAL nor COMPILE does take an environment argument. This makes it impossible to write a code walker.
18:15:25
gilberth
And even if you're not after a code walker, what good is CONSTANTP telling you that something is a constant, but you cannot get at the value? In a macro?
18:18:58
_death
well, constantp is still useful in some (rare, unfortunately) cases, e.g., when generating reference documentation it can indicate that the symbol represents a constant :) or sometimes the symbol is also boundp, and you can get at the value then
18:22:28
gilberth
This not being able to walk code however is a roadblock for my noffi project. Otherwise I could do my own type propagation / interference for foreign types. And possibly identify trivial cases in which stack-allocation suffices.
18:23:04
gilberth
sb-alien has an advantage here as Python has specific knowledge about sb-alien. Both know each other pretty well.
18:27:15
_death
I guess in practice one settles on having the necessary bits of implementation-specific code
18:30:52
gilberth
Yes, but in this case I would need to resort to non-exported functions for the most part. This different from e.g. figuring out how to make a weak hashtable.
18:32:25
gilberth
Anyhow, what I'm after are missing pieces of the language. Things that cannot possibly be implemented as a library. And with language I mean the language itself, not missing bits and pieces to interact with the environment.
18:38:10
_death
I guess implementation-internal -> implementation-external path is well traveled (presentable interface, convincing the implementors, etc.) and in 2082 when they start discussing the next CL standard, the implementation-external interfaces will be criticized and reshaped into the 2094 CL
18:40:45
gilberth
Well, we have a few success-stories: relative package names^W^W^Wpackage local nicknames, that "R" number marker, Bordeaux threads, Gray Streams, the MOP. All things I consider de facto standard.
18:41:47
gilberth
But EVAL taking an environment argument is too niche for that. Despite I have not written an article why that is important and why that is a road block when writing a code walker.
18:42:31
gilberth
_death: Who says that? There are universally available and in wide-spread use. Not much different from the pretty printer or the LOOP macro.
18:47:07
_death
gilberth: I say that :) just my opinion.. e.g., I think PLNs might have use cases but in general I avoid and dislike them, Gray Streams were already criticized for parroting the user API instead of being a useful extender API (cf. Franz's Simple Streams), Bordeaux Threads is currently redesigned (v2) though I've not kept up with the changes, it obviously misses big pieces like atomics and such.. the MOP also had some work done on it
18:58:18
_death
also, Bordeaux Threads is a particular library and not a specification with multiple implementations and PLN doesn't have a reference spec although multiple implementations exist
19:02:59
gilberth
We have plenty of time. I just wanted to point out that a lot of what we see in ANSI-CL once was a handy library. And as I understood it CLtL1 was more like writing about commonly seen features than anything else.
19:04:17
gilberth
And IMHO this is a good way to go, instead of specifying things out of the blue sky that someone somewhen dreamt of. In that regard too CL is a practical language.
19:10:02
_death
right.. it reminds me of some post I wrote a while ago, last 3 paragraphs are relevant https://old.reddit.com/r/Common_Lisp/comments/j7vd25/a_curated_standard_library_for_common_lisp/g89544v/
22:43:54
Josh_2
Lets get all the folks who wrote a JSON library together to write 1 more JSON library :)
23:01:19
Josh_2
The easiest way to solve this problem is to make a new Common Lisp standard where the productivity of the language is butchered. That way people have to collaborate on large do-everything-or-die-trying libraries!
23:39:31
pfdietz
Let's get all the people who used the wrong JSON library to stop their vile heresy.