@mbelkin has joined the channel
has anyone else had the experience that DrRacket usage is very “broken” on newer Ubuntu versions (i.e. those using Wayland) and had to switch back to the X Window system to make it tolerable?
It makes sense that racket/gui still has problems with Wayland. It just needs more work. (Ubuntu 18.04 is switching back to Xorg, though.)
@samth, @pnwamk and others: How much does TR depend on the internal protocol for optional arguments, as exposed by expansion? I’d like to switch from a pair of arguments for optionals – the value and a boolean indicating whether the value is meaningful – to a single argument with unsafe-undefined to mean that argument wasn’t supplied. In common cases where the default expression is an immediate, the immediate can be used instead of unsafe-undefined, and then a callee-side test can be removed.
@mflatt w.r.t. Wayland/Xorg — I had not noticed Ubuntu had decided to use Xorg for the next LTS release. That greatly lowers the priority if the issue for me :smiley: Thanks for the info!
@mflatt I’m not intimately familiar with the code that handles optional args (and I didn’t deal with having to write it the first time), but I’ve poked around in there some and my sense is we’d have to rewrite most/all of it to support the new protocol. From your description, it doesn’t sound like it would be too difficult to cope with the new approach… it’s just one or two modules.
(only 400 LOC in kw-types, for example)
Can you point me to the right module?
I’m looking at “tc-lambda-unit.rkt”, but maybe that’s not the right place.
yah it’s tucked away…
in kw-types.rkt:
there’s code that converts types from what a user would see (i.e. an arrow with an optional argument) into what the actual expanded definition would have (i.e. an arg-flag and the arg itself)
(there’s a few helper functions in there that would have to be updated to reason about Undefined, etc)
Yes and I think you’re right, there would need to be tweaks in tc-lambda-unit.rkt probably, e.g. this code is explicitly reasoning about the flags that currently exist:
@mflatt I agree with @pnwamk — the code would have to change, but it sounds like it would be reasonably easy to adapt
Actually, thinking about it more, we would have to think about what the semantics of unsafe-undefined are in TR
IE, is it included in the Any type
So there might be a bit of complication
But it ought to be doable
Is this a fundamentally different “undefined” than the one we’re already reasoning about here: https://github.com/racket/typed-racket/blob/master/typed-racket-lib/typed-racket/rep/base-types.rkt#L191
@samth ^
Yes, those are different values
I’ve pushed the revised protocol to the newopt6 branch of <http://github.com:mflatt/racket\|github.com:mflatt/racket> Do you have time to look at adapting TR? I imagine we’d have to sync Racket and TR changes.
As you may expect, this is motivated by racket7 and looking that things that provide even a tiny improvement in the hope that the tiny improvements add up
I will try to look this evening, not sure about @pnwamk
If you can just post a snippet demonstrating the protocol, especially if you make a stab at typing it in TR, that would be very helpful
If I define unsafe-undefined as 'unsafe-undefined, then TR is happy with (: f7 (Integer (U 'unsafe-undefined (Boxof Integer)) Integer Integer -> (List Integer Integer Integer (Boxof Integer))))
I guess TR and the implementation of optional arguments may need to agree on which default-argument expressions mean that unsafe-undefined won’t happen. That’s currently defined by immediate-default? in “collects/racket/private/kw.rkt”