freenode/#lisp - IRC Chatlog
Search
1:37:05
Xach
etimmons: adopt-subcommands got me to add support for looking up release info from gitlab
1:37:46
Xach
it turned out to be pretty easy - i can mostly pretend it's github, the protocol of GFs meant I only had to implement a single method in a key place...
1:40:43
copec
nij bash is actually a bit faster than python in many cases, and it's directly interpreting the text stream, I've thought it would be funny to have a lisp on top of bash
2:45:02
pjb
nij: https://cliki.net/programming%20language says Bash: no known CL implementation written in bash.
2:57:12
nij
Hmm.. I've asked this newb question before, but I wasn't happy with the solution. So here's another try.
2:57:56
nij
In my sbcl config, I use the package asdf and some symbols in it. However, in a freshly new workstation there's no asdf yet.
2:58:27
nij
Is there a way to wrap those that contain `asdf:..` in some form, so that when there's no asdf yet, it doesn't get loaded at read time?
3:02:50
pjb
nij: https://cliki.net/programming%20language says Bash: no known CL implementation written in bash.
3:04:24
beach
loli: Can you give me more context to your question? I am not sure what you are referring to.
3:05:13
beach
loli: We extracted the code for first-class global environments into the Clostrum library which has more documentation. There is also a presentation in the context of the online Lisp meeting that I made.
3:06:07
loli
I believe that was in response to your comment about it being more costly for CL to have a notion of either first class environments or modules.
3:06:23
loli
beach: if you don't mind, could you link me the presentaiton, that would be interesting to review
3:07:47
loli
I believe it was in a discussion about performance, you mentioned nested hash table calls
3:09:07
loli
well I assume CL already deals with a flat version of this, as it has to lookup things in it's image which we can view as a flat table?
3:09:09
beach
Usually, a typical Common Lisp implementation uses the symbol as an indirection to the function, so that SYMBOL-FUNCTION merely accesses a slot in the symbol.
3:09:59
beach
But that won't do when you have first-class global environments, because it name must resolve differently in different environments.
3:10:02
loli
ahh, so when you use libraries, it dumps the names into the namespace so it's a O(1) lookup call?
3:10:47
beach
Yes, the late binding costs O(1) and a very small O(1) in a typical Common Lisp implementation.
3:11:22
beach
So what most previous work does is to replace that indirection by a hash-table lookup.
3:12:15
beach
But if you do a hash-table lookup for each function call, you will slow down that important operation by an order of magnitude.
3:14:19
loli
thinking on it, I don't think it's relevant here, but it resolves the name to the proper one
3:14:26
jasom
A hash-table lookup is a larger (but still potentially O(1)) cost than reading a slot from a symbol
3:14:57
loli
have the schemes guys done first class environments, I heard the MIT guys have with their reflective tower?
3:15:01
beach
So what I did for the SICL work was that I use an indirection through a de-materialized "function cell" (just a CONS cell really), so that when code is loaded into some environment, the name resolves to an environment-specific cell.
3:15:44
beach
loli: Scheme has traditionally not been that concerned with performance, so they seem to accept the hash-table lookup for each function call. At least that's what Queinnec's work does.
3:19:23
beach
So it is easy to have first-class global environments or modules if you either don't need late binding (as static languages do) or if you don't care about performance of function calls.
3:20:38
loli
I believe this was the post I was referring to https://factor-language.blogspot.com/2008/01/compiler-overhaul.html
3:23:48
beach
So my work on first-class global environments solves the problem by resolving names to function cells at load time, but that works only when the name is known statically. If you call (SYMBOL-FUNCTION <non-constant-form>), then you still need a hash-table lookup, but the performance of such a call is less critical than that of a function call.
3:25:06
beach
Oh, and my ELS paper this year is another solution to the problem of late binding, and it is potentially even faster than the function-cell technique.
3:25:07
loli
Factor as a language is early binding, but with a few tricks, they make it seem like they have late binding which works in a lot of scenarios
3:26:05
beach
But on that page they talk about "interpreter", so they obviously don't position themselves in the "performance" camp.
3:27:23
beach
saturn2: They could. That's another possible solution. It would be very confusing, and you would need a way to refer to "the symbol which has the same name and package as this one, but in a different environment".
3:28:29
beach
saturn2: Plus, because the reader creates symbols, you would have to decide on the module/environment at read time.
3:28:31
saturn2
beach: it would just be going from package->symbol to environment->package->symbol, so it doesn't seem much more confusing than packages are
3:30:47
loli
ahh perfect I was just about to ask you if it was "Call-site optimization for Common Lisp" in the Preceedings
3:32:38
beach
I invented them so that I could isolate the host Common Lisp system from the SICL code during bootstrapping.
3:32:53
beach
SICL bootstrapping uses 5 different first-class global environments for different phases.
3:33:56
beach
You may want to isolate (say) the compiler internals from the API. Then if you put the internals in a first-class global environment by itself, you can "export" only the API to other first-class global environments.
3:35:10
beach
saturn2: So you can then also have different versions of the same system as long as each version is in a different first-class global environment. That solves the problem of two systems, needed simultaneously, require different versions of some library.
3:35:56
beach
saturn2: But my plan is also to use first-class global environments to isolate different users from one another, and to isolate users from the system, in a multi-user Common Lisp system.
3:37:08
loli
beach: with this new call-site optimization you found, is there still much more overhead versus the traditional model CL has? I'm curious from a new compiler perspective, and where the state of this research is at
3:38:22
loli
saturn2: you can do a lot of fun things, I've thought of having some way of sharing my nyxt browser state between my machines, then switching to different environments for a different machines state, and manipulating that, and through some protocol send the changes back (this is a bit silly, but would be fun to try to setup)
3:38:45
beach
loli: No, it's the other way around. The work on first-class global environments is already as fast as the traditional indirection through a symbol, and the work on call-site optimization suggests that we will be able to do function calls as fast as a static language like C++ can.
3:39:34
loli
beach: perfect, I can use this to my own means, and hopefully give something back to this field at some point in the future.
3:42:01
loli
Well I've been writing a compiler, and if things go well the language shall blossom quite nicely in enough time
4:14:05
terpri
beach, any thoughts on object-capability security models? a la johnathan reeves's w7 or chris lemmer webber's spritely goblins
4:18:11
terpri
a number people thought that common lisp was basically impossible to secure, but i think they were overly pessimistic and perhaps stuck in an actor-model rut
4:19:06
terpri
(granted, CL has a fair amount of global state and likely a number of funky edge cases)
4:21:44
terpri
beach, any recommended reading for multics security? i'm totally unfamiliar with it (but willing to trawl through multicians.org if nothing comes to mind, it's be good to know multics better in any case)
4:24:29
beach
I don't have anything specific in mind for the security aspect. But the basic idea is that you have an "object store" (i.e. the segment hierarchy in Multics) with ACLs (access control lists), and when you access an object in the store (done by the dynamic linker in Multics) the ACL determines the capability you get. After that, everything is capability based.
4:26:08
beach
EROS removed the ACLs, I think completely, and did everything with capabilities, but I find it hard to think in those terms.
4:26:41
terpri
beach, also...random question...would SICL potentially be useful for adding CL as a supported language to guile (a multilanguage scheme system that already fully supports "core" elisp and other langs)? e.g. for the later/higher-level parts of the spec? or is it its own thing like sbcl and other traditonal implementations?
4:29:04
terpri
beach, i'll try it out when the time comes (i'm barely past number parsing!) and let you know if i discover anything interesting. really cool project either way
4:29:04
beach
I am afraid that the SICL system code is going to require its own bootstrapping technique. I used to believe that I could write "modules" of system code to be added to a partial Common Lisp system, but it turned out to be too hard for a person with limited brain capacity like myself to write modules in a subset of the language.
4:30:22
beach
... so I decided to write the modules using the full Common Lisp language. But that means that you either need to have an existing Common Lisp implementation (which could be a slow interpreter) to load those modules. And then Guile would not qualify I guess.
4:31:06
beach
For SICL, I have a solution of course. I bootstrap using an existing conforming Common Lisp implementation, plus the CLOSER-MOP library.
4:31:49
beach
But Guile isn't built like that. Nor is any existing Common Lisp implementation as far as I know.
4:34:04
terpri
yes, and "layering" CL in a nontrivial way would be difficult (or at least the proposals for it were rejected as too complicated or unnecessary iirc)
4:34:08
beach
Then the ACLs can contain wildcards like *.admin (read/write) and beach.* (read only).
4:35:23
beach
terpri: Yes, the entire language is very tightly coupled. You can do evaluation at read time, etc.
4:36:26
beach
terpri: It is still possible to layer the implementation. For example, the SBCL compiler doesn't use classes or generic functions (or so I have been told). But I am not able to work like that.
4:38:35
beach
And I was told by stassats that there was no reason for the SBCL compiler to use generic functions and classes, because doing so would only have the effect of making it slower.
4:40:08
beach
Now, the way I see that issue is that, because generic dispatch is not very fast in SBCL, they then avoid the use of a great tool to write a major component of the system. I would much rather make generic dispatch faster and use the tool.
4:42:07
terpri
beach, btw, you *do* know of TUNES.org, right? conceptually, vaguely like CLOSOS, but much more of a pie-in-the-sky research project that fizzled out years ago; we were more often engaged in reflection-related wool-gathering instead of setting concrete goals and writing functioning programs (imho)
4:50:27
beach
I mean, this stuff is not rocket science. Anybody thinking about what we have and what we are doing wrong would come to similar conclusions.
5:11:09
terpri
a bit off-topic, but i'm personally interested in new approaches and optimizations for multiple dispatch, as adding prototypes with multiple dispatch to JS would allow me to (in a roundabout way) correct some serious design flaws in JS BigInt's design that i still feel guilty about (i was the main spidermonkey implementer and worked on other aspects of it)
5:13:05
terpri
(tl;dr google enabled a draft implementation early and changes to mathematical edge cases were rejected because "google says no", despite independent objections from me and fabrice bellard)
5:15:59
Nilby
terpri: You may have seen them, but there's some interesting papers about multiple dispatch here: https://opendylan.org/documentation/publications.html
5:19:11
beach
terpri: Can I assume you know about my work on generic dispatch? http://metamodular.com/SICL/generic-dispatch.pdf
5:21:08
terpri
Nilby, oh, neat, i have in fact not seen them (despite being interested enough in dylan to have a dead-tree copy of the language reference). even some of the older papers look potentially relevant to modern JS, ty for the link!
5:22:12
terpri
beach, you can indeed :) i think stumbling across that is how i actually heard about SICL
6:29:07
splittist
Kids, don't skip your trig classes. One day you're going to want to use the two-argument form of ATAN to draw Pacman...
10:25:25
engblom
Is there a ready macro like this for Common Lisp: https://clojuredocs.org/clojure.core/-%3E%3E ?
10:27:07
phoe
there's also a shameless plug from me, https://github.com/phoe/binding-arrows - they have some semantic differences to the clojurelike implementation
10:27:45
engblom
phoe: Thanks! As they are separate libaries, I guess there is nothing that replaces them directly in the common lisp specification?
10:29:17
phoe
the CL specification hasn't changed since 1994 and I don't know if anyone thought of arrow macros or something similar back in the way
10:31:24
engblom
Like adding stuff like these arrows, and maybe stuff that makes it easier to do threaded programming in a safe way.
10:32:59
phoe
the broader CL ecosystem has worked around this issue by means of libraries that can be implemented portably for stuff like arrows, and portability libraries that expose uniform API for stuff that requires implementation support
10:33:10
engblom
Not necessary, as many ideas could be brought directly from Clojure. It is not like the whole specification would need to be rewritten, just a few things added.
10:36:51
phoe
there's the tiny cost of editing the specification, big cost of convincing the implementers that it is worth for them to add this into their implementations, and the impossible cost of getting everyone to agree that this it the changeset to ANSI CL that is The Correct One that should be The New Oneā¢
10:38:26
phoe
and then there's the obvious collective cost of writing the code, testing it, aligning it with other implementations, and maintaining it
10:39:23
phoe
I don't want to say that it can't be done, but I want to say that there's been an attempt to do so every few years since 1994, and the topic is brought up here every two weeks or so
10:40:53
engblom
Ok. There is another thing that I wonder how to do best: threadsafe global variables. Clojure got such ones to read and set without any other thread interfering.
11:30:58
nij
In shcl, it stresses that it's not sending the string to another shell. Instead, it throws the input command through many functions, and arrives #'shcl-spawn at the end (https://github.com/SquircleSpace/shcl/blob/cc8d3c841b8b64b6715bf8f238fb19cd6093a793/core/support.lisp#L310). I wonder why it does that. Why doesn't it use uiop:run-program or sb-ext:run-program?
11:41:20
CL-ASHOK
Anybody know how to disable all the system messages on Freenode (connecting via Emacs ERC)
11:42:32
splittist
nij: because it has its own spawn (in C), that it says is more flexible than the POSIX spawn.
11:58:39
p_l
CL-ASHOK: ask on #emacs ? also beware, ERC is known to cause flooding by mistaken copy paste :)
12:24:14
beach
And this time comparing it to Clojure that does not even have an independent specification. Oh well.
12:25:41
nij
splittist: how can it be even more flexible than uiop:run-program? I cannot think of a shell thing that you cannot do with uiop:run-program..
12:28:58
beach
We should create a web page about "updating the Common Lisp specification" and teach minion to ask people to go read it.