[racket-users] TR typed-racket-more library docs

2015-06-26 Thread Jordan Johnson
Hi all,

One thing I’ve noticed in working with Typed Racket is that some of the 
libraries on the “Libraries Provided with Typed Racket 
http://docs.racket-lang.org/ts-reference/Libraries_Provided_With_Typed_Racket.html”
 docs page have type definitions that aren’t documented anywhere, but that 
ought to be visible to TR programmers. Sometimes, I look at that docs page and 
think, “Gee, I’d be happy to spend a little time writing docs for those types, 
if I knew where to do it.”

So, is there any planned idea of where the documentation for the TR-specific 
parts of all those wrapper libraries currently in the typed-racket-more package 
ought best to wind up? AFAICT there are at least three possibilities:

The wrappers eventually migrate to the libraries they wrap, and the docs then 
have an obvious home there.
The wrappers stay where they are, and documentation for a wrapper lib goes 
beneath its (require …) rectangle on the TR libs page linked above.
The wrapper libs get separate HTML files in the TR reference.

I don’t have a preference, but would gladly do some writing if the main TR devs 
suggest where.

Regards,
Jordan

-- 
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 typed-racket-more library docs

2015-06-26 Thread Sam Tobin-Hochstadt
Thanks for volunteering! I think 2 is the correct approach here.

Sam

On Fri, Jun 26, 2015 at 8:58 PM, Jordan Johnson j...@fellowhuman.com wrote:
 Hi all,

 One thing I’ve noticed in working with Typed Racket is that some of the
 libraries on the “Libraries Provided with Typed Racket” docs page have type
 definitions that aren’t documented anywhere, but that ought to be visible to
 TR programmers. Sometimes, I look at that docs page and think, “Gee, I’d be
 happy to spend a little time writing docs for those types, if I knew where
 to do it.”

 So, is there any planned idea of where the documentation for the TR-specific
 parts of all those wrapper libraries currently in the typed-racket-more
 package ought best to wind up? AFAICT there are at least three
 possibilities:

 The wrappers eventually migrate to the libraries they wrap, and the docs
 then have an obvious home there.
 The wrappers stay where they are, and documentation for a wrapper lib goes
 beneath its (require …) rectangle on the TR libs page linked above.
 The wrapper libs get separate HTML files in the TR reference.


 I don’t have a preference, but would gladly do some writing if the main TR
 devs suggest where.

 Regards,
 Jordan

 --
 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] Moving an image with the keyboard

2015-06-26 Thread Jordan Johnson
Hi Patrick,

The problem you’re up against is that in the code you’ve attached, we don’t 
have a clear picture of what the signatures for your functions are, nor of the 
“world” upon which big-bang operates. Standard practice in HtDP-based courses 
dictates that
every big-bang program should have a data definition for the world in comments, 
and
every function should have a signature and brief description of its purpose in 
comments (as well as one or more examples/tests to illustrate its use).

Because you write (big-bang (ufo 70 60) ...), you clearly intend for your 
“world” to be a ufo struct. So in order for your readers to not have to guess 
at what you mean, you need a comment to accompany your struct definition:

;; A World is a (ufo Number Number):
(struct ufo (xpos ypos))
;; where xpos is ...
;;   and ypos is ...

And say what xpos and ypos represent. Thereafter, when you write function 
signatures, you can use World to describe the kind of data that’s passing in or 
out, e.g.,

;; SIGNATURE: render-ufo : World - Image
;; PURPOSE: draws the UFO at the given location

If you look at the Help Desk docs for 2htdp/universe, one fine thing it gives 
you in the description of big-bang is the signature required for every one of 
the handler functions. For example: big-bang’s first parameter must be a World, 
and in
 [to-draw f]
the signature of f must be
 ;; f : World - Image

Once you’ve worked out what the signatures should be for all of your handler 
functions, take a look at your code and start writing signatures for the 
functions you’ve written. This will lead you to figure out what’s going wrong.

Cheers,
jmj

On Jun 26, 2015, at 4:42 PM, Patrick Ester patrick.es...@gmail.com wrote:
 
 Dear All,
 
 I am not sure if this is the right place since I am working from the Realm of 
 Racket book. If not, please let me know where I can take my question. I 
 finished up chapter five, and wanted to modify the UFO example to move in 
 relation to the arrow keys. Here is the code that I wrote:
 
 #lang racket
 (require 2htdp/universe 2htdp/image)
 
 (define WIDTH 600)
 (define HEIGHT 600)
 ;;The image won't copy and paste, but you get the idea.
 (define IMAGE-of-ufo .)
 
 (struct ufo (xpos ypos))
 
 (define (move-up w)
  (add1 (ufo-xpos w)))
 
 (define (move-down w)
  (sub1 (ufo-xpos w)))
 
 (define (move-right w)
  (add1 (ufo-ypos w)))
 
 (define (move-left w)
  (sub1 (ufo-ypos w)))
 
 (define (render-ufo w)
  (place-image
   (scale 0.25 IMAGE-of-ufo) (ufo-xpos w) (ufo-ypos w)
   (empty-scene WIDTH HEIGHT)))
 
 (define (move-UFO w key)
  (cond [(key=? key up) (move-up w)]
[(key=? key down) (move-down w)]
[(key=? key left) (move-left w)]
[(key=? key right) (move-right w)]
[else w]))
 
 (big-bang (ufo 70 60)
  (on-key move-UFO)
  (to-draw render-ufo))
 
 When I click the Run button, the output initially looks good. However, when I 
 press an arrow key, I get an error. Attached is a screenshot with what I see 
 in the definitions pane.
 
 The error message in the interactions pane is:
 
 ufo-xpos: contract violation
  expected: ufo?
  given: 61
 
 I do not get why the contract is broken. The function place-image takes an 
 image, number, number, and a scene. What mistake am I making? Thanks in 
 advance.
 
 Patrick
 
 -- 
 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.
 Screen Shot 2015-06-26 at 6.26.21 PM.png

-- 
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] Moving an image with the keyboard

2015-06-26 Thread Patrick Ester
Dear All,

I am not sure if this is the right place since I am working from the Realm of 
Racket book. If not, please let me know where I can take my question. I 
finished up chapter five, and wanted to modify the UFO example to move in 
relation to the arrow keys. Here is the code that I wrote:

#lang racket
(require 2htdp/universe 2htdp/image)
 
(define WIDTH 600)
(define HEIGHT 600)
;;The image won't copy and paste, but you get the idea.
(define IMAGE-of-ufo .)
 
(struct ufo (xpos ypos))
 
(define (move-up w)
  (add1 (ufo-xpos w)))
 
(define (move-down w)
  (sub1 (ufo-xpos w)))
 
(define (move-right w)
  (add1 (ufo-ypos w)))
 
(define (move-left w)
  (sub1 (ufo-ypos w)))
 
(define (render-ufo w)
  (place-image
   (scale 0.25 IMAGE-of-ufo) (ufo-xpos w) (ufo-ypos w)
   (empty-scene WIDTH HEIGHT)))
 
(define (move-UFO w key)
  (cond [(key=? key up) (move-up w)]
[(key=? key down) (move-down w)]
[(key=? key left) (move-left w)]
[(key=? key right) (move-right w)]
[else w]))
 
(big-bang (ufo 70 60)
  (on-key move-UFO)
  (to-draw render-ufo))

When I click the Run button, the output initially looks good. However, when I 
press an arrow key, I get an error. Attached is a screenshot with what I see in 
the definitions pane.

The error message in the interactions pane is:

ufo-xpos: contract violation
  expected: ufo?
  given: 61

I do not get why the contract is broken. The function place-image takes an 
image, number, number, and a scene. What mistake am I making? Thanks in advance.

Patrick

-- 
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] #true, #false, '()

2015-06-26 Thread Matthias Felleisen


Dear educators and users of our teaching languages,

Dave Tompkins from Waterloo brought to our attention that I failed to
properly warn about a change to the teaching languages of HtDP.  

Since the change may affect your teaching materials, we want

-- to alert you now in case you need to adjust things for the fall
   semester/new school year

-- to request your input on how to help you with this transition. 

The rest of the message first explains the CHANGE and its IMPACT on
PROGRAMMING, PRINTING VALUES, and STEPPING through programs. It then 
explains the RATIONALE, and finally gets back to the TRANSITION. 

-
THE CHANGE --- Over release 6.1.1 (last fall) and 6.2 (just now), HtDP/2e
and *SL gradually introduced

  '() for empty lists
  #true for truth
  #false for falsity

The idea was to inject this change into DRAFTS unlikely to be used by
instructors and to warn them of these changes and let them inspect the
materials and software. 

-
IMPACT on PROGRAMMING --- All of your programs will continue to run because
the teaching languages still come with the pre-defined identifiers

  empty for empty list
  true for truth
  false for falsity

-
IMPACT on PRINTING THE VALUES OF PROGRAMS --- While programs continue to
run as is, some of their resulting values will be rendered differently. 

 Examples:

 in BSL
  (remove 1 '(1))
 '()
 instead of empty

 in ISL
  (andmap odd? '(1 2 3))
 #false
 instead of false

We firmly believe that students will comprehend the results anyway. 

-
IMPACT on STEPPER --- Due to my negligence, the stepper is currently in an
 partly inconsistent state with respect to this problem. 

It is built so as to cope with such changes automatically, which means that
 it picks some default renderings for truth, falsity, and emptiness. We
 consider this problem a bug. 

-
RATIONALE --- If your book/courses focuses on design and ignores all
connections to Racket, the idea of using identifier-like literal constants
for these three entities is acceptable. 

Neither HtDP/2e nor HtDP/1e do so. Both try to expose readers to some of
ideas found in Racket (Scheme), and how they make programming much more
convenient. One of these ideas -- still not found in ML, Haskell, Java, or
similar languages -- is quoting and unquoting.

Since un/quoting is in the teaching languages, identifier-like literal
constants are a philosophical mistake. Our change fixes this old mistake.

-
TRANSITION --- We recognize that your time is valuable and you may not be
able to edit your materials in time for the next school year, though we
sincerely hope that you eventually will. 

First, we intend to release another (minor) upgrade of Racket to fix some
of the problems with the stepper. Second, if teachers are interested, we
will investigate the possibility of making the old HtDP printer for values
available via a language preference. Students would have to choose this
option explicitly but we are confident that they can do so. 

If there is anything else you think we could do to smoothen this transition,
please feel free to propose specifics. 

-- 
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] Fast way to map over a list many times, changing ONE element each time?

2015-06-26 Thread Alexander D. Knauth
Is there a split-at-reverse anywhere, equivalent to split-at except that the 
first return value is reversed?
If not, should that be added somewhere like srfi/1?

I’m asking because wanted to be able to write functions like:

(define ((drop-lens n) lst)
  (define-values [fst-lst rst-lst] (split-at-reverse lst n))
  (values rst-lst (λ (x) (append-reverse fst-lst x

(define ((list-ref-lens i) lst)
  (match-define-values [fst-lst val:rst-lst] (split-at-reverse lst i))
  (match-define (cons val rst-lst) val:rst-lst)
  (values val (λ (x) (append-reverse fst-lst (cons x rst-lst)

These are lenses as used in this package:
https://github.com/jackfirth/lenses

I wrote my own version of split-at-reverse, but I’m wondering if it should be 
put in something like srfi/1 as a companion to append-reverse, or if it perhaps 
already is in some other library.

Alex Knauth

On Jun 19, 2015, at 4:28 PM, Jens Axel Søgaard jensa...@soegaard.net wrote:

 A more efficient version using append-reverse from srfi/1.
 
 #lang racket
 (require (only-in srfi/1 append-reverse))
 
 (define (list-splits xs)
   (define (loop ys zs)  ; xs = (append (reverse ys) yz)
 (match zs
   ['()  '()]
   [(cons z zs*) (cons (list ys zs)
   (loop (cons z ys) zs*))]))
   (loop '() xs))
 
 
 (define (map-once f xs)
   (for/list ([ys+zs (list-splits xs)])
 (match ys+zs
   [(list ys '()) '()]
   [(list ys (cons z zs)) (append-reverse ys (cons (f z) zs))])))
 
 (list-splits  '(1 2 3))
 (map-once sqr '(1 2 3))
 
 
 2015-06-19 22:07 GMT+02:00 Jens Axel Søgaard jensa...@soegaard.net:
 #lang racket
 (define (list-splits xs)
   (define (loop ys zs)  ; xs = (append (reverse ys) yz)
 (match zs
   ['()  '()]
   [(cons z zs*) (cons (list ys zs)
   (loop (cons z ys) zs*))]))
   (loop '() xs))
 
 
 (define (map-once f xs)
   (for/list ([ys+zs (list-splits xs)])
 (match ys+zs
   [(list ys '()) '()]
   [(list ys (cons z zs)) (append (reverse ys) (cons (f z) zs))])))
 
 (list-splits  '(1 2 3))
 (map-once sqr '(1 2 3))
 
 
 2015-06-19 22:05 GMT+02:00 Jon Zeppieri zeppi...@gmail.com:
 It's unlikely that an implementation using continuations would be
 faster than one that does not.
 
 An idiomatic solution might look like:
 
 (define (map-once fn xs)
   (for/list ([i (in-range (length xs))])
 (for/list ([(x j) (in-indexed (in-list xs))])
   (cond [(= i j) (fn x)]
 [else x]
 
 
 But it's not terribly fast.
 If you're willing to use vectors instead of lists, then maybe:
 
 (define (map-once fn xs)
   (build-vector (vector-length xs)
 (λ (i)
   (define v (vector-copy xs))
   (vector-set! v i (fn (vector-ref v i)))
   v)))
 
 
 On Fri, Jun 19, 2015 at 3:24 PM, Luke Miles rashreportl...@gmail.com wrote:
  Say I have a list ls and I want to produce a list of
  lists where the i'th list has the i'th element of ls tripled,
  but all other elements are the same.
 
  e.g. '(3 5 7) = '((9 5 7) (3 15 7) (3 5 21))
 
  What is a fast way to do this?
 
 
  I could do a loop with appending.
  (define (map-once f ls)
(let M ([sooner null] [later ls])
  (if (null? later) null
(cons (append sooner (list (f (car later))) (cdr later))
  (M (append sooner (list (car later))) (cdr later))
 
  - (map-once sqr '(4 5 6))
  '((16 5 6) (4 25 6) (4 5 36))
 
  Unfortunately, this is very slow  messy.
  I have to do 2 big appends for every element is the return list.
 
 
  Here is a cleaner-looking, but still slow way:
  (define (list-set ls i new-val)
(let-values ([(sooner later) (split-at ls i)])
  (append sooner (list new-val) (cdr later
 
  (define (map-once f ls)
(for/list ([i (in-naturals)]
   [elm (in-list ls)])
  (list-set ls i (f elm
 
 
  I'm thinking a good implementation might use continuations somehow?
 
  Maybe of vector-set (without the exclamation point) existed, I could use it?
 
  --
  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
 
 
 
 
 -- 
 -- 
 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