Multiple return values, receive and apply
I've got multiple return values and apply working in Picobit, and that means Picobit can compile SRFI-1. This post to remind myself what I am trying to achieve, because this has been a long detour.
I'm actually trying to get the time library in SRFI-19 working. It needs SRFI-6: string ports, SRFI-8: receive and by extension multiple values support. This is nothing to do with SRFI-1, other than it seemed like a good candidate for testing multiple values.
My multiple values work like this: I created a 'values' type, which is just a wrapper around a list. (values ... ) returns one of these. Two primitives: (#%apply-call proc values) and (#%proc-jump proc values) apply a proc to values (jump is for tail calls). To get the two different primitives to be called in the right places, I added a new AST node type specifically for apply, and then matched it in the compilation phase.
Having looked into SRFI-6, I now realise I don't have R5RS io primitives. Some of the names are used for functions that only work on the 'current' port which is the console.
I will want R5RS io to multiple ports, even if it's just the serial ports I support. Maybe it's time to provide some sort of user defined type mechanism.Perhaps I could re-purpose the tuple type I added like this: The car would be the wrapped data (which could be any object), and the cdr would be a reference to a symbol - the types unique identifier.
For now, I can just discriminate inside the methods. I'd really like dynamic dispatch and type inference (to work out what types are actually possible) that's compatible with the tree shaker - i.e. handlers for unused types aren't included. That might turn out to be ambitious.
I'm actually trying to get the time library in SRFI-19 working. It needs SRFI-6: string ports, SRFI-8: receive and by extension multiple values support. This is nothing to do with SRFI-1, other than it seemed like a good candidate for testing multiple values.
My multiple values work like this: I created a 'values' type, which is just a wrapper around a list. (values ... ) returns one of these. Two primitives: (#%apply-call proc values) and (#%proc-jump proc values) apply a proc to values (jump is for tail calls). To get the two different primitives to be called in the right places, I added a new AST node type specifically for apply, and then matched it in the compilation phase.
Having looked into SRFI-6, I now realise I don't have R5RS io primitives. Some of the names are used for functions that only work on the 'current' port which is the console.
I will want R5RS io to multiple ports, even if it's just the serial ports I support. Maybe it's time to provide some sort of user defined type mechanism.Perhaps I could re-purpose the tuple type I added like this: The car would be the wrapped data (which could be any object), and the cdr would be a reference to a symbol - the types unique identifier.
For now, I can just discriminate inside the methods. I'd really like dynamic dispatch and type inference (to work out what types are actually possible) that's compatible with the tree shaker - i.e. handlers for unused types aren't included. That might turn out to be ambitious.
