freenode/#sicl - IRC Chatlog
Search
12:13:14
lukego
(please excuse that extended braindump, forgot how much I have been obsessing about all things "high level languages on bare metal" over the years, love everything in this space :))
12:19:45
scymtym
who doesn't? that's why i thought https://www.youtube.com/watch?v=cooTl4-9bhg would be an interesting encore for the clouseau presentation
12:30:14
lukego
it's also a bit of a reality check though. I dream about a LispOS... and then suddenly there are multiple to choose from - OpenGenera, Movitz, Mezzano - and I don't actually bother to run them. I think that ultimately what I want is a Lisp machine that enables me to do something new that I couldn't do before -- but I'm not sure what that would be.
12:33:59
no-defun-allowed
Picking up CL let me imagine a few new things, but I don't know if an operating system (or lack thereof) would take it any further. In the case of CLOSOS, most of the language is just "more" of what I already know (barring first class global environments again).
12:37:49
no-defun-allowed
Maybe even the first part of that is debatable; debating linguistic relativity is a bit old by now though.
12:38:08
lukego
I think that I'd be attracted by an OS that came with a good stable hardware platform that I could get invested in. the OLPC was a bit like that although not really ideal. the Amiga was /exactly/ like that but that's been dead for decades now
12:39:12
lukego
Maybe I'll connect with this again... currently I'm writing Lisp code to help me create powerful FPGA boards for a fraction of the normal price, then I want to write Lisp code for programming FPGAs, maybe this could become a Lisp machine :)
12:41:30
lukego
and maybe if the hardware were actually defined by Lisp code and synthesized onto an FPGA that would tick the "lets me do something new" box. but hard to know ahead of time.
19:53:12
karlosz
i wouldn't flush it because you might still want (lambda (x) (the fixnum x) y) to do a runtime check
19:59:43
Bike
it's involved in a snag i hit while removing rtypes. i guess to figure out if a thei needs actual multiple values i need to look at the type?
20:00:52
Bike
there's only one bit of code in clasp's extended sequences library (why? i don't know) that hits this
20:01:09
karlosz
if we ironed out our use of values types vs non values types everywhere it should be possible to just find out if its unknown-values from looking at the types of the outputs and stuff
20:07:12
Bike
i thought sbcl only gave up checking on things like values &rest types, which nobody uses anyway
20:07:43
karlosz
sbcl can do more types of conflicting i believe, and i think there are some oddities with the representation i ended up choosing for thei checking
20:08:07
karlosz
Bike: yeah, the values &rest checking is too hairy to check, and we have the same problem, except instead of saying its too hairy i think we do the wrong thing?
20:10:28
Bike
how does it work now? like, there's the type check function, and it's mv-called? and then returns the values, or no?
20:17:07
Bike
i thought the translation layer in clasp was the only thing that actually needed rtypes
20:27:07
karlosz
i was thinking the type check generation should just be thrown into mir altogether?
20:28:11
Bike
thei should be an identity possibly with side effects. so it needs multiple values if its output does. but there are some other optimizations possible, like if we infer the input is one value
20:34:40
Bike
how about - if thei doesn't have a type check function, it has the same rtype (or rather needs values coerced in the same way) as whatever it outputs to. if it does, we could always have it accept multiple values, and then pick off other cases based on inference
20:35:49
Bike
i think i'll just do that since if there's a type check it doesn't need to be enormously fast anyway, so extra values thrown around are whatever
20:37:03
Bike
then i can have generate-type-check always do the mv call rather than checking the rtype
20:39:50
Bike
karlosz: although - what's the deal with a tcfunction of :external? i don't understand your comment.
20:53:42
Bike
hang on. actually. if we do this then the optimizations we want to do are the same as we want for ANY mv call, i think
20:54:03
Bike
like if we have (mvc type-check-function form), and derive that form returns exactly one value, we make it into (funcall type-check-function form)
20:56:11
Bike
and similar for the return values, since ideally we would have local calls not forcing everything into unknown values returns like it does now
20:58:29
karlosz
Bike: :external is kinda a hack for compile time checking arguments of inlined function. the commit might explain it better
20:59:14
karlosz
yeah in sbcl all the decisions for whether to do unknown values or known values stuff is driven off of the ctypes of lvars
21:35:03
Bike
i guess this is how we can do type check functions correctly and performantly. first, we write the functions to return all values, by doing something stupid like (multiple-value-call #'values ,@required (values-list ignore)). then we derive the type of ignore to be NIL (if we figure out the number of values), which lets that be reduced to (multiple-value-call #'values ,@required), which is just (values
21:56:54
Bike
it might be necessary to rethink values-collect a bit. right now it's a little magical in having all its inputs but one be a specific kind of instruction
21:57:31
Bike
in reality we might have some heterogeneity in values counts, having various numbers of known values forms and unknown values forms