freenode/#sicl - IRC Chatlog
Search
10:31:15
beach
heisig: Last time I thought about type inference, I found it useful to consider two different purposes. The first purpose is absolutely crucial, but also fairly simple, namely optimization by avoiding unnecessary type tests. The second purpose is good, but can be considered a bonus, and it is giving the programmer compile-time feedback about incorrect types. The second one is much harder, so you might want to consider only very
10:32:40
beach
heisig: For the first purpose, it is good to know whether an object is of one of the immediate types, or on the contrary, if it is a standard object. Also, the type LIST might be useful, because then a single test (for CONSP) is enough to distinguish the cases.
10:33:21
beach
Arrays of different element types are important. You can assume that we are not allowed to CHANGE-CLASS of an array.
13:18:37
lukego
SICL seems very interesting and I am going to have to read all the papers once I get back into a distractable state.
13:28:19
splittist
lukego: clime seems like a great development aid (inter alia) - being able to attractively (or, at least, graphically) PRESENT objects at the repl would be great.
13:29:26
lukego
maybe it will also work as a stepping stone between the Emacs and CLIM worlds i.e. an easy way for SLIME users to get their feet wet with CLIM.
13:31:16
lukego
but yeah presenting objects at the repl is working already now and once ACCEPT is also working then we'll be getting somewhere
13:32:22
lukego
I haven't dared to try yet :-) but I /think/ it's going to just work. kind of hoping someone else will volunteer to try that :)
13:32:44
lukego
I mean, CLIME is just translating CLIM drawing operations into SVG, and SVG has first class support for drawing text.
13:33:27
lukego
but once it hits Emacs it will be rendered into a bitmap. unless we did some more elaborate integration -- maybe even tying in with existing SLIME presentatoin features -- but that's beyond my ambitions for no
13:34:37
lukego
though by "just work" I mean after adding a few lines to emacs.lisp where it translates output records to svg elements here https://github.com/nuddyco/McCLIM/blob/clime/Backends/Emacs/emacs.lisp#L219-L232
13:35:17
lukego
up to and including fixing silly things e.g. if I've forgotted to commit some crucial file...
13:36:43
lukego
could potentially be useful for SICL even? I started down this interactive diagrams path originally for visualizing LuaJIT IR instructions.
13:38:08
lukego
that worked pretty well IMO e.g. click an IR instruction to see the SSA pruned to only show transitively referenced instructions, e.g. click on a branch to see all instructions that influence whether that branch is taken, etc.
13:39:23
jackdaniel
I think that there is such tool for SICL and Cleavir written in CLIM, but I don't remember details
13:39:59
lukego
it'll be interesting to see how much CLIM code ends up working with CLIME. maybe quite a bit or maybe only new code carefully written in a supported subset. I don't have much notion of CLIM usage.
15:24:54
lukego
are there PDFs of the SICL papers and manuals somewhere, or does one build them oneself?
15:28:01
lukego
I don't think it's a problem for me to run builds really, I just notice that the lack of links to PDFs is inhibiting me from impulse-reading
15:32:12
jackdaniel
ACTION wonders how useful is the url ending with ...pdf given there is no way to access a list of file names (403: Forbidden for the /SICL/ directory)
15:36:15
beach
My idea was that you would look in the SICL/Papers/? directory. Find the name of the TeX file, and then replace the suffix with pdf and add it to the link.
15:44:22
beach
The good news is that I might no longer need a system administrator though, since I now replaced my desktop and everything seems to work in the new machine.
18:09:28
beach
I have no intention of using a library written in C++ and that I will have to keep up with.
18:09:45
beach
If someone else wants to create such an independent module, then they are free to do so.
18:10:41
pjb
I guess all that would take is only one of us winning the lotto, to finance more backends to sicl :-)
18:10:45
beach
Plus, given all the problems the Clasp developers had with it, with respect to compile-time performance, exception handling etc., that's another thing I have no desire (nor time) to deal with.
18:12:54
beach
I plan to "support" a RISC-V backend, and the x86-64 one, as long as I need it for my own computers.
18:14:03
beach
Anyway, I'm off to spend time with my (admittedly small) family. I'll be back tomorrow morning (UTC+2).
18:36:36
Bike
I'm poking at the "mirtype" branch in Cleavir again, where decisions of unboxed types and values/non-values representations are delayed to MIR level. everything works but it's slower, which i think is basically because multiple-value-bind does a local call now instead of just some setqs
18:37:03
Bike
there are a couple hacky solutions I can do, but I think the right thing would be to use type inference information about the number of values returned by forms
18:37:55
Bike
Since values specifiers don't work in some implementations, I think it might be prudent to gives cleavir-ctype its own values type objects... which it sort of has anyway
18:54:59
heisig
Bike: I just started working on a protocol for types (although slowly, because I am technically on vacation).
18:55:55
Bike
oh yeah, if you're any less busy... I filed a PR for Trucler that I would appreciate a look at
18:56:17
heisig
The main difference so far is that I clearly separate ctypes and vctypes. I am also thinking about introducing fctypes (function ctypes).
18:56:47
Bike
mm, well that's what i'm just about to work on for cleavir-ctype, so if you do it first all the better i suppose
19:06:19
heisig
Bike: I just had a look at your changes. Let me rephrase your change to make sure I actually understood it.
19:06:51
heisig
We are only considering declarations that are not bound to a particular variable. Things like ftypes, types, special, dynamic-extent etc are already handled by other means.
19:07:49
heisig
The only one of these declarations in the standard is cl:optimize, but implementations might support further declarations.
19:08:31
Bike
I need to get that information from the environment somehow and this is what I came up with
19:11:25
heisig
But the compiler wouldn't be able to detect user-defined lexical declarations. So Trucler doesn't have to worry about that either.
19:12:03
Bike
well, it might want to record them in an environment where they could be used by compiler macros or whatnot
19:13:10
Bike
https://github.com/guicho271828/trivia/blob/master/level2/impl.lisp#L370-L390 for reference, here's a use of them in the wild i found when i was seeing if anyone actually did this
19:15:29
heisig
I think those are good changes. The only thing I wonder is whether we should conflate describe-optimize and describe-declarations.
19:18:12
heisig
The point is that describe-optimize returns an instance of a particular class, while the latter returns the X of some (declare X) just like it appeared in the source code.
19:19:03
Bike
oh, i was thinking of describe-declaration as returning a description object of some kind
19:19:35
Bike
I figure in the spirit of "CLTL2 but modern" it would always do so, and if you want a custom declaration you need to define a description class or something
19:20:40
heisig
Oh, I see. But what information other than the declare form would be stored in that declaration-description?
19:21:36
Bike
I don't know. Whatever the user wants. In this trivia example, I guess it would be the actual optimizer function rather than its name.
19:39:37
heisig
The first case is accessing the current optimize settings. Trucler already has a better way of handling that.
19:40:34
heisig
The second case is that of accessing the set of user-defined declarations that are currently permitted.
19:41:05
heisig
The third case is that of accessing a particular use of one of these user-defined declarations.
19:41:33
heisig
My hunch would be to introduce separate API functions for each of these three cases.
19:43:36
heisig
The first case stays as it is, with the generic function describe-optimize that returns an optimize-description.
19:44:24
heisig
The second case should be handled by a describe-declarations function that returns a declarations-description.
19:45:00
heisig
We could then define some generic functions for querying such a declarations description.
19:48:32
heisig
The third case could be handled by a generic function called describe-declaration, that returns the declaration specifier whose first entry is that symbol, or NIL if no such declaration specifier exists.
19:49:12
heisig
(Please tell me if it doesn't make sense. I am still very tired from chairing ELS and likely to make mistakes)
19:50:59
Bike
the first two cases make sense. The third... I'm not sure, users might want some processing like cltl2 has, but that's probably out of band for trucler
19:58:17
Bike
define-declaration defines a function that th eenvironment is supposed to call when an environment is augmented
20:01:13
heisig
Oh, right, I had missed define-declaration. Give me some time to re-think what I just said.
20:01:41
Bike
sure. i mean, i can work on the first two cases to begin with, anyway, that's what i need to use trucler in cleavir
21:24:45
Bike
::notify heisig i think an actual define-declaration analog would be out of scope for trucler. but trucler could have a function to read implementation-defined info for a user defined declaration, and maybe one to augment