It works now, and it is magnificent.
Neil ⊥
On 10/06/2014 10:31 PM, Robby Findler wrote:
I think I see what's wrong. I've pushed a fix. It involved a change to
the property values, so I pushed a change to TR too.
Robby
On Mon, Oct 6, 2014 at 7:37 PM, Neil Toronto wrote:
It's from the "pict3
+ω
On Oct 6, 2014, at 8:21 PM, Neil Toronto wrote:
> On 10/06/2014 06:58 PM, Asumu Takikawa wrote:
>> On 2014-10-02 18:48:32 -0500, Robby Findler wrote:
>>> I've just pushed a change to check syntax that picks up tooltip syntax
>>> properties in syntax objects that it sees. See the docs for
>
I think I see what's wrong. I've pushed a fix. It involved a change to
the property values, so I pushed a change to TR too.
Robby
On Mon, Oct 6, 2014 at 7:37 PM, Neil Toronto wrote:
> It's from the "pict3d" package in my home directory.
>
> Neil ⊥
>
> On 10/06/2014 08:36 PM, Robby Findler wrote:
It's from the "pict3d" package in my home directory.
Neil ⊥
On 10/06/2014 08:36 PM, Robby Findler wrote:
I think I need a little more help with this one. Is that from a file in
the repo somewhere?
Robby
On Monday, October 6, 2014, Neil Toronto mailto:neil.toro...@gmail.com>> wrote:
On 10
I think I need a little more help with this one. Is that from a file in the
repo somewhere?
Robby
On Monday, October 6, 2014, Neil Toronto wrote:
> On 10/06/2014 06:58 PM, Asumu Takikawa wrote:
>
>> On 2014-10-02 18:48:32 -0500, Robby Findler wrote:
>>
>>> I've just pushed a change to check syn
On 10/06/2014 06:58 PM, Asumu Takikawa wrote:
On 2014-10-02 18:48:32 -0500, Robby Findler wrote:
I've just pushed a change to check syntax that picks up tooltip syntax
properties in syntax objects that it sees. See the docs for
mouse-over-tooltips.
Thanks to Robby's very nice addition, I've ma
On 2014-10-02 18:48:32 -0500, Robby Findler wrote:
> I've just pushed a change to check syntax that picks up tooltip syntax
> properties in syntax objects that it sees. See the docs for
> mouse-over-tooltips.
Thanks to Robby's very nice addition, I've made TR log type and type
error tooltips for D
I've just pushed a change to check syntax that picks up tooltip syntax
properties in syntax objects that it sees. See the docs for
mouse-over-tooltips.
Robby
On Thu, Oct 2, 2014 at 8:23 AM, Neil Toronto wrote:
> [rather later]
>
> When can I have this wonderful thing?
>
> As it is, I insert (ann
At Thu, 02 Oct 2014 09:23:19 -0400,
Neil Toronto wrote:
> With `case->` types, as you say, it can get tricky to find out which
> combination of argument types produces which type for any given `e` in
> the function body. It might work out to just keep the types in order and
> number them.
Would `:
[rather later]
When can I have this wonderful thing?
As it is, I insert (ann e Void) to discover the type that TR gives `e`.
The type error is very informative.
With `case->` types, as you say, it can get tricky to find out which
combination of argument types produces which type for any give
On 2014-08-12 12:39:57 -0500, Robby Findler wrote:
> B.: I don't see what you mean. Why does DrRacket know better than TR
> how to format TR types?
FWIW, if there are width limitations in the widget that DrRacket shows
the type information, DrRacket may be able to pretty-print s-expressions
better
On Tue, Aug 12, 2014 at 1:39 PM, Robby Findler
wrote:
> A. won't work; the communication has to be things that can be
> transmitted on place channels. Currently, all of this communication is
> already position-based. Of course, it's easy to make position based
> information from a syntax object.
A. won't work; the communication has to be things that can be
transmitted on place channels. Currently, all of this communication is
already position-based. Of course, it's easy to make position based
information from a syntax object.
B.: I don't see what you mean. Why does DrRacket know better th
I think that it would work better to:
a. Associate the information with a syntax object rather than a location.
b. Provide an sexp rather than a string, so that it can be formatted
appropriately by DrRacket.
Sam
On Aug 12, 2014 12:15 PM, "Robby Findler"
wrote:
> That would be great. I think you
That would be great. I think you'd just want to tell check syntax "at
this position, here is a string to show the user". Is that ok? (And
you'd put newlines in the string to format it, I guess?)
Robby
On Tue, Aug 12, 2014 at 8:55 AM, Sam Tobin-Hochstadt
wrote:
> [rather late]
>
> Typed Racket kn
[rather late]
Typed Racket knows quite a bit about the types of expressions, not
just constants, even when type checking fails. I think we could use a
logging mechanism similar to the one that allows check syntax to work
even when type checking fails to communicate types of sub-expressions
to DrRa
On Wed, Aug 06, 2014 at 08:41:40AM -0400, Matthias Felleisen wrote:
>
> On Aug 6, 2014, at 7:56 AM, Hendrik Boom wrote:
>
> > On Tue, Aug 05, 2014 at 08:53:42PM -0400, Matthias Felleisen wrote:
> >>
> >> You guys came up with some wonderful ideas.
> >>
> >> I think this particular one is easy
On Aug 6, 2014, at 7:56 AM, Hendrik Boom wrote:
> On Tue, Aug 05, 2014 at 08:53:42PM -0400, Matthias Felleisen wrote:
>>
>> You guys came up with some wonderful ideas.
>>
>> I think this particular one is easy to implement when
>> the program type checks. But when it doesn't, what do
>> you
On Tue, Aug 05, 2014 at 08:53:42PM -0400, Matthias Felleisen wrote:
>
> You guys came up with some wonderful ideas.
>
> I think this particular one is easy to implement when
> the program type checks. But when it doesn't, what do
> you show?
When the program fails to type-check, does the typ
Robby and Matthias, hello.
On 2014 Aug 6, at 02:23, Robby Findler wrote:
> Also because it is a decision that users a) have control over and b)
> may not guess TR's behavior correctly.
Very much (b). The consequences of TR's behaviour are reported later (at
type-check time) and elsewhere (in
Also because it is a decision that users a) have control over and b)
may not guess TR's behavior correctly.
Robby
On Tue, Aug 5, 2014 at 8:08 PM, Matthias Felleisen wrote:
>
> True because it is local inference. That's a thought -- Matthias
>
>
>
>
> On Aug 5, 2014, at 9:04 PM, Robby Findler wro
True because it is local inference. That's a thought -- Matthias
On Aug 5, 2014, at 9:04 PM, Robby Findler wrote:
> Is TR's type checker organized in such a way that the decisions about
> what types are given to constants decided as a separate (first) phase?
> That is, no matter the context,
Is TR's type checker organized in such a way that the decisions about
what types are given to constants decided as a separate (first) phase?
That is, no matter the context, is this constant:
#(0 0)
always going to be given the type (Vector Integer Integer), assuming
there is no annotation?
If
(1) is already done. You must declare the types of all identifiers,
in particular, variables, functions, fields, methods and structs as
a whole.
(2) is doable -- when the ti succeeds and I think we should at
least provide the opption.
On Aug 5, 2014, at 6:06 PM, Raoul Duke wrote:
>>>
You guys came up with some wonderful ideas.
I think this particular one is easy to implement when
the program type checks. But when it doesn't, what do
you show?
-- Matthias
On Aug 5, 2014, at 6:13 PM, Alexander D. Knauth wrote:
>
> On Aug 5, 2014, at 6:06 PM, Raoul Duke wrote:
>
>>
On Tue, Aug 5, 2014 at 5:00 PM, Norman Gray wrote:
> Simple, really -- cor, it's wall-to-wall epiphanies today
This made my day. What better purpose could there possibly be for a
mailing list than wall-to-wall epiphanies!
Robby
Racket Users list:
http://lists.racket-
On Aug 5, 2014, at 6:06 PM, Raoul Duke wrote:
>>> add type declarations to variables and fields and function and method
>>> signatures.
>>
>> A good motto, which I shall endeavour to remember.
>
> what i do not get about TR and other languages (ocaml, haskell, etc.)
> is: there are these
>> add type declarations to variables and fields and function and method
>> signatures.
>
> A good motto, which I shall endeavour to remember.
what i do not get about TR and other languages (ocaml, haskell, etc.)
is: there are these rules of thumb that you must somehow learn to keep
yoursel
Matthias, hello.
On 2014 Aug 5, at 14:23, Matthias Felleisen wrote:
> --- 1. There was no contradiction between Sam's email (happy birthday Sam)
> and mine.
On the contrary, I thought it was useful to see, between three alternatives,
the contrast between a minimally- and a maximally-rewritte
Alexander, hello.
On 2014 Aug 5, at 14:11, "Alexander D. Knauth" wrote:
> Well ann can’t add any detail, it can only make types less specific.
Aha: I was thinking of this the wrong way round.
If I type, say, #(1 2) into TR, it determines its type as
> #(1 2)
- : (Vector Integer Integer)
'#
In principle your email summarizes it all. I would like to add two comments
though:
--- 1. There was no contradiction between Sam's email (happy birthday Sam) and
mine. My initial reaction was to fix up your program in a 'least intrusive'
manner. That's why I left in the cast and simply pinpo
First of all, thank you all of you, I have had similar problems with not
knowing what to annotate and what not to.
On Aug 5, 2014, at 5:36 AM, Norman Gray wrote:
>
>> If I were to move this code to Typed Racket, I'd add a type declaration to
>> each identifier just like in any other (explic
Matthias and Sam, hello.
This has been a very useful brief thread for me, and also, I suspect, for
others.
On 2014 Aug 4, at 01:22, Matthias Felleisen wrote:
> In a sense, you put your finger on a sore spot of TR from R -- we are still
> figuring out how to help programmers along here.
Such
Here's how I would annotate the original program, using Matthias' type
definitions:
```
#lang typed/racket
(: 1+ (Nonnegative-Integer -> Positive-Integer))
(define (1+ n)
(+ n 1))
;; entirely unnecessary but helped me read; IGNORE
(define-type (Maybe α) (U False α))
(define-type NI Nonnegative
After some reflection, here is how I think you should proceed:
#lang typed/racket
(: 1+ (Nonnegative-Integer -> Positive-Integer))
(define (1+ n)
(+ n 1))
;; entirely unnecessary but helped me read
(define-type (Maybe α) (U False α))
(define-type NI Nonnegative-Integer)
(define-type LNI (Li
In a sense, you put your finger on a sore spot of TR from R -- we are still
figuring out how to help programmers along here. I rewrote your program like
this:
#lang typed/racket
(: 1+ (Nonnegative-Integer -> Positive-Integer))
(define (1+ n)
(+ n 1))
;; entirely unnecessary but helped me r
Greetings.
Short version: I repeatedly find myself adding TR type annotations by
trial-and-error -- I'm sure I'm missing something.
I had a particularly acute case of this this afternoon. I have a bit of
typed/racket/base code as follows:
(: 1+ (Nonnegative-Integer -> Positive-Integer))
(def
37 matches
Mail list logo
