3 ms·
Well, there's a preliminary answer! Though I'm not enamored of the Typed Racket style of wrapping everything at the boundary (even as I appreciate why it's the
by skrishnamurthi 13y ago
Well, there's a preliminary answer!
Though I'm not enamored of the Typed Racket style of wrapping everything at the boundary (even as I appreciate why it's there). Not even hypothetical: we actually began developing Pyret in TR but, with great sadness, ended up having to move it out because of the enormous performance hits.
- samth 13y agoBut neither of those is a "primitive". The first is a major restriction on contracts (and not a restriction Pyret enforces, AFAICT). The second isn't a language feature at all. How would having a new language help give me either of these? And yes, soundness + interoperation + structural types = heavy performance cost. You can give up on one of those easily, but the combination can't be free. But the best way to make TR programs not pay that cost is to not cross the boundary all the time, which it sounds like is what you were doing. Why was that necessary?