[racket-users] typed/racket surprises

[Philip McGrath]

While experimenting with porting an typed program to Typed Racket, I
encountered a few surprises. Some of these seem like they might be bugs,
others missing features, and several probably are misunderstandings on my
part.

*1. struct subtyping doesn't work with #:type-name*

The following program fails to typecheck with the error "Type Checker:
parent type not a valid structure name: animal":
#lang typed/racket

(struct animal ()
  #:type-name Animal
  #:transparent)

(struct dog animal ()
  #:transparent)

Trying to use `Animal` as the parent of `dog` doesn't work either,
producing the expected error from `struct` that `Animal` is not bound to
struct type information.

*2. Problems with define-struct/exec*

There seem to be some subtleties to using applicable structs created with
define-struct/exec that I do not understand. For example, the following
program fails to typecheck:
#lang typed/racket

(define-struct/exec adder ([name : Symbol])
  [(λ (this n) (add1 n)) : (-> adder Number Number)])

(define v
  (adder 'v))

(apply v '(41))

with the error "Type Checker: Type of argument to apply is not a function
type:
adder".

I thought that I might need to add a type annotation, but I also am
confused about how to write the type of `v` in the above program. If I
change the above program to one that does typecheck:
#lang typed/racket

(define-struct/exec adder ([name : Symbol])
  [(λ (this n) (add1 n)) : (-> adder Number Number)])

(define v
  (adder 'v))

(v 41)

the REPL prints the type of v as simply `adder`, but, hovering over the use
of `v` in the last line, the tooltip in DrRacket shows the type as `(U (->
adder Number Number) adder)`.

This seems to be wrong. That function type is the type of the value for
`adder`'s prop:procedure, not the type of an `adder` when used as a
function. Annotating `v` with `(: v (U (-> adder Number Number) adder))`
causes the program to fail to typecheck.

But it isn't clear what type should be used to annotate `v`. Writing `(: v
(U (-> Number Number) adder))` also causes typechecking to fail, as does
experimenting with an intersection type or simply writing `(: v (-> Number
Number))`.

*3. parse-command-line doesn't support usage-help, help-labels, help-proc,
or unknown-proc*

The type for `parse-command-line` doesn't support the `'usage-help`
specification (or `#:usage-help` in an equivalent `command-line` form), so
the following program, which works fine in #lang racket, fails to typecheck:
#lang typed/racket

(parse-command-line
 "example"
 #("-h")
 '([usage-help "here is some usage help"])
 void
 null)

Worse, the type for the `'help-labels`/`#:help-labels` specification is
wrong, so the following program typechecks successfully but raises a
run-time error:
#lang typed/racket

(parse-command-line
 "example"
 #("-h")
 '([help-labels ("this is a help label")])
 void
 null)

I have tried to write a better contract for `parse-command-line` using
`require/typed`, but the following program, for example, fails to typecheck
with the error "cannot generate contract for variable arity polymorphic
type":
#lang typed/racket/base

(require/typed
 racket/cmdline
 [parse-command-line
  (All (b a ...)
  (-> Path-String
  (U (Listof String) (Vectorof String))
  (Listof
   (U (Pairof 'ps (Listof String))
  (Pairof
   (U 'final 'help-labels 'multi 'once-any 'once-each)
   (Listof (Listof Any)
  (-> Any a ... a b)
  (Listof String)
  b))])

Note that the type above is exactly the type reported by the #lang
typed/racket REPL for `parse-command-line` by default. Also, this type does
not support the optional "help-proc" or "unknown-proc" arguments.

Thanks to all who have worked on and promoted Typed Racket! Really, it is
remarkable how *few* surprises there are when adding types to an untyped
program.

-Philip

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Re: sharing an awesome plot - warms the cockles of my heart

[Geoffrey Knauth]

I wondered where the term "warms the cockles of my heart" comes from:

https://en.wiktionary.org/wiki/warm_the_cockles_of_someone%27s_heart

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Re: Simple loop control

[Laurent]

Indeed. If you omit `in-range', this can have a big cost on performance on
nested loops (I observe almost a factor 10 on this small example).

Note that you can also write a nested for loop with `for*':
(for* ([i (in-range 1)]
   [j (in-range 1000)])
  (void))




On Mon, Apr 2, 2018 at 10:33 AM, 若草春男  wrote:

> Thank you, Laurent.
>
> I mind the performance of in-range, but it seems to be no problem.
>
> #lang racket
>
> (time (for ([i (in-range 1)])
> (for ([j (in-range 1000)])
>   (void
>
> (time (do ([i 0 (+ i 1)]) ([= i 1])
> (do ([j 0 (+ j 1)]) ([= j 1000])
>   (void
>
> cpu time: 110 real time: 106 gc time: 0
> cpu time: 109 real time: 111 gc time: 0
>
> --
> 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.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Re: Simple loop control

[若草春男]

Thank you, Laurent.

I mind the performance of in-range, but it seems to be no problem.

#lang racket

(time (for ([i (in-range 1)])
(for ([j (in-range 1000)])
  (void

(time (do ([i 0 (+ i 1)]) ([= i 1])
(do ([j 0 (+ j 1)]) ([= j 1000])
  (void

cpu time: 110 real time: 106 gc time: 0
cpu time: 109 real time: 111 gc time: 0

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Why is there a space in the path to the Racket application on MacOSX?

[Stephen Smith]

Philip, you're right, a DSL doesn't have to mean a restricted language
(like BSL). I completely missed that point in my last response to this
thread. For some reason BSL got in my head and I incorrectly equated that
concept with the embedded DSL approach suggested by Matthias as I was
writing my response. That clearly wasn't what Matthias was suggesting, and
he even mentioned the natural backdoor. Thanks for clarifying this for me,
it was actually very helpful. Call it a momentary brain malfunction on my
part.

On Sun, Apr 1, 2018 at 10:51 PM, Philip McGrath 
wrote:

> One way the student languages from HtDP are different from most Racket
> DSLs and langs is that, in the service of regularity and nice error
> messages, they take away many convenient and powerful features of the full
> Racket language. There is not really an "escape hatch" into full Racket,
> other than importing libraries.
>
> In contrast, most Racket language extensions either simply add new
> language constructs to racket/base—think of the contract system, or the
> class-based object system—or provide forms very similar to the racket/base
> form, but with some refinement: #lang web-server transforms modules to make
> continuations serializable at interaction points, or Typed Racket adds
> syntax for specifying types. So starting your readers with a DSL doesn't
> have to mean that they have a heavily-restricted language overall (or you
> could be really ambitious and provide both a (require railroad) library and
> a #lang railroad/beginner).
>
> My first experience with Racket was through HtDP, which I loved, but,
> while I understand the good reasons for the teaching languages (especially
> the great error messages for beginners), I also have mixed feelings about
> them. For students like me who already had some (imperative,
> non-parenthesized) coding experience, there was a lot of complaining about
> conveniences of other languages that seemed to be missing from *SL (e.g. I
> believe BSL doesn't even have a mechanism for giving temporary names to
> values). When I tell other people who've been through HtDP that Racket is
> now my language of choice, I often get reactions like "Why would you want
> to use that for a real project?" and have to explain that Racket is not the
> language we learned in class. I think the text of the second edition may do
> a better job at making that distinction: we mostly used the first edition
> with little bits of the second, and certainly it was more confusing when
> everything was just called "Scheme."
>
> -Philip
>
> On Mon, Apr 2, 2018 at 1:30 AM, Stephen Smith 
> wrote:
>
>> Railroad-simulation language, absolutely! One of the key reasons that
>> Racket is on the top of the list. But what I didn't think of was to have
>> the reader use the DSL first. I was initially planning to develop the DSL
>> as a later part of the book - doing it the hard way perhaps.
>>
>> That has always been the one thing I wasn't crazy about with htdp,
>> starting with the Beginning Student language, but that's just me
>> personally. I understand the reasons for the approach. I look at it as, "I
>> don't want training wheels - let me take the real thing for a ride!", and
>> deal with the consequences later - an 
>> I-wanna-know-what's-under-the-hood-right-now
>> type of guy. For that reason, I never considered something like that for my
>> book, but the more I think of it now, it kind of makes a lot of sense for
>> my audience? I've always looked at it from an experienced programmer's
>> point of view - which doesn't necessarily fit best here.
>>
>> Thanks Matthias for giving me this suggestion to think about. I might
>> have a lot more work to do to get started using that approach, but in the
>> long run, as you say, it might get them more interested in the programming
>> part. Much appreciated food for thought.
>>
>>
>>
>> On Sunday, April 1, 2018 at 8:23:32 PM UTC-4, Matthias Felleisen wrote:
>>>
>>>
>>> On Apr 1, 2018, at 12:57 PM, Stephen Smith 
>>> wrote:
>>>
>>> my (book) project is for model railroad hobbyists (many if not most who
>>> have never programmed before).
>>>
>>>
>>>
>>> Have you considered the development of a railroad-simulation language
>>> within Racket that fits your domain? If you can provide people with a
>>> language that fits their problem area, they might be more interested in
>>> learning more about programming per se. Since embedded DSLs usually have a
>>> natural backdoor, this might be an approach that works well.
>>>
>>> In my current “hack your own language” course, some kids have gone a
>>> step further. They are interested in music theory. So they implemented a
>>> language for specifying languages in which students can then create
>>> compositions of choral music and the composition is statically checked
>>> before they even turn it in. The teacher can create a language per weekly
>>> homework and teh students