Re: [racket-users] Learning by doing Typed Racket

On 13/06/2016 03:53, Daniel Prager wrote: On Mon, Jun 13, 2016 at 10:59 AM, Matthew Butterick > wrote: Some people, when confronted with a problem, think "I know, I'll use Typed Racket." Now they have (Pairof Problem Problem). Most droll !

Re: [racket-users] Learning by doing Typed Racket

On Sun, Jun 12, 2016 at 9:53 PM, Daniel Prager wrote: > It seems that math libraries are a sweet-spot for TR. What else? > > The math library has to deal with all the same growing pains (inst, assert). I think part of the reason it looks so good is that it sparked

Re: [racket-users] Learning by doing Typed Racket

On Mon, Jun 13, 2016 at 10:59 AM, Matthew Butterick wrote: > Some people, when confronted with a problem, think "I know, I'll use Typed > Racket." Now they have (Pairof Problem Problem). > > Most droll ! Taken seriously, when is the right time for TR vs Contracts vs lots of

Re: [racket-users] Learning by doing Typed Racket

> On Jun 12, 2016, at 8:59 PM, Matthew Butterick wrote: > > Now they have (Pairof Problem Problem). :-)) [sorry for the bandwidth but this way cute] -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this

Re: [racket-users] Learning by doing Typed Racket

Some people, when confronted with a problem, think "I know, I'll use Typed Racket." Now they have (Pairof Problem Problem). On Jun 12, 2016, at 2:29 PM, Ben Greenman wrote: > Yeah I agree `inst` needs more documentation. > And as someone (Matthew B.?) suggested

Re: [racket-users] Learning by doing Typed Racket

> we could really use a systematic way of documenting the type variables on each polymorphic function. That would be most welcome! Dan On Mon, Jun 13, 2016 at 7:29 AM, Ben Greenman wrote: > Yeah I agree `inst` needs more documentation. > And as someone (Matthew

Re: [racket-users] Learning by doing Typed Racket

Yeah I agree `inst` needs more documentation. And as someone (Matthew B.?) suggested before, we could really use a systematic way of documenting the type variables on each polymorphic function. On Sun, Jun 12, 2016 at 5:23 PM, Daniel Prager wrote: > Cc:ing the list

Re: [racket-users] Learning by doing Typed Racket

Cc:ing the list ... On Sun, Jun 12, 2016 at 4:56 PM, Ben Greenman wrote: > Yep, use `inst` to instantiate the polymorphic variables to sort. > > #lang typed/racket > > ((inst sort (List Symbol Integer) Integer) > '((a 45) (b 13) (c 12) (d 16) (e 9) (f 5)) < #:key

Re: [racket-users] Learning by doing Typed Racket

Next example. In Racket: > (sort '((a 45) (b 13) (c 12) (d 16) (e 9) (f 5)) < #:key second) '((f 5) (e 9) (c 12) (b 13) (d 16) (a 45)) In Typed Racket I couldn't get a version using #:key to type-check. Pulling second into a comparison function works: > (sort '((a 45) (b 13) (c 12) (d 16) (e

Re: [racket-users] Learning by doing Typed Racket

Ah, okay. Well maybe try the Haskell or OCaml versions of the 99 problems? https://wiki.haskell.org/H-99:_Ninety-Nine_Haskell_Problems https://ocaml.org/learn/tutorials/99problems.html On Sat, Jun 11, 2016 at 3:28 AM, Daniel Prager wrote: > Hi Ben > > I wrote: > >>

Re: [racket-users] Learning by doing Typed Racket

On Sat, Jun 11, 2016 at 12:46 AM, Daniel Prager wrote: > Do you have an alternative recommendation in mind? I guess you already solved this one, but for later it might help to avoid macros. -- You received this message because you are subscribed to the Google

Re: [racket-users] Learning by doing Typed Racket

Ok, it took me a while to see how to eliminate the apply: (define-syntax-rule (table (a ...) body) (for/list : (Listof (Listof Boolean)) ([b : (Listof Boolean) (boolean-tuple (length '(a ...)))]) (match-define (list a ...) b) (append b (list ((λ ([a : Boolean] ...) : Boolean

Re: [racket-users] Learning by doing Typed Racket

On Sat, Jun 11, 2016 at 8:17 AM, Sam Tobin-Hochstadt wrote: > The easiest way to avoid this is to program with the types, and the > type checker, in mind from the start. That's what I'm trying to do, hampered by my limited of understanding of the limits of the

Re: [racket-users] Learning by doing Typed Racket

On Fri, Jun 10, 2016 at 5:17 PM, Sam Tobin-Hochstadt wrote: > The easiest way to avoid this is to program with the types, and the > type checker, in mind from the start. If you write a maximally-clever > Racket program, and then try to get it to type check, you will >

Re: [racket-users] Learning by doing Typed Racket

The easiest way to avoid this is to program with the types, and the type checker, in mind from the start. If you write a maximally-clever Racket program, and then try to get it to type check, you will probably need to change it. Also, I expect that those problems in particular seem to involve a

Re: [racket-users] Learning by doing Typed Racket

Thanks Sam I seem to repeatedly come up against this sort of problem, where I can make inferences that are beyond the ken of Typed Racket. Do you have general advice, given TR's "by design" conservatism? Dan On Sat, Jun 11, 2016 at 7:47 AM, Sam Tobin-Hochstadt wrote: >

Re: [racket-users] Learning by doing Typed Racket

The problem here is that you have a fixed-argument function (taking 3 Boolean arguments) and you're applying it to a list of unknown length. Your program knows that this won't be a problem, because `boolean-tuple` always produces a list of exactly the right length, but Typed Racket doesn't know

[racket-users] Learning by doing Typed Racket

I'm working my way through the 99 Lisp Problems ( http://www.ic.unicamp.br/~meidanis/courses/mc336/2006s2/funcional/L-99_Ninety-Nine_Lisp_Problems.html) to improve my proficiency with Typed Racket. While sometimes the discipline of the types helps me catch mistakes, quite often I find myself