[racket-users] contracts: the blame name game

[Jon Zeppieri]

Over time I've run into a number of problems trying to provide custom
struct constructors and match expanders under the same name, while also
attaching module-level contracts to the constructors. I've figured out most
of the issues (I think), but one remains. Here's an example:

===
#lang racket/base

(module foo racket/base
  (require racket/contract
   racket/match
   (for-syntax racket/base
   syntax/transformer))

  (struct bar (x y z))

  (define make-bar
(procedure-rename
 (λ (x [y 1] [z 1])
   (bar x y z))
 'bar))

  (define-module-boundary-contract
make-bar*
make-bar
(->i ([x exact-integer?])
 ([y (integer-in 0 200)]
  [z (x y) (integer-in x y)])
 [result bar?]))

  (define-match-expander make-bar**
(syntax-rules ()
  [(_ x y z) (bar x y z)])
(make-variable-like-transformer #'make-bar*))

  (provide (rename-out [make-bar** bar])))


(require 'foo)

(bar "hello")
===

The submodule here provides the name `bar` which doubles as a custom
constructor and a match-expander. And it works fine. The constructor's
contract has the right boundary, too. However, the contract violation uses
the wrong name for the constructor:

../../Applications/Racket
v6.7/collects/racket/contract/private/blame.rkt:159:0: make-bar*: contract
violation
  expected: exact-integer?
  given: "hello"
  in: the x argument of
  (->i
   ((x exact-integer?))
   ((y (integer-in 0 200))
(z (x y) (integer-in x y)))
   (result bar?))
  contract from: (anonymous-module foo)
  blaming: anonymous-module
   (assuming the contract is correct)
  at: unsaved-editor:17.2

It's calling the procedure `make-bar*`, which is the internal name, instead
of `bar`, the public name. Is there a way to get it to use the right name?

I could name the struct type itself something other than `bar`, which would
free up that name to be used internally. I've taken that approach in the
past, in fact, but there are a number of places where I need to be vigilant
about names crossing the public/private boundary (notice the use of
`procedure-rename` in the above example; without it, `bar` will evaluate --
in a public context -- to a procedure named `make-bar`, which is awkward),
and so starting with the public names seems to minimize the number of
problems.

Any thoughts?

- Jon

-- 
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] New website design feedback

[Hendrik Boom]

On Mon, Jan 02, 2017 at 11:14:02AM +, Stephen De Gabrielle wrote:

> - it resizes nicely to the small screen of my phone (i don't see the point
> as I can't use DrRacket on my iPhone...this is not a bad thing as typing
> code on a phone is a terrible idea)

I often look up documentation on my phone  while using my computer 
for coding.  Otherwise I'd have to get my laptop to talk to two 
screens, and it's just not up to that.

-- hendrik

-- 
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] New website design feedback

[Greg Trzeciak]

On Monday, January 2, 2017 at 5:50:22 PM UTC+1, Matthew Butterick wrote:

> They're just little SVG doodles made with `racket/draw`. I like to use 
> complex numbers to draw things because they're already two-dimensional. A 
> couple doodles have random elements so they change slightly when the page is 
> rebuilt. 
> 
> 
> https://github.com/racket/racket-lang-org/blob/master/www/index-illos.rkt

Thank you for the link!

-- 
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] New website design feedback

[Matthew Butterick]

> On Jan 2, 2017, at 5:42 AM, Greg Trzeciak  wrote:
> 
> The reason I asked is because I've noticed some differences between images in 
> between version of the new website so I thought that maybe some generative 
> art package was used and I wondered what it could be.

They're just little SVG doodles made with `racket/draw`. I like to use complex 
numbers to draw things because they're already two-dimensional. A couple 
doodles have random elements so they change slightly when the page is rebuilt. 

https://github.com/racket/racket-lang-org/blob/master/www/index-illos.rkt 


-- 
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] Errors in (Dr)Racket

[Philip McGrath]

I understand entirely that this was not the sort of case you seemed to have
in mind, but I'll follow up because I worry that, in the process of making
a minimal example, I may have obscured the actual problem. "The fix can be
easily located in [my] code" in the sense that it's clear that the error is
not the fault of the library writer, but I'm not sure I'd say that it can
be "easily located" in general — though obviously "easily" is a relative
term, and, again, it is only having seen just how good a great error
message can be that I can dream of a better world.

The problem with locating the error is more pronounced if the call to
serve/servlet is not in the same module as the non-serializable value, and
especially if the program being run incorporates several modules written in
#lang web-server. In larger programs like that (unfortunately I don't have
a great specific example to send right now) I have encountered error
messages with which it has not even been entirely clear which module is to
blame, let alone where within the module to start looking. (Perhaps there
is, in fact, some way to extract this information from existing messages:
all I can say is that there have been times when it has not been clear to
me.) Also, I have not found a good way to get more specific messages
through the contract system.

Certainly "(kont #)" doesn't help
much with tracking down the problem, and
"#", while it makes it sufficiently
clear that the offending value was a formlet, doesn't tell me where the
formlet is, or even where to start looking for it. If this were the first
time I were seeing this error message, I might also be confused by the fact
that stuff-url is not only not a function I called, I do not believe it is
a documented part of the API.

If there were some way of getting the error message to show, for example,
which call to send/suspend failed (in this case: the one within get-date,
which was called within start — it just happens that my tiny example only
called send/suspend once), that would be a great improvement. But, again, I
feel spoiled by the excellence of Racket's error reporting overall, and I
suspect the incremental improvements I have in mind are easier said than
done.

-Philip

P.S.: As I wrote this, I glanced at the implementation of stuff-url and saw
that it generates these error messages by using a "with-handlers" form that
runs a regexp against the message of any "exn:fail" it catches. Perhaps it
would be worth creating an exn:fail:serialize, as I know I have also
written regular expressions against that error message … I could even
imagine something like a lazily-enforced "serializable/c", especially as
"serializable?" doesn't check the contents of nested values. All just pipe
dreams, though!

On Mon, Jan 2, 2017 at 9:12 AM, Matthias Felleisen 
wrote:

>
> On Jan 2, 2017, at 7:25 AM, Philip McGrath 
> wrote:
>
>
> So why have I not complained about this?
>
> First, most generally, because the bug is clearly my fault.
>
>
>
> Hi Philip, thanks for this example. What Robby and I had in mind are calls
> to errors inside a library that baffle client programmers. When (1) it is
> clear from the error message how to fix the mistake and (2) the fix can be
> easily located in your code, there’s no problem. Our goal is to eliminate
> situations when either (1), (2) or both are unclear due to error "from the
> guts”.
>
>
> hank you for all of the thought you all have given to useful error
> messages, and for contracts specifically.
>
>
> We owe this aspect of our work to our original goal of spreading the word
> about reading, ‘riting, ‘rogramming but it turns out, it’s generally
> useful.
>
> Errors matter, POPL 2002 :-)
>
> — Matthias
>
>

-- 
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] Errors in (Dr)Racket

[Matthias Felleisen]

> On Jan 2, 2017, at 7:25 AM, Philip McGrath  wrote:
> 
> 
> So why have I not complained about this?
> 
> First, most generally, because the bug is clearly my fault. 


Hi Philip, thanks for this example. What Robby and I had in mind are calls to 
errors inside a library that baffle client programmers. When (1) it is clear 
from the error message how to fix the mistake and (2) the fix can be easily 
located in your code, there’s no problem. Our goal is to eliminate situations 
when either (1), (2) or both are unclear due to error "from the guts”. 


> hank you for all of the thought you all have given to useful error messages, 
> and for contracts specifically. 


We owe this aspect of our work to our original goal of spreading the word about 
reading, ‘riting, ‘rogramming but it turns out, it’s generally useful. 

Errors matter, POPL 2002 :-)  

— Matthias

-- 
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] New website design feedback

[Greg Trzeciak]

On Monday, January 2, 2017 at 12:14:15 PM UTC+1, spdegabrielle wrote:
> I'm guessing the 2htdp/image library was used to generate the nice 
> backgrounds as per the #lang racket Sierpinski example. You could also use 
> the racket/draw library.

The reason I asked is because I've noticed some differences between images in 
between version of the new website so I thought that maybe some generative art 
package was used and I wondered what it could be.



Also the resizing seems to be fixed now - or maybe it was never broken and I 
had old images cached causing the distortion. The new buttons (with blue 
Download) work perfectly fine.

-- 
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] Traits, inspectors, and serializable classes

[Philip McGrath]

Is there (or, if not, could there be) a way to specify the inspector when
working with traits (from racket/trait)?

I can write

> (mixin () ()
>   (inspect #f)

  ... )

but "inspect" does not seem a valid clause inside the "trait" form. (I
could also imagine that this might need to be determined at the point when
I would call trait->mixin.)

Perhaps there is a way to do this already that I could figure out if I
played with the details of current-inspector and such? Really my only use
for inspectors thus far has been to make things be transparent.

My objective would be to use a class produced using traits as a super-class
with define-serializable-class*, and keeping the super-class transparent
would preserve automatic serialization (and incidental benefits, like
support for cycles of instances).

-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.

Re: [racket-users] Errors in (Dr)Racket

[Philip McGrath]

Stephen's mention of web server code reminded of me one of the very few
situations when I've struggled with Racket error messages, so I'll both
share an example and explain why I haven't complained about it before.

Here's a buggy program:

> #lang web-server
> (require web-server/servlet-env
>  web-server/formlets
>  racket/date)
> (define (start request)
>   (response/xexpr
>`(html (head (title "Output"))
>   (body (p "You entered this date: "
>(b ,(get-date)))
> (define (get-date)
>   (define the-formlet
> (make-date-formlet))
>   (formlet-process
>the-formlet
>(send/suspend
> (λ (k-url)
>   (response/xexpr
>`(html (head (title "Get Input"))
>   (body (h1 "Enter Some Date")
> (form ([method "POST"]
>[action ,k-url])
>   ,@(formlet-display
>  the-formlet)
> (define (make-date-formlet)
>   (formlet
>(#%# ,{=> (text-input #:value (date->string
>   (current-date))
>  #:attributes `([required ""]))
>  date-str}
> (input ([type "submit"])))
>date-str))
> (serve/servlet start #:stateless? #t)


Trying to run this program produces an error message that is in many ways
quite good: the message says:

stuff-url: Cannot stuff (kont #)
into a URL because it contains non-serializable pieces. Convert
# to a serializable struct

In a tiny example like this, that's enough for me to pinpoint the bug:
formlets are represented internally as procedures, so the output of
(make-date-formlet) cannot be serialized when it's called in (get-date).

However, in larger #lang web-server programs, and especially in earlier
stages of my becoming familiar with #lang web-server, the stack trace is
unhelpful and a bit intimidating: it begins with

select-handler/no-breaks at:
  line 163, column 2, in file /Applications/Racket
v6.7/collects/racket/private/more-scheme.rkt

and runs through a list of ""s until concluding with

 at:
  line 131, column 8, in file /Applications/Racket
v6.7/share/pkgs/web-server-lib/web-server/private/dispatch-server-with-connect-unit.rkt

At no point do any of the modules named or anything like that refer to my
code.

So why have I not complained about this?

First, most generally, because the bug is clearly my fault. Even when I was
at a stage of learning when I would have struggled to debug this, the
documentation makes it very clear that "the values in the lexical scope of
your continuations must be serializable for the continuations itself to be
serializable." Likewise, the formlet documentation explains that formlets
are implemented as procedures, and there are even old posts on this mailing
list specifically discussing the fact that formlets are not serializable.
So it would seem a bit decadent, I suppose, to complain about an error
message that is (especially by the standards of other languages) not
terrible at all, and which is sufficient to make it clear that, even if I'm
not immediately sure what the problem is, it's something I need to find and
fix in my code, not something the author of the library did wrong. (In
fact, it is something that the author of the library specifically warned me
not to do, though that makes it even more perplexing when I can't
immediately figure out how I managed to do it anyway.)

Second, in the specific case of #lang web-server, I considered the
extensive transformations that run on the source-text of my code to get
serializable continuations, and which seem to have something to do with the
fact that stack traces and errors in #lang web-server are generally harder
to understand than in #lang racket (certainly they do not have Dr. Racket
highlight the offending passages of my program in red, with beautiful
arrows to show me the context in which they occurred — but that is quite a
high standard indeed). As Stephen said, the internals seemed intimidating
and I felt a bit out of my depth, but also, specifically, it seemed like
improving this situation might be more of a hard technical problem than
just using contract-out at the right place.

I'll end with a thank you for all of the thought you all have given to
useful error messages, and for contracts specifically. It certainly is one
of the reasons I have been doing so much of my programming in Racket
lately. I took an HtDP-based course after many years of programming in
traditional/imperative languages, and one of the many transformative things
I learned from it was the importance of thinking specifically about the
legal inputs and outputs of each function. I have come more and more to use
contracts internally in the code I write, because whatever hypothetical
performance cost I may incur is almost always worth it to take advantage of
this incredible infrastructure for pinpointing the problem when (not if) I
produce runtime errors.

Happy New Y

Re: [racket-users] New website design feedback

[Stephen De Gabrielle]

Great new design
FWIW I noticed the following
- when you select the code examples the grey is replaced with documentation
style linked code
- it resizes nicely to the small screen of my phone (i don't see the point
as I can't use DrRacket on my iPhone...this is not a bad thing as typing
code on a phone is a terrible idea)

I'm guessing the 2htdp/image library was used to generate the nice
backgrounds as per the #lang racket Sierpinski example. You could also use
the racket/draw library.

Kind regards
Stephen

On Mon, 2 Jan 2017 at 10:13, Greg Trzeciak  wrote:

> On Thursday, December 29, 2016 at 6:46:12 PM UTC+1, Matthew Butterick
> wrote:
>
>
>
> > I darkened them a bit. But grey text has been used in screen interfaces
> for 30 yrs to indicate de-emphasis, and is widely used on today's web (e.g.
> Github). That particular horse is long out of the barn.
>
>
>
> I'd rather think of myself as being ahead of time ;)
>
>
>
> Now to the serious points - it looks really good now and satisfies all of
> the issues I had. One new minor issue - when you resize your browser to the
> minimum width possible the top 3 buttons (docs, packages, download) are the
> only elements that don't fit in one line and slightly distort the
> eye-pleasing layout .
>
>
>
> BTW What did you use to generate those images used behind eg. "Powerful
> macros & languages"?
>
>
>
> --
>
> 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.
>
> --
Kind regards,
Stephen
--
Bigger than Scheme, cooler than Clojure & more fun than CL.(n=1)
--

-- 
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] New website design feedback

[Greg Trzeciak]

On Thursday, December 29, 2016 at 6:46:12 PM UTC+1, Matthew Butterick wrote:

> I darkened them a bit. But grey text has been used in screen interfaces for 
> 30 yrs to indicate de-emphasis, and is widely used on today's web (e.g. 
> Github). That particular horse is long out of the barn. 

I'd rather think of myself as being ahead of time ;)

Now to the serious points - it looks really good now and satisfies all of the 
issues I had. One new minor issue - when you resize your browser to the minimum 
width possible the top 3 buttons (docs, packages, download) are the only 
elements that don't fit in one line and slightly distort the eye-pleasing 
layout .

BTW What did you use to generate those images used behind eg. "Powerful macros 
& languages"?

-- 
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.