freenode/#sicl - IRC Chatlog
Search
21:45:42
no-defun-allowed
Re-reading the document, I wonder if they've investigated what assumptions the compiler writers make, and what is idiomatic Common Lisp.
21:46:53
no-defun-allowed
e.g one should basically never have to write SLOT-VALUE, so foo.bar syntactic sugar is just encouraging one to write bad code, and RAII (oh, why the hell are we suggesting RAII and manual memory management in the new standard now?) and continuations probably would not mix.
21:53:53
no-defun-allowed
We either already have "first-class macros", as you can grab the macro function and pass it around, like any old object, or by Matt Might's definition, it would be non-trivial to modify a compiler to implement them efficiently. And finalization is usually a last-ditch effort for handling remote resources; I wouldn't bother. And the high performance socket stuff is definitely _not_ using BSD sockets, so I hope we don't
3:51:18
fiddlerwoaroof
There are a couple areas that are occasionally annoying (floating point numbers not lining up nicely with IEEE-754, iirc)
3:51:31
no-defun-allowed
I have a small todo list of things to do to Common Lisp, but they're all implementation details really.
3:51:57
fiddlerwoaroof
But, the language as specified doesn't really need to be re-specified because the most common issues can be solved as libraries
3:52:23
fiddlerwoaroof
And, my attitude towards standardized features is roughly "standards are where features go to ide"
3:53:31
fiddlerwoaroof
The thing I like about SICL, for example, is that it's making standardized features user-extensible (eclector's a good example here)
3:54:15
no-defun-allowed
Specifically, those would be "green threads for async IO without hurting my head on async code" and "vectorising compiler", which are literally supposed to avoid having to modify client code.
3:54:33
fiddlerwoaroof
Anyways, I used to be a python programmer and the Python 2->3 transition has permanently soured my opinion of attempts to change language standards
3:57:23
no-defun-allowed
Oh, that reminds me somehow, Kulukundis's hash table avoids the problem of having excess tombstones from removing mappings...somehow. You only add tombstones if a group is full of mappings, and only empty mappings otherwise.
3:59:39
no-defun-allowed
It's still a bit beyond me, but (assuming an evenly distributed hash function) you'd need a (n-1)/n load for a hash table with n-sized groups to see any tombstones, which is pretty large even at n=8
4:00:35
Bike
i think there are some important improvements that would be more appropriate as a standard than a library
4:00:51
Bike
but all these CL 3.0 or whatever things like to focus on... i didn't even read this one. automatic slot names? who cares
4:01:29
fiddlerwoaroof
That's the other thing, people's idea of improving lisp is "making it more like Python/JS/Ruby"
4:02:56
Bike
i mean like, continuations, sure. whether they're desirable is of course arguable, but that's something you'd need actual implementation support for. you can put that in your updated standard
4:03:06
no-defun-allowed
Re-re-reading that document, the features aren't supposed to make sense together, so my comment on stack-allocation and continuations doesn't really hold.
4:04:55
no-defun-allowed
But if CL went that way, I would begin learning Self (at a faster rate than I am now). At least no one makes dumb READMEs about how to update Smalltalk for the "modern" era.
4:05:01
fiddlerwoaroof
Bike: yeah, although I wish people who wanted that sort of thing focused more on writing languages that compile to CL
4:06:03
fiddlerwoaroof
I recall a long-time smalltalker grumbling on Twitter about Pharo for this reason
4:08:22
no-defun-allowed
I've used Squeak more than I've used Pharo, but surely they consider how to implement the stuff they add in efficient and readable ways.
4:12:31
fe[nl]ix
fiddlerwoaroof: the MOP is full of holes, the whole I/O library is a joke by modern standards, the compiler needs support for first-class compilation environments, there's no explicit memory model, etc...
4:15:19
fiddlerwoaroof
It's more that the value of the improvements is necessarily proportionate to the cost, especially for a relatively small language community
4:16:06
fiddlerwoaroof
(especially when the improvements are backwards-incompatible and break existing code)
4:22:37
Bike
in other news, i think ansi tests for subtypep may be insufficiently strict. i have (subtypep '(cons (satisfies foo)) 'nil) => NIL T and it doesn't complain
4:36:47
Bike
i think ansi tests also didn't cover the bug i reported earlier, though i noticed the problem due to an ansi test i think
4:52:28
beach
fe[nl]ix has some very good points, and they are totally different from the union of arbitrary features that aun has collected on that site.
4:55:03
beach
In fact, I think when a committee designs a language, they are probably using the intersection of what everybody wants rather than the union.
4:56:47
beach
But in general, it's a collection of totally arbitrary stuff that aun found on the net.
4:58:12
fe[nl]ix
but that's because, with 30 years of language advancements at our disposal, CL's warts are all over the place
5:00:02
fe[nl]ix
the lack of extensibility of many parts of CL is because it allows runtime to be relatively lean (by today's standards) and allows compilers to optimize because behaviour is hard-coded
5:00:31
fe[nl]ix
otherwise you either end up with too late binding everywhere, which tends to be quite slow
5:01:31
fe[nl]ix
I feel CL is a good sweetspot between ML and Smalltalk as between lots of early bindings and lots of late binding
5:02:39
fe[nl]ix
OTOH, I *think* I know how to make a smarter language, but I don't have the funds to sustain myself while I spend 5+ years implementing it
5:17:26
beach
fe[nl]ix: Yes, there are a few people with enough experience and knowledge to create an improved standard. And, as you point out, it would take a lot of money to create such a thing. And the work would be very different from collecting arbitrary suggestions from people on the web who don't know anything about language design, and publishing the union of those suggestions.
5:19:45
Bike
i whipped up a caching system for ctype and i'm realizing it could really use a memory model.
6:26:16
pjb
beach: but wouldn't it be possible to develop such a standard using the resources available nowadays, including human resources? There are a lot more programmers available to participate, to implement and test experimental language features. Perhaps we could have a look at the process used for python and its PEP (Python Enhancement Proposals), similar to the CLHS ISSUES I guess, but more numerous and seemingly with more breadth.
7:29:27
beach
I think the latter point is the most important one. Like I have said several times, the point is to specify what most implementations already do.
7:41:43
no-defun-allowed
I thought Bike had a file on GitHub with the document, but I can't find it.
8:43:42
no-defun-allowed
My assumption about SIMD, 128-bit packed values and Lisp was wrong; both the SIMD libraries I found (cl-simd and sb-simd) are able to load and store octowords consisting of multiple elements (16 in the case of an (unsigned-byte 8) metadata vector).
8:57:42
no-defun-allowed
Rather, instead of having (unsigned-byte 128) elements, we load 16 (unsigned-byte 8) elements at a time. And that's how it also works in C with intrinsics, as far as I can tell.
9:17:29
heisig
no-defun-allowed: You had questions about SIMD? Or feature requests? (I still haven't managed to finish any of my SIMD libraries, sorry about that)
9:18:06
no-defun-allowed
Not really, thanks, I was just experimenting with cl-simd today (after hacking it and SBCL sufficiently to get them to appear to work).