libera/#sicl - IRC Chatlog
Search
13:46:39
moon-child
jackdaniel: it means that you can use eq in place of eql when you know you're not dealing with bignums (or don't care about bignum results)
13:47:10
moon-child
I think, if the pointer doesn't have any free bits, you had rather taken out some extra data beside the pointer as a tag, rathern than eaten an indirection
13:49:02
jackdaniel
perhaps I should phrase it better - what is there to be /practically/ gained by specifying that - did you hit a bottleneck in your program because eql is too slow?
13:51:00
moon-child
no, but I can imagine cases where it would get annoying. Eg eql likely becomes a drag on vectorisation. I'm also generally in favour of specifying more rather than less, where feasible--punish the implementor!
13:53:22
jackdaniel
I think that usually with numbers you use arithmetic operators like #'<; also if you can declare types then unboxed comparisons will be equally good for most cases (while eq could only be used instead of = at the expense of obscurity)
15:03:35
beach
Bike: I was thinking that something like that would be ideal to use in Second Climacs. I just did a short experiment using SBCL to compile a non-trivial top-level form, and it took less than 10ms. So I think it is going to be very practical to compile top-level forms at typing speed (but only when needed, of course).
15:54:50
beach
I think we might want to use s-expression-syntax first, and that's not finished either.
17:06:57
Bike
and in bir you can get useful type warnings and some other things. the stuff left over for a linter to do is basically style
17:15:24
scymtym
i have some rule based stuff for style on the character ("avoid closing paren on separate line"), CST ("avoid double package markers") and AST ("use (when X Y) instead of (if X Y)") levels. but making what i have really usable will take more work on Eclector (not as much) and the s-expression-syntax library (the majority of the work)
19:27:58
Bike
as for what i have been working on... i have been doing stuff with the bytecode compiler we made. right now it is a bit clasp-specific, but i would like to make it portable lip again, and maybe put it in s-expressionists. the idea is that the bytecode compiler is fast and simple (no IR), and does enough "optimization" (e.g. macroexpansion) for most code to go much faster than an interpreter. then with that in
19:28:04
Bike
place, cleavir can be the big guns compiler with more sophisticated analyses, and it's less important how fast it goes.
19:28:42
Bike
with the improve-cleavir-optimization-so-cleavir-runs-faster strategy i have been continually frustrated by the optimization taking more time than it saves, because more optimizations need to be in place for things to be really efficient - so by splitting concerns like this i hope i can do better with that
19:30:31
Bike
for an idea of how long cleavir takes in clasp - i have been compiling and loading swank with the new bytecode compiler - cleavir isn't used except for constructing inline function ASTs, and for code walking in CLOS. it still manages to take 17% of the total time of compiling and loading
19:39:43
scymtym
Bike: i came up with yet another (the third, i think) solution for the NIL-as-eof-value issue: https://github.com/s-expressionists/Eclector/compare/master...end-of-input-fix . compared to the second(?) solution, this one avoids introducing yet another magic value
19:39:51
scymtym
i also took the opportunity to document the differences in terms of returns values between "CL mode" and "parse result mode". does this look OK to you?
19:43:24
Bike
documenting the additional values thing is definitely good. seems like something eclector does in a few places.
19:48:21
Bike
you could use m-v-call instead of dest-bind and m-v-list to maybe save some consing, but that's a nitpick
19:54:22
scymtym
thanks. i think i considered that but didn't see how to examine the return value count, but let me check again
19:56:29
Bike
(multiple-value-call (lambda (value &optional (parse-result nil parse-result-p)) ...) (call-next-method)) would do it i think
19:58:24
Bike
it's a bit uglier than the dest-bind, maybe, but after spending time implementing multiple-value-call i kind of want to see it used to its full potential, eheh
20:24:39
scymtym
the difference in terms of consing and runtime is quite significant as well. at least in a micro-benchmark in SBCL