MostAwesomeDude/pypy.irc.log Secret

## pypy.irc.log
12:15:42 <korvo> I want my RPython interpreter to be easily usable as a subprocess for a composable REPL. I already have a working REPL but I don't want to machine-parse its human-readable output.
12:15:52 <korvo> With that in mind: what are the ways of doing JSON in RPython lately?
12:18:09 <arigato> there is none that I'm aware of
12:25:56 <korvo> Hm, alright. I could try breaking out some of the PyPy stdlib to form a meaningful generic RPython module. I could write my own JSON parser with RPLY. Or I could use jq for this project since I wouldn't be reusing that much of my existing RPython REPL.
12:28:02 <arigato> ...or look at https://github.com/cheery/lever/blob/master/runtime/stdlib/json.py (which I just found with google)
12:28:41 <arigato> unlike what the comment at the top says, the code appears to contain both reading and writing
12:29:15 <korvo> And emitting JSON is merely a tree transformation. (I wish RPython had nice tree transformations and ADTs. If wishes were ponies...)
12:59:59 <korvo> Actually, I can concretize this wish. I wish that we had a good way to provide base classes whose methods can vary in return type.
13:02:33 <korvo> I suppose that we get close by replacing `return ` with `self.rv = ` within implemented methods, and then requiring an impure access for the child at the end. Like a traditional mutable visitor pattern.
18:21:04 <korvo> Huh, variance in return types can be smuggled via wrapper functions that are annotated with @specialize.argtype() for each visitor. Maybe first-order tagless-final encoding is possible.
00:38:42 <arigato> there are various hacks possible.  RPython is not a syntactically well-defined OO language, instead you can build whatever classes make sense at import time, and feed that to RPython.  E.g. if you want to use inheritance only for convenience in ways that wouldn't be correctly typed for RPython, you can copy all methods into the class instead of using inheritance
00:39:31 <arigato> (there is a decorator somewhere that does it for you, but you can do it manually too)
00:42:48 <arigato> all the @specialize decorators do something similar, they only vary in how many identical copies they end up making
00:44:04 <arigato> and in whend the copy actually occurs---it can be in advance, or it can be done lazily during the RPython annotation phase
07:58:25 <korvo> Right. objectmodel.import_from_mixin has been useful to me in the past, for example.
07:59:53 <korvo> I don't want inheritance for mixins or functionality, but for APIs; RPython won't let me duck-call objects that don't have a superclass in common, nor methods not on the superclass. I'm not sure exactly how the vtables look, but I've assumed it's like C++ vtables.
08:00:56 <korvo> Of course, I suppose that after specialization, the superclass doesn't matter and the vtables will get flattened. So perhaps this is overkill or a wrong direction.
15:58:57 <korvo> I've just finished rewriting (and debugging) my Brainfuck interpreter. It is still technically based on Brown's work, but no longer resembles it at all: https://github.com/rpypkgs/rpypkgs/blob/main/bf/bf.py
15:59:48 <korvo> I think I figured out how to apply the tagless-final style meaningfully. arigato was right about @specialize.import_from_mixin and monomorphization being a better call than trying to wedge everything into a single superclass.
16:01:56 <korvo> I was able to do optimizations in an abstracted domain. I needed to add a monoid to the algebraic signature to keep things easy to read.
16:02:39 <korvo> This is the fastest iteration of Brainfuck in RPython yet, I believe. I'd be willing to do a serious comparison with other fast interpreters if folks are interested.
16:03:11 <korvo> Let me know if y'all would like a blog post on this topic.
	12:15:42 <korvo> I want my RPython interpreter to be easily usable as a subprocess for a composable REPL. I already have a working REPL but I don't want to machine-parse its human-readable output.
	12:15:52 <korvo> With that in mind: what are the ways of doing JSON in RPython lately?
	12:18:09 <arigato> there is none that I'm aware of
	12:25:56 <korvo> Hm, alright. I could try breaking out some of the PyPy stdlib to form a meaningful generic RPython module. I could write my own JSON parser with RPLY. Or I could use jq for this project since I wouldn't be reusing that much of my existing RPython REPL.
	12:28:02 <arigato> ...or look at https://github.com/cheery/lever/blob/master/runtime/stdlib/json.py (which I just found with google)
	12:28:41 <arigato> unlike what the comment at the top says, the code appears to contain both reading and writing
	12:29:15 <korvo> And emitting JSON is merely a tree transformation. (I wish RPython had nice tree transformations and ADTs. If wishes were ponies...)
	12:59:59 <korvo> Actually, I can concretize this wish. I wish that we had a good way to provide base classes whose methods can vary in return type.
	13:02:33 <korvo> I suppose that we get close by replacing `return ` with `self.rv = ` within implemented methods, and then requiring an impure access for the child at the end. Like a traditional mutable visitor pattern.
	18:21:04 <korvo> Huh, variance in return types can be smuggled via wrapper functions that are annotated with @specialize.argtype() for each visitor. Maybe first-order tagless-final encoding is possible.
	00:38:42 <arigato> there are various hacks possible. RPython is not a syntactically well-defined OO language, instead you can build whatever classes make sense at import time, and feed that to RPython. E.g. if you want to use inheritance only for convenience in ways that wouldn't be correctly typed for RPython, you can copy all methods into the class instead of using inheritance
	00:39:31 <arigato> (there is a decorator somewhere that does it for you, but you can do it manually too)
	00:42:48 <arigato> all the @specialize decorators do something similar, they only vary in how many identical copies they end up making
	00:44:04 <arigato> and in whend the copy actually occurs---it can be in advance, or it can be done lazily during the RPython annotation phase
	07:58:25 <korvo> Right. objectmodel.import_from_mixin has been useful to me in the past, for example.
	07:59:53 <korvo> I don't want inheritance for mixins or functionality, but for APIs; RPython won't let me duck-call objects that don't have a superclass in common, nor methods not on the superclass. I'm not sure exactly how the vtables look, but I've assumed it's like C++ vtables.
	08:00:56 <korvo> Of course, I suppose that after specialization, the superclass doesn't matter and the vtables will get flattened. So perhaps this is overkill or a wrong direction.
	15:58:57 <korvo> I've just finished rewriting (and debugging) my Brainfuck interpreter. It is still technically based on Brown's work, but no longer resembles it at all: https://github.com/rpypkgs/rpypkgs/blob/main/bf/bf.py
	15:59:48 <korvo> I think I figured out how to apply the tagless-final style meaningfully. arigato was right about @specialize.import_from_mixin and monomorphization being a better call than trying to wedge everything into a single superclass.
	16:01:56 <korvo> I was able to do optimizations in an abstracted domain. I needed to add a monoid to the algebraic signature to keep things easy to read.
	16:02:39 <korvo> This is the fastest iteration of Brainfuck in RPython yet, I believe. I'd be willing to do a serious comparison with other fast interpreters if folks are interested.
	16:03:11 <korvo> Let me know if y'all would like a blog post on this topic.