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 <dominik.pantu...@trustica.cz> 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 racket-users+unsubscr...@googlegroups.com. 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.
