freenode/#sicl - IRC Chatlog
Search
9:03:21
anticrisis
beach, regarding IDEs, there's a specification called Language Server Protocol, which seems like a language-agnostic SLIME. Many language developers have adopted it because it plays nicely with IntelliSense in VS Code. Since it's specified, I thought it might be a useful reference.
9:05:03
beach
But scymtym has an implementation of it for Common Lisp, that can do whatever subset the LSP can do.
9:06:12
beach
They didn't think to include things that are needed for dynamic languages, like evaluation, apparently. I haven't looked at it myself, but scymtym knows the details.
9:06:15
no-defun-allowed
Does LSP allow one to interact with a running program and perform "dynamic" analysis? The latter would be necessary because user-defined macros can define functions and types.
9:11:01
beach
So people who are happy with using the subset that LSP allows can use what scymtym developed and their favorite editor.
9:11:15
anticrisis
I was hoping its "text synchronization" messages (designed to catch file open/save) could be hacked to simulate SLIME C-c C-c, maybe? Or maybe the protocol cold be extended.
9:11:28
no-defun-allowed
I think in minus-defun.lisp the name of the function being defined should be -, not /
9:36:48
beach
anticrisis: Not sure whether my idea is possible or not in LSP, but the plan is to avoid requiring the programmer to hit any particular key in order to compile the source code. I want to parse and compile the source code at typing speed.
9:53:12
beach
I think I should call them -addition -subtraction -multiplication -division or possible -add -subtract -multiply -divide.
9:59:04
no-defun-allowed
binary-addition sounds nicer, but usually I expect functions to be verbs, so binary-add would be more "correct".
10:04:25
no-defun-allowed
"div" or "divide". I would say "over" usually, but I still prefer binary-division.
10:10:03
selwyn
beach: your proposal for bignums as essentially vectors of fixnums is very close to what is being implemented now in clasp, though we made the decision to use 64-bit unsigned integers
10:18:25
splittist
any reason not to use binary+, binary-, binary/, binary* etc? (Then folks can pronounce them however they wish in the privacy of their own mind...)
10:51:28
beach
selwyn: OK. There are not many different ways of doing it. The main choice was between fixnums (making it possible to implement it in Common Lisp) and what you chose (probably making it necessary to implement it in C++).
10:58:34
selwyn
we chose the 64-bit unsigned integers in order to make it entirely compatible with GMP low level routines, which do all the heavy lifting for us
11:47:32
scymtym
when i looked at LSP, it focused on static analysis, refactoring (e.g. rename variable) and navigation (e.g. goto definition, find references). the specification was rapidly changing at the time, so it might do a very different set of things now. there are also language-specific extensions as well as a separate, similar protocol for integration of external debuggers into IDEs
11:49:25
scymtym
here is a somewhat outdated version of my implementation: https://github.com/scymtym/protocol.language-server/tree/future
11:52:09
scymtym
i think this is the most comprehensive demo of what a system using this LSP implementation could do in Emacs: https://techfak.de/~jmoringe/eclector-context-completion.ogv
11:54:12
scymtym
ACTION should get back to that. with current eclector all of that should work without carefully avoiding syntax errors and incomplete inputs
12:02:51
scymtym
heisig: pay me to work on it full-time. but seriously, i'm not releasing most of this because it is a collection of prototype-level software that i have no hope of supporting with my currently available time
12:08:04
heisig
I fully understand. I'd volunteer to help, but my time is also not what it used to be. Have you tried to attract other contributors, e.g., from #lisp?
12:10:49
heisig
Oh, and while I can't pay you full-time, I could at least make some donations. Do you have some flattr or whatever account?
12:11:10
scymtym
my development style and slow pace for this prototype stuff makes it unsuitable for collaboration, i think. it is also easy to waste what little time i have on collaboration overhead
12:13:29
scymtym
thanks for the offer, but the problem is time not money so only a more radical change would have an effect. my contract will run out soon (again), though :)
12:15:56
heisig
ACTION wonders how much money we could raise in the CL community for such an endeavor.
12:17:40
scymtym
when i last looked into this, i have read about a model in which an organization collects the funds and employs or contracts individuals for specific projects
12:25:27
MichaelRaskin
Also, maybe ask around if someone is willing to accept stewardship and Do Something with submited patches?
12:38:44
beach
selwyn: Right. That's not possible for SICL, though someone else might slip it in for their own personal use, now that we know that we can do everything with generic functions.
12:47:10
Bike
shouldn't sicl have the ability to work with "unboxed" 64 bit integers anyway? i mean, you can change bignums later, of course
12:53:48
heisig
SICL should definitely support unboxed 64bit integers. There are plenty of algorithms that require power-of-two sizes, and there are exactly zero machines that don't provide them.
12:55:01
beach
Right. I would need to give some serious thought to how such support would be provided.
13:05:31
froggey
I use ub64-based bignums but didn't have any compiler support for unboxed ub64 arithmetic until recently. I had to write a significant part of the bignum code in assembly, seriously not recommended
13:09:41
beach
So how would that be done? Insist that any function that takes unboxed arguments or return unboxed values be inlined?
13:13:16
lonjil
You could have a special calling convention for functions on unboxed values, but it would only work for some function signatures and only if the function can't be redefined.
13:13:19
beach
And then perhaps write the code so that bignums are possible when inlining does not happen, and count on pairs of box/unbox to be removed?
13:14:33
heisig
beach: I don't understand what you mean with 'bignums are possible when inlining does not happen'.
13:15:15
beach
heisig: There might be a declaration and a type check for (unsigned-byte 64), but no particular action to prevent bignums from happening.
13:15:52
beach
So then box/unbox would be inserted normally, and should the function not be inlined, there will be a BOX in there and a bignum would be created.
13:17:06
beach
But when the function is inlined, there will be an unboxed value with type (unsigned-byte 64), and then a BOX instruction and then an UNBOX instruction, so that the result is again an unboxed (unsigned-byte 64).
13:19:22
heisig
That would be one way. The other way would be that box/unbox instructions are only inserted after inlining and type inference.
13:19:55
heisig
Either way, it will be possible to implement bignum+ on a vector of element type (unsigned-byte 64).
13:21:58
heisig
Absolutely. As they say, the biggest speedup is when a code goes from "not working" to "working" :)