Cool, we can pick the best version :-))
> On Jul 13, 2016, at 7:27 AM, Jack Firth wrote:
>
> On Tuesday, July 12, 2016 at 2:36:24 PM UTC-7, Sam Tobin-Hochstadt wrote:
>> Could this be an API like the one for tooltips? IOW, some sort of general
>> warning with a message and a syntax location?
On Tuesday, July 12, 2016 at 2:36:24 PM UTC-7, Sam Tobin-Hochstadt wrote:
> Could this be an API like the one for tooltips? IOW, some sort of general
> warning with a message and a syntax location?
I'd just like to interject quickly and say that's what I'm working on for
RacketCon :)
--
You re
OC gets its dead code info from TR, so the two should agree.
Vincent
On Tue, 12 Jul 2016 16:54:10 -0500,
Robby Findler wrote:
>
> I think you are saying that TR does not declare variables in for/hash
> as dead code but that OC does. Is that what you're saying? Is that
> true?
>
> Robby
>
> On
This isn't really a for loop specific problem -- any complicated macro
could run into this, and so we need a more general solution.
Sam
On Tue, Jul 12, 2016, 6:17 PM Matthias Felleisen
wrote:
>
> Alex is working on for loops in general, using a suggestion from Asumu.
>
>
>
> > On Jul 12, 2016,
Alex is working on for loops in general, using a suggestion from Asumu.
> On Jul 12, 2016, at 6:13 PM, Sam Tobin-Hochstadt wrote:
>
> I've opened https://github.com/racket/typed-racket/issues/402 to track those
> issues.
>
> What's likely going on is that `for/hash` expands into some code
I've opened https://github.com/racket/typed-racket/issues/402 to track
those issues.
What's likely going on is that `for/hash` expands into some code that is
unreachable, and gives it the source location of the full `for/hash`
expression. I think we can do a better job with avoiding this, though.
I think you are saying that TR does not declare variables in for/hash
as dead code but that OC does. Is that what you're saying? Is that
true?
Robby
On Tue, Jul 12, 2016 at 4:51 PM, Matthias Felleisen
wrote:
>
> The coach is different from the type checker.
>
> I think that the type checker shou
Sorry, I really should have said “for/* loops are a mess in types.”
Otherwise the OC is a tool you should use for optimization hunting,
not type error hunting.
> On Jul 12, 2016, at 5:54 PM, Robby Findler
> wrote:
>
> I think you are saying that TR does not declare variables in for/hash
>
The coach is different from the type checker.
I think that the type checker should use these colors only when type
checking succeeds, and in that case, I’d consider the colors highly
useful.
> On Jul 12, 2016, at 5:46 PM, Robby Findler
> wrote:
>
> That would require too mcuh work an
That would require too mcuh work and also be ugly, IMO. :)
I think that an on-mouseover option would be too hard to discover.
John raises a good point.
Robby
On Tue, Jul 12, 2016 at 4:42 PM, Sam Tobin-Hochstadt
wrote:
> I hesitate to suggest it as well, but what about the little red
> squiggl
> On Jul 12, 2016, at 2:38 PM, Robby Findler
> wrote:
>
> Yes.
>
> I hesitate to suggest it, but would a background color on the text be
> the way to go? I find that a bit on the annoying side, tho.
>
> You could use an existing pipeline to do something like the unused
> require highlighting
I hesitate to suggest it as well, but what about the little red
squiggles seen in editors/word processors/etc?
But I'm happy with any of these options.
Sam
On Tue, Jul 12, 2016 at 5:38 PM, Robby Findler
wrote:
> Yes.
>
> I hesitate to suggest it, but would a background color on the text be
> th
Yes.
I hesitate to suggest it, but would a background color on the text be
the way to go? I find that a bit on the annoying side, tho.
You could use an existing pipeline to do something like the unused
require highlighting (which requires mouseover).
Robby
On Tue, Jul 12, 2016 at 4:36 PM, Sam T
Could this be an API like the one for tooltips? IOW, some sort of general
warning with a message and a syntax location?
Sam
On Tue, Jul 12, 2016 at 5:34 PM Robby Findler
wrote:
> I think it would be straightforward to add something to Check Syntax
> that reported unreachable code and that seems
I think it would be straightforward to add something to Check Syntax
that reported unreachable code and that seems pretty cool and useful
for TR. So CS could report any code that TR could prove was
unreachable and yet the code came from the original program. I guess
if John had seen that showing up
> On Jul 12, 2016, at 5:07 PM, Sam Tobin-Hochstadt wrote:
>
>>
>> 2) Is there some nice user interface that we could use to make the warnings
>> visible to the case of the user? Maybe a “I think I have a bug, can I see
>> the compilation warnings” button?
>
> I agree -- I think we need a bet
On Tue, Jul 12, 2016 at 4:50 PM, 'John Clements' via Racket Users
wrote:
>
> So, I have two questions:
>
> 1) Why doesn’t the optimization coach locate the unreachable code in this
> example? Perhaps it’s too small?
TR doesn't prove that the else branch is unreachable. I think what's
happening i
> On Jul 12, 2016, at 4:50 PM, 'John Clements' via Racket Users
> wrote:
>
> lang typed/racket
>
> (: process-number (Integer -> (U 'both-odd 'not-both-odd)))
> (define (process-number n)
> (if (andmap is-odd? (list (sub1 n) (add1 n)))
> 'both-odd
> 'not-both-odd))
>
> (: is-odd? (
Quick puzzle: why does this program return the wrong answer:
#lang typed/racket
(: process-number (Integer -> (U 'both-odd 'not-both-odd)))
(define (process-number n)
(if (andmap is-odd? (list (sub1 n) (add1 n)))
'both-odd
'not-both-odd))
(: is-odd? (Integer -> (U 'odd 'even)))
(de
19 matches
Mail list logo
