Thanks for this detailed account (and for trying it out). I have some questions inline:
On Sat, Jan 2, 2021 at 5:34 PM Dominik Pantůček <[email protected]> wrote: > And now for the worse part. TR rough edges: > > * Higher-order procedures and polymorphic functions in all imaginable > combinations. That was a total disaster. Yes, the documentation clearly > states that - but typing any code using these is like trying to break a > badly designed cipher. Irregularities here and there. Sometimes simple > `inst' was enough. Sometimes casting both the function and the arguments > was necessary. The biggest trouble is that the error messages are very > cryptic and sometimes even do not point to the offending construct but > only the module file. I will provide MWE to show this if someone wants > to look into it. An example would be great here. In general you should only need one use of `inst` in any of these cases, and you shouldn't ever need a `cast`. > * Struct: Missing struct generics - when porting code that relies on > them, there's not much that can be done. This is indeed a limitation -- struct generics are complex and we (mostly Fred Fu) are thinking about them, but it's not there yet. > * Math: there really is just a natural logarithm and no logarithm with > arbitrary base? Yes, one-line to implement, but why? I'm not sure why this didn't get added originally, but it's easy to fix. > * Math/Fixnums/Flonums: All fx+/-/*/... accept two arguments only. No > unary fl-, no variadic-argument fl+ or fxior (this one hurt the most). These definitely became variadic after the type definitions were written, but that's of course not an excuse for not updating them. > * unsafe/ops: unsafe-vector-* resisted a lot - until I just gave up and > require/typed it for my particular types. Maybe casting would help, but > the error messages were different to the classical problems of the > polymorphic functions in TR. Can you say more about what happened here? > * Classes: My notes say "AAAAAAAAAAAAAAAAAAAA". Which roughly says it > all. Although I managed to back down to only using bitmap% class, > properly typing all procedures using it was a nightmare. By properly I > mean "it compiles and runs". More detail here would be helpful as well. > * with-input-from-file does not accept Path or String, only Path-String > and the conversion rules are either missing or strange at best. > Basically I ended up with just converting to String and casting to > Path-String to make everything work. > > * with-input-from-file also revealed that procedure signatures as types > can be very tricky - just passing `read' was not possible, because it > accepts some optional arguments. Wrapping it in thunk helped though. I don't understand what the problem was here; for example this works for me: #lang typed/racket (with-input-from-file "/tmp/x.rkt" read) and `Path-String` is just the union of Path and String. > * order of definitions matters. Not that this is unexpected, it is just > strange when working with larger code-base where it didn't matter. > Actually the error messages were helpful here. What do you mean by "order of definitions matters" here? > * Type annotations of procedures with variadic arguments. The only place > where I had to put annotations outside of the procedure definition. It > is nothing super-problematic, but it feels inconsistent with the rest. I would encourage type annotations before the procedure definition in all cases -- the `define` form doesn't really have the right places to put everything that can go in a function type. > * More modules need to be required everywhere. If module A provides a > procedure that accepts a type from module B, all modules using that > procedure must also require the module B to know the type. In normal > Racket it does not matter as long as you just pass the opaque data along. Can you give an example? > * Syntax macros are extra hard. As I use some syntax trickery to convert > semi-regular code to "futurized" one, I basically gave up and just ran > everything single-threaded. The main issue is passing type information > from the module that uses the macro to the macro and matching it on both > sides. Also the macro must split the type annotation from argument names > in the syntax pattern when it defines new procedures - I did some ugly > hacks to get through it but in the end I just refrained from using them > when possible (except for the unsafe-struct macro, of course). > commits, 2292-line diff!) and genuinely (it really helped). An example here would be great too. Thanks again, Sam -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/CAK%3DHD%2BaB3P6MvY8e4-%3DKxf6z6-kas5ayT4mkxRyy3DB4Vakx_Q%40mail.gmail.com.
