libera/#commonlisp - IRC Chatlog
Search
3:17:23
beach
merazi: http://www.total-knowledge.com/~ilya/mips/ugt.html#:~:text=UGT%20%28abbr.%29%3A%20Universal%20Greeting%20Time.%20UGT%20is%20convention,time%20of%20any%20member%20of%20channel%20is%20irrelevant.
3:20:00
merazi
I'm learning Scheme, a lisp implementation (I know it's not the same as Common Lisp), and I wanted to be part of the lisp community.
3:31:14
beach
merazi: I should tell you, usually #commonlisp is fairly lively, but this is Sunday morning in Europe, and many people here are Europeans with families, so it is a bit slow during the weekend.
3:32:30
merazi
That's completely understandable, I won't be here 24/7 but I'll hang out occasionally.
3:58:11
jcowan
merazi: Not to steal you away or anything, but there is a #scheme channel as well as the #lisp channel, which is about all the Lisps.
3:59:13
merazi
I'm already in the #scheme channel and... *click* Now I am in the #lisp channel as well :)
4:05:55
beach
That dictionary entry says how a conflict should be resolved when an imported symbol conflicts with an existing inherited symbol, and when it conflicts with a symbol that is present.
4:05:59
beach
But what about this scenario: A new symbol conflicts with a symbol that is present, but the present symbol is a shadowing symbol, and there are external symbols in the used packages that would conflict if it weren't for the fact that the present symbol is a shadowing symbol.
4:06:00
beach
So here is my question: Should a conflict be reported that contains also the inherited symbols? If not, what happens if the user uninterns the present symbol? Should the new symbol also be a shadowing symbol right away, or should a new conflict be reported?
4:09:18
beach
I am leaning toward not including inherited symbols in the conflict report and to make it shadowing if the present symbol is a shadowing symbol.
8:57:20
beach
We are accumulating "issues" for WSCL: https://github.com/s-expressionists/wscl/tree/main/wscl-issues/proposed which is good. But we could use some help from people who have easy access to implementations other than SBCL.
8:57:25
beach
Many issues have a line "TODO: check other implementations." where the behavior of other implementations should go.
9:08:20
beach
Some of the issues have been transferred from (I think) Cliki to WSCL. This one was transferred by Bike.
9:09:02
moon-child
yeah, I saw it was dated to 2004, which was why I was surprised I had never heard about it
9:12:59
beach
shka: yes, maybe you prefer to make an "issue" that PROG2 should be deprecated since there is an operator doing the same thing. :)
9:24:48
Alfr
PROG2 shouldn't be deprecated, as its second form is mandatory thus not redundant to prog1. But fixing the description of result-2 (under Arguments and Values) for consistency could be considered.
9:28:00
Alfr
I was thinking about the following fixup: result-2---the primary value resulting from the evaluation of first-form.
9:32:40
Alfr
beach, what do you mean? clhs already uses the name result-2 for the only value of prog2.
9:37:07
Alfr
It isn't a serious proposal anyways apart from keeping prog2 alive. I think there is a know better fix for that.
10:18:42
pjb
beach: there are arguments to deprecate prog2. For example, there's no multiple-value-prog2, only a multiple-value-prog1 :-)
11:15:16
scymtym
deprecate all three and generalize to MULTIPLE-VALUE-PROG-NTH N FORM* where N is evaluated. i'm sure there will be no negative impact in terms of ergonomics or performance
11:40:33
scymtym
that's hard to answer in general. GTK has gpu acceleration, more complete text and font support, more supported platforms and probably looks more appealing to many users. McCLIM works without foreign libraries, has the presentation and command sub-systems, is easy to extend due to the stratified design and has a specification. but again, advantages and disadvantages will depend on the use-case
12:16:45
lotuseater
a friend of mine said McCLIM looks old but I more tend to use the term "baroque"
12:25:32
beach
lotuseater: So here is what bugs me. People would rather spend a lot of time and energy debugging FFI solutions that serve only their own projects, and complain about the looks of McCLIM, rather than spending a small amount of time making McCLIM look the way they would like it to, thereby providing a better solution for the entire community.
12:50:02
contrapunctus
lotuseater: there's been some lovely art from the Baroque era, is that a compliment? 😏