Re: [racket-users] type annotation example

[Sam Tobin-Hochstadt]

Brian,
Since this has turned out to be relevant for other reasons, can you
say how you ended up using version 6.0? Was it automatically available
to you somewhere, or did you install it?

Sam

On Mon, Feb 25, 2019 at 1:46 PM Brian Craft  wrote:
>
> yeah, maybe version. Has this changed since 6.0?
>
> On Monday, February 25, 2019 at 10:39:23 AM UTC-8, johnbclements wrote:
>>
>> When I paste that code into a file called `foo`, it runs fine. Transcript:
>>
>> hardy:/tmp clements> cat foo
>> #lang typed/racket
>> (require typed/racket/base)
>>
>> (: fn (-> String Symbol))
>> (define (fn str) 'foo)
>> hardy:/tmp clements> racket foo
>> hardy:/tmp clements>
>>
>> I can’t honestly guess what the problem is. Wrong version of racket?
>>
>> John
>>
>>
>> > On Feb 25, 2019, at 10:11 AM, Brian Craft  wrote:
>> >
>> > Doing a cut & paste from the typed racket docs, I'm getting a compile 
>> > error. Input file:
>> >
>> > #lang typed/racket
>> > (require typed/racket/base)
>> >
>> > (: fn (-> String Symbol))
>> > (define (fn str) 'foo)
>> >
>> >
>> > 'fn' taken from this page:
>> >
>> > https://docs.racket-lang.org/ts-guide/more.html#%28part._when-annotations~3f%29
>> >
>> >
>> > Running with 'racket foo', gives me
>> > Type Checker: ->: bad syntax
>> >   in: (-> String Symbol)
>> >
>> >
>> > What am I doing wrong?
>> >
>> >
>> > --
>> > 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...@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.

-- 
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] type annotation example

[Alex Knauth]

> On Feb 25, 2019, at 2:05 PM, Sam Tobin-Hochstadt  wrote:
> 
> Version 6.0 was released 5 years ago, so while I don't recall exactly when 
> the prefix -> syntax was introduced, it was most likely since then. 

The -> prefix syntax was introduced in version 6.0.1. If you really need to use 
6.0, you can use (String -> Symbol) instead.

However if you can upgrade, you probably should. A lot of things have improved 
in Typed Racket between 6.0 and now.

Alex Knauth

> Sam
> 
> On Mon, Feb 25, 2019, 1:46 PM Brian Craft  > wrote:
> yeah, maybe version. Has this changed since 6.0?
> 
> On Monday, February 25, 2019 at 10:39:23 AM UTC-8, johnbclements wrote:
> When I paste that code into a file called `foo`, it runs fine. Transcript: 
> 
> hardy:/tmp clements> cat foo 
> #lang typed/racket 
> (require typed/racket/base) 
> 
> (: fn (-> String Symbol)) 
> (define (fn str) 'foo) 
> hardy:/tmp clements> racket foo 
> hardy:/tmp clements> 
> 
> I can’t honestly guess what the problem is. Wrong version of racket? 
> 
> John 
> 
> 
> > On Feb 25, 2019, at 10:11 AM, Brian Craft > wrote: 
> > 
> > Doing a cut & paste from the typed racket docs, I'm getting a compile 
> > error. Input file: 
> > 
> > #lang typed/racket 
> > (require typed/racket/base) 
> > 
> > (: fn (-> String Symbol)) 
> > (define (fn str) 'foo) 
> > 
> > 
> > 'fn' taken from this page: 
> > 
> > https://docs.racket-lang.org/ts-guide/more.html#%28part._when-annotations~3f%29
> >  
> > 
> >  
> > 
> > 
> > Running with 'racket foo', gives me 
> > Type Checker: ->: bad syntax 
> >   in: (-> String Symbol) 
> > 
> > 
> > What am I doing wrong? 
> > 
> > 
> > -- 
> > 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...@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 
> .
> 
> -- 
> 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.

Re: [racket-users] Scribble wraps @verbatim? Also, comments on Scribble

[Ben Greenman]

> It bothers me that the change applies only to HTML output and not PDF
> output via LaTeX, but I don't see a way to get that effect via LaTeX
> without substantial changes.

Is it possible to wrap each line in an \mbox, or to have SVerbatim
make the \textwidth extremely wide?

-- 
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] Scribble wraps @verbatim? Also, comments on Scribble

[Matthew Flatt]

At Wed, 27 Feb 2019 14:58:54 -0500, David Storrs wrote:
> Turning off line wrapping would definitely be good, yes.

I've pushed that change.

It bothers me that the change applies only to HTML output and not PDF
output via LaTeX, but I don't see a way to get that effect via LaTeX
without substantial changes.

-- 
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] Scribble wraps @verbatim? Also, comments on Scribble

[David Storrs]

On Wed, Feb 27, 2019 at 1:59 PM Matthew Flatt  wrote:
>
> At Wed, 27 Feb 2019 12:51:58 -0500, David Storrs wrote:
> > On Wed, Feb 27, 2019 at 12:34 PM Matthew Flatt  wrote:
> > > The line breaks are added by a browser, because `verbatim` doesn't
> > > generate anything that disables line wrapping.
> >
> > I'm pretty sure that this is not coming from my browser, but is
> > instead down to the pixel-based max-width in manual.css
>
> I agree that `max-width` triggers line breaks here earlier than they
> might happen if left to the defaults of your browser (assuming that you
> browser window is wide enough). I don't think the use of px causes the
> `max-width` specification to work other than as intended, though,
> particularly since the font sizes are also px.

I suppose I said that badly.  Yes, I agree that having max-width in
pixels works as intended, but I think the intent is wrong.  Content
flow should be left to the browser unless there's a specific reason
not to.  As such, I think it would be better if the CSS defined
left/right margin widths in rems but did not specify a pixel width.
Having a max-width of 970px on a 5120×2880 monitor with your browser
fullscreened looks silly.  If code gets flowed awkwardly when the
window is too narrow, that's on the user.

Separately, it would also be good to move away from a table-based
layout; among other reasons, they are hell on screenreaders and
scrapers.  Having the HTML be purely semantic and the presentation
defined by the CSS is a better approach, and would also facilitate
building tools that scrape / embed the docs.

>
> Maybe the issue is that paragraphs in general wrap too narrowly for
> your purposes, in which case the solution is probably to use a
> different overall document style. But I had assumed that you wanted
> `verbatim` to stretch beyond the normal text-column bounds, possibly
> within Racket documentation where the basic style is imposed, in which
> case it's a question of `verbatim` turning off line wrapping. Is that
> not right?

Turning off line wrapping would definitely be good, yes.


>

-- 
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: Scribble wraps @verbatim? Also, comments on Scribble

[David Storrs]

Ah, nice.  Thanks, Joel.

On Wed, Feb 27, 2019 at 1:59 PM 'Joel Dueck' via Racket Users
 wrote:
>
>
> On Wednesday, February 27, 2019 at 11:03:46 AM UTC-6, David K. Storrs wrote:
>>
>> Also, it would be really spiffy if the generated HTML was
>> pretty-printed.  Having it minified seems unnecessary and
>> disadvantageous.
>>
>
> On occasions where I’ve wanted to go spelunking in Scribble-generated HTML, I 
> used the HTML Tidy utility: http://www.html-tidy.org/
>
> I've also used tidy to clean up generated HTML as a separate build step in 
> the makefile in some of my projects. It does a great job.
>
> --
> 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.

Re: [racket-users] TR: tighten type of "random" ? (and so much more...)

[Sam Tobin-Hochstadt]

1. I think the Flonum -> Nonnegative-Flonum change would be easy to do.
2. `define-predicate` uses contracts, and contracts have significant
overhead that simpler functions like `positive?` don't.
3. Can you file bugs for the OC issue?

Sam

On Wed, Feb 27, 2019 at 2:23 PM 'John Clements' via Racket Users
 wrote:
>
> I was doing some very low-key monte carlo testing today, and I wanted to 
> whether it would magically get faster if I used TR. The short answer is … 
> well, wait on that. Here’s my program; it’s supposed to check the likelihood 
> that three randomly chosen numbers in the interval 0-1 could be the sides of 
> an acute triangle:
>
> #lang typed/racket
>
>
> (define-predicate nneg-flonum? Nonnegative-Flonum)
> ;; comment it out for no-check...
> ; (define (nneg-flonum? n) #t)
>
> (define (run-trials [trials : Natural])
>   (exact->inexact
>(/ (for/sum : Natural
> ([i (in-range trials)])
> (define a (assert (random) nneg-flonum?))
> (define b (assert (random) nneg-flonum?))
> (define c (assert (random) nneg-flonum?))
> (if (and (< (abs (- a b)) c)
>  (< c (sqrt (+ (* a a) (* b b)
> 1
> 0))
>   trials)))
>
>
> (time
>  (for ([i : Natural (in-range 26)])
>(define trials (expt 2 i))
>(printf "~v trials: ~v\n"
>trials (run-trials trials
>
> ;; IN DRRACKET, "no debugging or profiling"
>
> ;; TR:cpu time: 37953 real time: 36371 gc time: 3849
> ;; TR/NC: cpu time: 33632 real time: 33959 gc time: 8511
>
> ;; COMMAND-LINE
>
> ;; TR:cpu time: 24707 real time: 24693 gc time: 27
> ;; TR:cpu time: 26602 real time: 26610 gc time: 27
> ;; TR/NC: cpu time: 12735 real time: 12727 gc time: 132
> ;; TR/NC: cpu time: 12715 real time: 12713 gc time: 116
>
>
> One thing that I was curious about was the necessity for the assertion on the 
> result of random. Specifically, it appears to me that the result of the call 
> (random) is guaranteed to be a Nonnegative-Flonum, but the type on Random is 
> not that specific:
>
> (case->
>  (->* (Integer Integer) (Pseudo-Random-Generator) Nonnegative-Fixnum)
>  (->* (Integer) (Pseudo-Random-Generator) Nonnegative-Fixnum)
>  (->* () (Pseudo-Random-Generator) Flonum))
>
>
> Is there a reason for this?
>
>
> More generally, of course, I’d like to know why the TR version isn’t faster; 
> I ran the given timings on the command-line, which seemed to speed up the 
> no-check version immensely and the TR version hardly at all. I checked the 
> optimization coach, and all of the numeric portions are solid green. Maybe 
> the numeric portion of the inner loop isn’t the slow part?
>
> I tried some amateur loop-unrolling, duplicating the inner body 4 times and 
> running the loop 1/4 as many times, and … got essentially no difference, 
> which would suggest that the arithmetic part *is* the slow part.
>
> …
>
> or
>
> … Ah! It’s the calls to “random”. reducing the calls to random by a factor of 
> four makes the code run about four times faster. Hmm… How about those 
> assertions?
>
> Oh! look! changing (assert (random) nneg-flonum?) into (assert (random) 
> positive?) makes the code twice as fast! So apparently using an assert with a 
> define-predicate is not a good idea, at least in this case. Is that generally 
> true?
>
> Okay, I just went to “show more” on the Optimization Coach, and two 
> fascinating things happened
> 1) The colors went bananas, and editing the file put me in sliding-highlight 
> hell, so I had to close and re-open the buffer.
> 2) The optimization coach suggested that the parameter lookup of 
> (current-pseudo-random-generator) could be slow, so I should look it up once. 
> I took this advice and…
> racket is now segfaulting reliably. Whoops! Time to file a PR.
>
> Well, okay, that’s (tallying…) one change request (type of random), one 
> question (bad idea to use define-predicate?), one vague bug report 
> (optimization coach coloring), and one straight-up crash (seg fault). I think 
> I’ve used my quota, back to real work.
>
> John
>
>
>
>
>
>
> --
> 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] TR: tighten type of "random" ? (and so much more...)

['John Clements' via Racket Users]

I was doing some very low-key monte carlo testing today, and I wanted to 
whether it would magically get faster if I used TR. The short answer is … well, 
wait on that. Here’s my program; it’s supposed to check the likelihood that 
three randomly chosen numbers in the interval 0-1 could be the sides of an 
acute triangle:

#lang typed/racket


(define-predicate nneg-flonum? Nonnegative-Flonum)
;; comment it out for no-check...
; (define (nneg-flonum? n) #t)

(define (run-trials [trials : Natural])
  (exact->inexact
   (/ (for/sum : Natural
([i (in-range trials)])
(define a (assert (random) nneg-flonum?))
(define b (assert (random) nneg-flonum?))
(define c (assert (random) nneg-flonum?))
(if (and (< (abs (- a b)) c)
 (< c (sqrt (+ (* a a) (* b b)
1
0))
  trials)))


(time
 (for ([i : Natural (in-range 26)])
   (define trials (expt 2 i))
   (printf "~v trials: ~v\n"
   trials (run-trials trials

;; IN DRRACKET, "no debugging or profiling"

;; TR:cpu time: 37953 real time: 36371 gc time: 3849
;; TR/NC: cpu time: 33632 real time: 33959 gc time: 8511

;; COMMAND-LINE

;; TR:cpu time: 24707 real time: 24693 gc time: 27
;; TR:cpu time: 26602 real time: 26610 gc time: 27
;; TR/NC: cpu time: 12735 real time: 12727 gc time: 132
;; TR/NC: cpu time: 12715 real time: 12713 gc time: 116


One thing that I was curious about was the necessity for the assertion on the 
result of random. Specifically, it appears to me that the result of the call 
(random) is guaranteed to be a Nonnegative-Flonum, but the type on Random is 
not that specific:

(case->
 (->* (Integer Integer) (Pseudo-Random-Generator) Nonnegative-Fixnum)
 (->* (Integer) (Pseudo-Random-Generator) Nonnegative-Fixnum)
 (->* () (Pseudo-Random-Generator) Flonum))


Is there a reason for this?


More generally, of course, I’d like to know why the TR version isn’t faster; I 
ran the given timings on the command-line, which seemed to speed up the 
no-check version immensely and the TR version hardly at all. I checked the 
optimization coach, and all of the numeric portions are solid green. Maybe the 
numeric portion of the inner loop isn’t the slow part?

I tried some amateur loop-unrolling, duplicating the inner body 4 times and 
running the loop 1/4 as many times, and … got essentially no difference, which 
would suggest that the arithmetic part *is* the slow part.

…

or

… Ah! It’s the calls to “random”. reducing the calls to random by a factor of 
four makes the code run about four times faster. Hmm… How about those 
assertions?

Oh! look! changing (assert (random) nneg-flonum?) into (assert (random) 
positive?) makes the code twice as fast! So apparently using an assert with a 
define-predicate is not a good idea, at least in this case. Is that generally 
true?

Okay, I just went to “show more” on the Optimization Coach, and two fascinating 
things happened
1) The colors went bananas, and editing the file put me in sliding-highlight 
hell, so I had to close and re-open the buffer.
2) The optimization coach suggested that the parameter lookup of 
(current-pseudo-random-generator) could be slow, so I should look it up once. I 
took this advice and…
racket is now segfaulting reliably. Whoops! Time to file a PR.

Well, okay, that’s (tallying…) one change request (type of random), one 
question (bad idea to use define-predicate?), one vague bug report 
(optimization coach coloring), and one straight-up crash (seg fault). I think 
I’ve used my quota, back to real work.

John






-- 
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: Scribble wraps @verbatim? Also, comments on Scribble

['Joel Dueck' via Racket Users]

On Wednesday, February 27, 2019 at 11:03:46 AM UTC-6, David K. Storrs wrote:

> Also, it would be really spiffy if the generated HTML was 
> pretty-printed.  Having it minified seems unnecessary and 
> disadvantageous. 
>
>
On occasions where I’ve wanted to go spelunking in Scribble-generated HTML, 
I used the HTML Tidy utility: http://www.html-tidy.org/

I've also used tidy to clean up generated HTML as a separate build step in 
the makefile in some of my projects. It does a great job.

-- 
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] Scribble wraps @verbatim? Also, comments on Scribble

[Matthew Flatt]

At Wed, 27 Feb 2019 12:51:58 -0500, David Storrs wrote:
> On Wed, Feb 27, 2019 at 12:34 PM Matthew Flatt  wrote:
> > The line breaks are added by a browser, because `verbatim` doesn't
> > generate anything that disables line wrapping.
> 
> I'm pretty sure that this is not coming from my browser, but is
> instead down to the pixel-based max-width in manual.css

I agree that `max-width` triggers line breaks here earlier than they
might happen if left to the defaults of your browser (assuming that you
browser window is wide enough). I don't think the use of px causes the
`max-width` specification to work other than as intended, though,
particularly since the font sizes are also px.

Maybe the issue is that paragraphs in general wrap too narrowly for
your purposes, in which case the solution is probably to use a
different overall document style. But I had assumed that you wanted
`verbatim` to stretch beyond the normal text-column bounds, possibly
within Racket documentation where the basic style is imposed, in which
case it's a question of `verbatim` turning off line wrapping. Is that
not right?

-- 
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] R6RS history

[Arthur Nunes-Harwitt]

Dear Matthias,

  Would you be willing to share your thoughts about the history of 
denotational versus operational semantics in the report?


  Thanks.

==
Arthur Nunes-Harwitt
Computer Science Department, Rochester Institute of Technology
Room 70-3509
585-475-4916
==

"I don't know what the language of the future will be
called, but it will look like LISP."

This email is confidential and intended for the named recipient(s). In
the event the email is received by someone other than the recipient,
please notify the sender at a...@cs.rit.edu.

On Tue, 26 Feb 2019, Matthias Felleisen wrote:




Let me inject some comments that make it a bit more obvious what’s happening 
here:



On Feb 26, 2019, at 3:33 PM, Sam Tobin-Hochstadt  wrote:



RnRS meetings from 1984 thru 2003 adhere to the “unanimity rule” originating 
from the MIT group.

In 2001, I created and ran “Scheme and Functional Programming” (SFP), a first 
annual Scheme workshop that also subsumed “Scheme Report” meetings.



2003: New Scheme Standard proposed at the Scheme Workshop


At the 2003 Boston SFP, I proposed going to a majority rule so that the Scheme 
standard could grow into a useful language after a long long day, with many 
people gone. The motion passed.


2006: First draft of R6RS released
2007: R6RS Ratified by community vote after extensive discussion and revision


I wrote an essay entitled “The R6RS is Perfect”. The certification vote 
succeeded with just a few votes more than needed (60% or 66% or something like 
that).



2009: A new Scheme Standard steering committee elected by a community
vote. The new committee reflected opposition to the R6RS.


(as in “community vote” by another Scheme workshop)


We, the Racketeers, didn’t want to be in their way so we wrote this:

https://racket-lang.org/new-name.html

History is history. The future you can change, unless Gödel is right about 
Einstein’s equations and it’s practical.

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



--
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] Scribble wraps @verbatim? Also, comments on Scribble

[David Storrs]

On Wed, Feb 27, 2019 at 12:34 PM Matthew Flatt  wrote:
>
> At Wed, 27 Feb 2019 12:03:33 -0500, David Storrs wrote:
> > I have a .scrbl file with the following:
> >
> > @verbatim{
> > ...stuff...
> > | #:rule (rule-name #:transform field-id
> > (field-id ...+) (code ...+))
> > }
> >
> > My expectation is that this will render, well, verbatim.  Instead, it
> > adds a line break so that I get:
> >
> > | #:rule (rule-name #:transform field-id (field-id
> > ...+) (code ...+))
> >
> > Am I not understanding something?
>
> The line breaks are added by a browser, because `verbatim` doesn't
> generate anything that disables line wrapping.

I'm pretty sure that this is not coming from my browser, but is
instead down to the pixel-based max-width in manual.css


>
> Probably it would make sense to have `verbatim` use a style that
> disables line breaks through `white-space: nowrap` CSS, as form like
> `racketblock` do. That would address line breaking for HTML output, at
> least.
>
> Possibly, this wasn't done before because overflowing a column often
> means that things need to be written to avoid the overflow, anyway.
>
> I can make this change, unless someone knows a reason that it wouldn't
> be a good idea.
>
> > Separately, a comment on the HTML that is generated from Scribble:
> > [...]
> > It's fine to do this:
> >
> > .maincolumn { font-family: monospace }
> > .refpara { font-family: monospace }
>
> That format doesn't achieve the goal of having the word "monospace"
> appear once so that it can be changed in one place.
>
> > Also, it would be really spiffy if the generated HTML was
> > pretty-printed.  Having it minified seems unnecessary and
> > disadvantageous.
>
> The generated HTML is not specifically minified. Instead, the problem
> would be to add whitespace that isn't there o start with.
> Unfortunately, the library that prints the representation used for HTML
> doesn't have enough information to know where whitespace can be added
> without changing the meaning of the document.
>
> --
> 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.

Re: [racket-users] Scribble wraps @verbatim? Also, comments on Scribble

[Matthew Flatt]

At Wed, 27 Feb 2019 12:03:33 -0500, David Storrs wrote:
> I have a .scrbl file with the following:
> 
> @verbatim{
> ...stuff...
> | #:rule (rule-name #:transform field-id
> (field-id ...+) (code ...+))
> }
> 
> My expectation is that this will render, well, verbatim.  Instead, it
> adds a line break so that I get:
> 
> | #:rule (rule-name #:transform field-id (field-id
> ...+) (code ...+))
> 
> Am I not understanding something?

The line breaks are added by a browser, because `verbatim` doesn't
generate anything that disables line wrapping.

Probably it would make sense to have `verbatim` use a style that
disables line breaks through `white-space: nowrap` CSS, as form like
`racketblock` do. That would address line breaking for HTML output, at
least.

Possibly, this wasn't done before because overflowing a column often
means that things need to be written to avoid the overflow, anyway.

I can make this change, unless someone knows a reason that it wouldn't
be a good idea.

> Separately, a comment on the HTML that is generated from Scribble:
> [...]
> It's fine to do this:
> 
> .maincolumn { font-family: monospace }
> .refpara { font-family: monospace }

That format doesn't achieve the goal of having the word "monospace"
appear once so that it can be changed in one place.

> Also, it would be really spiffy if the generated HTML was
> pretty-printed.  Having it minified seems unnecessary and
> disadvantageous.

The generated HTML is not specifically minified. Instead, the problem
would be to add whitespace that isn't there o start with.
Unfortunately, the library that prints the representation used for HTML
doesn't have enough information to know where whitespace can be added
without changing the meaning of the document.

-- 
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: Scribble wraps @verbatim? Also, comments on Scribble

[David Storrs]

On Wed, Feb 27, 2019 at 12:03 PM David Storrs  wrote:
>
> I have a .scrbl file with the following:
>
> @verbatim{
> ...stuff...
> | #:rule (rule-name #:transform field-id
> (field-id ...+) (code ...+))
> }
>
> My expectation is that this will render, well, verbatim.  Instead, it
> adds a line break so that I get:
>
> | #:rule (rule-name #:transform field-id (field-id
> ...+) (code ...+))
>
> Am I not understanding something?

Found the problem:  The manual.scrbl file uses pixel-based max widths.
This seems odd, since the CSS is generally defined using rems, which
is a much better solution.

>
>
> Separately, a comment on the HTML that is generated from Scribble:
>
> It uses table-based layout and then adds CSS on top of that.  This seems odd.
>
> The standard scribble.css file includes the following comment:
>
> ===quote
> /* CSS seems backward: List all the classes for which we want a
>particular font, so that the font can be changed in one place.  (It
>would be nicer to reference a font definition from all the places
>that we want it.)
>
>As you read the rest of the file, remember to double-check here to
>see if any font is set. */
> ===/quote
>
> It's perfectly legit to do it the other way around, and in fact that's
> the more standard way.  Instead of putting this at the top of the
> file:
>
> /* Monospace: */
> .maincolumn, .refpara, .refelem, .tocset, .stt, .hspace, .refparaleft,
> .refelemleft {
>   font-family: monospace;
> }
>
> It's fine to do this:
>
> .maincolumn { font-family: monospace }
> .refpara { font-family: monospace }
>
>
> Also, it would be really spiffy if the generated HTML was
> pretty-printed.  Having it minified seems unnecessary and
> disadvantageous.
>
> Are these things that people are open to changing and, if so, is there
> a way I can help?

-- 
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] Scribble wraps @verbatim? Also, comments on Scribble

[David Storrs]

I have a .scrbl file with the following:

@verbatim{
...stuff...
| #:rule (rule-name #:transform field-id
(field-id ...+) (code ...+))
}

My expectation is that this will render, well, verbatim.  Instead, it
adds a line break so that I get:

| #:rule (rule-name #:transform field-id (field-id
...+) (code ...+))

Am I not understanding something?


Separately, a comment on the HTML that is generated from Scribble:

It uses table-based layout and then adds CSS on top of that.  This seems odd.

The standard scribble.css file includes the following comment:

===quote
/* CSS seems backward: List all the classes for which we want a
   particular font, so that the font can be changed in one place.  (It
   would be nicer to reference a font definition from all the places
   that we want it.)

   As you read the rest of the file, remember to double-check here to
   see if any font is set. */
===/quote

It's perfectly legit to do it the other way around, and in fact that's
the more standard way.  Instead of putting this at the top of the
file:

/* Monospace: */
.maincolumn, .refpara, .refelem, .tocset, .stt, .hspace, .refparaleft,
.refelemleft {
  font-family: monospace;
}

It's fine to do this:

.maincolumn { font-family: monospace }
.refpara { font-family: monospace }


Also, it would be really spiffy if the generated HTML was
pretty-printed.  Having it minified seems unnecessary and
disadvantageous.

Are these things that people are open to changing and, if so, is there
a way I can help?

-- 
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] How do I get the username from a database handle?

[David Storrs]

Thanks, I'll check it out.

On Tue, Feb 26, 2019 at 5:18 PM Jon Zeppieri  wrote:
>
>
> On Tue, Feb 26, 2019 at 4:58 PM David Storrs  wrote:
>>
>> Given a database handle, I'd like to be able to ask it what user it's
>> connected as.  Is there a way to do this?
>>
>
> I don't see anything in the `db` library's API to get this, but your database 
> probably allows you to do it in SQL (at the cost of a DB round-trip, of 
> course). E.g., in Postgres: `SELECT current_user`.
>
> - 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] Cannot use case+else inside match+else

[Shu-Hung You]

And because it is nothing else but a usual binding, it's possible to
prefix-in or rename-in as in

(require (prefix-in r: racket/base))
(case 5 [r:else 'ok])

On Wed, Feb 27, 2019 at 7:32 AM Laurent  wrote:
>
> Good point. I wasn't sure that would work---it does.
>
> On Wed, Feb 27, 2019 at 1:28 PM Jens Axel Søgaard  
> wrote:
>>
>> I suppose you could (re)require it again.
>>
>> ons. 27. feb. 2019 kl. 14.19 skrev Laurent :
>>>
>>> Wait, that means that in an interactive session, if you ever happen to 
>>> redefine `else', you can't use `case' anymore?
>>>
>>> On Tue, Feb 26, 2019 at 5:03 AM Ben Greenman  
>>> wrote:

 Here's a suggestion for the docs:

 https://github.com/racket/racket/pull/2505

 --
 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.
>>
>> --
>> --
>> Jens Axel Søgaard
>>

-- 
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] tree-layout, many many thanks

[Laurent]

A long time ago I had a need for this too, so I just made one for me:
https://github.com/Metaxal/bazaar/blob/master/slideshow/slideshow-tree.rkt

The behaviour is a bit different from pict/tree-layout.
There's an example usage in the drracket submodule at the end of the file
that produces:
[image: Screenshot from 2019-02-27 13-39-22.png]






On Tue, Feb 26, 2019 at 11:41 PM 'John Clements' via Racket Users <
racket-users@googlegroups.com> wrote:

> I wanted to format binary search trees for a data structures exam. I spent
> literally hours trawling through old source code to see how I’d done it
> before… graphviz? tikzpicture? … before giving up and doing what I should
> have done in the first place, looking in the racket docs. Tree-layout does
> exactly what I want, renders to .pdf, and I’m done.
>
> My major mistake: looking elsewhere!
>
> John
>
> --
> 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.

Re: [racket-users] Cannot use case+else inside match+else

[Laurent]

Good point. I wasn't sure that would work---it does.

On Wed, Feb 27, 2019 at 1:28 PM Jens Axel Søgaard 
wrote:

> I suppose you could (re)require it again.
>
> ons. 27. feb. 2019 kl. 14.19 skrev Laurent :
>
>> Wait, that means that in an interactive session, if you ever happen to
>> redefine `else', you can't use `case' anymore?
>>
>> On Tue, Feb 26, 2019 at 5:03 AM Ben Greenman 
>> wrote:
>>
>>> Here's a suggestion for the docs:
>>>
>>> https://github.com/racket/racket/pull/2505
>>>
>>> --
>>> 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.
>>
> --
> --
> Jens Axel Søgaard
>
>

-- 
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] Cannot use case+else inside match+else

[Jens Axel Søgaard]

I suppose you could (re)require it again.

ons. 27. feb. 2019 kl. 14.19 skrev Laurent :

> Wait, that means that in an interactive session, if you ever happen to
> redefine `else', you can't use `case' anymore?
>
> On Tue, Feb 26, 2019 at 5:03 AM Ben Greenman 
> wrote:
>
>> Here's a suggestion for the docs:
>>
>> https://github.com/racket/racket/pull/2505
>>
>> --
>> 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.
>
-- 
-- 
Jens Axel Søgaard

-- 
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] Cannot use case+else inside match+else

[Laurent]

Wait, that means that in an interactive session, if you ever happen to
redefine `else', you can't use `case' anymore?

On Tue, Feb 26, 2019 at 5:03 AM Ben Greenman 
wrote:

> Here's a suggestion for the docs:
>
> https://github.com/racket/racket/pull/2505
>
> --
> 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.

Re: [racket-users] R6RS history

[Will Jukes]

This question has been burning me up as well.

On Tue, Feb 26, 2019 at 4:16 PM Matthias Felleisen 
wrote:

>
>
> Let me inject some comments that make it a bit more obvious what’s
> happening here:
>
>
> > On Feb 26, 2019, at 3:33 PM, Sam Tobin-Hochstadt 
> wrote:
> >
>
> RnRS meetings from 1984 thru 2003 adhere to the “unanimity rule”
> originating from the MIT group.
>
> In 2001, I created and ran “Scheme and Functional Programming” (SFP), a
> first annual Scheme workshop that also subsumed “Scheme Report” meetings.
>
>
> > 2003: New Scheme Standard proposed at the Scheme Workshop
>
> At the 2003 Boston SFP, I proposed going to a majority rule so that the
> Scheme standard could grow into a useful language after a long long day,
> with many people gone. The motion passed.
>
> > 2006: First draft of R6RS released
> > 2007: R6RS Ratified by community vote after extensive discussion and
> revision
>
> I wrote an essay entitled “The R6RS is Perfect”. The certification vote
> succeeded with just a few votes more than needed (60% or 66% or something
> like that).
>
>
> > 2009: A new Scheme Standard steering committee elected by a community
> > vote. The new committee reflected opposition to the R6RS.
>
> (as in “community vote” by another Scheme workshop)
>
>
> We, the Racketeers, didn’t want to be in their way so we wrote this:
>
>  https://racket-lang.org/new-name.html
>
> History is history. The future you can change, unless Gödel is right about
> Einstein’s equations and it’s practical.
>
> — 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.
>

-- 
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] Struct properties and recursion

[Ross Angle]

On Fri, Feb 22, 2019 at 2:35 PM Jack Firth  wrote:

> This feels tedious and unnecessary. Looking at the underlying API of
> make-struct-type, I can't see any way to avoid this mutual recursion.
>

There may be some situations where struct definitions make essential use of
fixed points, but the situation you're describing doesn't sound like one of
them.

When you do need fixed points, since `struct` is generative, the pure Z
combinator style of fixed point tends to come up short. If we have a
expression that needs to refer to its own results, usually that's easy as
long as the results are functions: We locally bind some *other* functions
which work by first running the expression again. Running a (struct ...)
expression again produces a different result, so this isn't so viable.

Instead, Racket's mutation-based fixed points with `define` and friends
come in handy here because they only have to run the expression once. Since
`struct` has the `define` functionality built in, that seems to be the
easiest way to go. You're seeing some use-before-definition errors that
result from this, but you'd get that kind of error with the Z combinator
style too; it would just show up as an infinite loop instead.

It sounds like you'd like to avoid fixed points altogether in this case. I
think you actually can refactor your example to do that.

Instead of defining your `make-list-type-writer` abstraction as a function,
you can define it as a structure type property. (I think
`prop:auto-custom-write` may be an example of this technique.).This
property would make use of multiple features of
`make-struct-type-property`: It would first obtain a list of reflective
information about the struct type (since that's one of the parameters
passed to its guard procedure), and then it would use one of its supers
entries to populate `prop:custom-write` based on that information. One part
of the reflective information is an accessor procedure, so the generated
`prop:custom-write` procedure can call that instead of having to refer to
`point-x` and `point-y`.

I find it a little surprising how well this technique corresponds to the
needs of a program that's avoiding fixed points. The bundle of reflective
information only contains certain information `struct` defines, namely the
accessor and mutator procedures. If it contained the structure type
descriptor or the constructor, then it would be possible to attempt to
access a property value *before* it was done being computed, essentially
letting us run into the very kind of use-before-definition error that we'd
get if we were using fixed points.

By the way, I've noticed the documentation says `prop:custom-write` is
deprecated and to use `gen:custom-write` instead. If you do that, I think
you do have to go back to using fixed points again. The technique I
described doesn't help with generic interfaces, just structure type
properties.

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