Re: [racket-dev] Overly general types for mutable containers

2012-07-08 Thread Neil Toronto

On 07/07/2012 10:28 PM, Sam Tobin-Hochstadt wrote:

On Sun, Jul 8, 2012 at 12:58 AM, Neil Toronto  wrote:

It runs directly counter to what I expect from immutable containers, which I
use most of the time:


This is the problem.  Immutable containers are very different from
mutable ones, and your expectations shouldn't be expected to carry
over.  Mutability is a communications channel, not just a data storage
mechanism, and you should expect it to be different.


Yes, I'm seeing that now. A lot. :D

(I apologize for my recent negative tone. I've made up for it by 
submitting bug reports for you. Or something.)


I keep trying to come up with better rules for generalizing the 
containee types in mutable containers. I haven't found any that don't 
have problems, so I'll have to be content with your choices on this.


Neil ⊥
_
 Racket Developers list:
 http://lists.racket-lang.org/dev


Re: [racket-dev] redex.racket-lang.org Index of /

2012-07-08 Thread Robby Findler
Eli: while you're at this, can you improve the watchdog script so that
it would notice this?

Robby

On Sun, Jul 8, 2012 at 12:35 PM, David Van Horn  wrote:
> redex.racket-lang.org seems to have reverted to serving the index of /.
>
> David
> _
>  Racket Developers list:
>  http://lists.racket-lang.org/dev
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


[racket-dev] redex.racket-lang.org Index of /

2012-07-08 Thread David Van Horn

redex.racket-lang.org seems to have reverted to serving the index of /.

David
_
 Racket Developers list:
 http://lists.racket-lang.org/dev


Re: [racket-dev] Custom write that pretty-prints and works well with quote?

2012-07-08 Thread Matthew Flatt
Do `prop:custom-print-quotable' and/or
`make-tentative-pretty-print-output-port' from `racket/pretty' help?

At Sat, 07 Jul 2012 11:40:49 -0700, Neil Toronto wrote:
> I've got an array structure like so:
> 
> (struct: (A) strict-array ([shape : (Listof Index)]
> [data : (Vectorof A)])
> 
> Say I have this value:
> 
>  (strict-array '(2 2) #(1 2 3 4))
> 
> I want it to print like this at the REPL:
> 
>  #
> 
> If there's not enough room, I want this:
> 
>  #'(2 2)
>'((1 2) (3 4))>
> 
> If it happens to be in a list, I want this:
> 
>  (list #)
> 
> and definitely NOT '(#) because the 
> inner quotes are confusing.
> 
> How do I do that with prop:custom-write? The only way I've found so far 
> to get nicely formatted output is to write/display/print a list, but 
> then the quotes get messed up. I haven't found a way to keep the REPL 
> from quoting lists of structs, except to go with the default printer, 
> which flattens arrays, which makes them hard to read.
> 
> This is frustrating.
> 
> Neil ⊥
> _
>   Racket Developers list:
>   http://lists.racket-lang.org/dev

_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] Proposal for a "no-argument"

2012-07-08 Thread Eli Barzilay
Quick summary: I'll remove the #:before-first and #:after-last
feature.  If anyone wants them, please tell me -- maybe it can be left
for the spliced case, or maybe they could always be spliced.


On Monday, Matthew Flatt wrote:
> I'm not enthusiastic about this proposal.
> 
> As you say at the start, it seems like a rare case. My main
> objection is that it's too rare to merit a change to the main
> `lambda' form and other parts of our infrastructure, such as
> documentation tools.

This -- a more substantial extension of `lambda' and friends -- seems
to be the core issue here.  I've talked about it to Matthias, and we
agreed on something that would help.  I'll post about it separately,
when I land.


> As a weaker objection, I don't agree with the suggestion that naive
> users can somehow ignore the `no-argument' value. I think it would show
> up prominently in documentation, contracts, and types.

I didn't mean that they'll ignore it -- I meant that having a default
expression that is rendered as "no-argument" or something similar is
self explanatory in a better way than "", and definitely from an
additional #:nothing argument (which is an actual interface change in
addition to being obscure).


> Weaker still, in terms of how well I can defend it: I'm suspicious
> of "no-value" values in general. Granted, we already have `#f',
> #, and #, but I'm not really happy about that (and
> I keep thinking about ways to get rid of #).

This could be solved, roughly, by what both Robby and Matthias
suggested (protecting it from leaking out), but on one hand there's a
problem with that, and on the other it makes it equivalent to exposing
a boolean flag for the presence of an argument.  That's the thing that
I'll delay for a proper post on that.  Side-question: do you have some
potential direction for eliminating #?  (Asking because it
might apply here too.)

(Is there any problem with #?)

Meanwhile, the interface change, the gensym-encouraging, and the
obscurer explanation really bother me, so I'll just get rid of the
need for them by removing the #:before-first and #:after-last feature.

-- 
  ((lambda (x) (x x)) (lambda (x) (x x)))  Eli Barzilay:
http://barzilay.org/   Maze is Life!
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] Need a clarification on the implementation of stream-map

2012-07-08 Thread Robby Findler
I'm not sure about the rationale behind the design of stream-map, but
"any" as a result contract for a function indicates it may return
multiple values (in the range of a function "any" is a special
keyword). "any/c" is a contract for a single value.

Robby

On Sun, Jul 8, 2012 at 6:25 AM, Daniel King  wrote:
> Question 0:
>
> In collects/racket/stream.rkt, `stream-map' is defined as:
>
>   (define (stream-map f s)
> (unless (procedure? f) (raise-argument-error 'stream-map "procedure?" f))
> (unless (stream? s) (raise-argument-error 'stream-map "stream?" s))
> (let loop ([s s])
>   (cond
>[(stream-empty? s) empty-stream]
>[else (stream-cons (call-with-values (lambda () (stream-first s)) f)
>   (loop (stream-rest s)))])))
>
>
> I don't understand the difference between:
>
>   (call-with-values (lambda () (stream-first s)) f)
>
> and
>
>   (f (stream-first s))
>
> because the contract for `stream-first' is:
>
>   (stream-first s) → any
>   s : (and/c stream? (not/c stream-empty?))
>
> Which seems to me to just return a single value. I was taking a second look at
> my changes to `stream-map' which add support for multiple streams. I noticed
> this unusual snippet as I rebased onto the latest version of plt/master.
>
>
> Question 1:
>
> Would it make more sense to simply update all the sequence procedures to 
> handle
> multiple sequences? Is there a circumstance where it doesn't make sense to
> handle multiple sequences in a sequence procedure such as `sequence-map'?
>
> I figure that the sequence procedures don't support multiple sequences is just
> lack of interest. Do most people just use the `for' macros in these cases?
>
> --
> Dan King
> College of Computer and Information Science
> Northeastern University
>
> _
>   Racket Developers list:
>   http://lists.racket-lang.org/dev

_
  Racket Developers list:
  http://lists.racket-lang.org/dev


[racket-dev] Need a clarification on the implementation of stream-map

2012-07-08 Thread Daniel King
Question 0:

In collects/racket/stream.rkt, `stream-map' is defined as:

  (define (stream-map f s)
(unless (procedure? f) (raise-argument-error 'stream-map "procedure?" f))
(unless (stream? s) (raise-argument-error 'stream-map "stream?" s))
(let loop ([s s])
  (cond
   [(stream-empty? s) empty-stream]
   [else (stream-cons (call-with-values (lambda () (stream-first s)) f)
  (loop (stream-rest s)))])))


I don't understand the difference between:

  (call-with-values (lambda () (stream-first s)) f)

and

  (f (stream-first s))

because the contract for `stream-first' is:

  (stream-first s) → any
  s : (and/c stream? (not/c stream-empty?))

Which seems to me to just return a single value. I was taking a second look at
my changes to `stream-map' which add support for multiple streams. I noticed
this unusual snippet as I rebased onto the latest version of plt/master.


Question 1:

Would it make more sense to simply update all the sequence procedures to handle
multiple sequences? Is there a circumstance where it doesn't make sense to
handle multiple sequences in a sequence procedure such as `sequence-map'?

I figure that the sequence procedures don't support multiple sequences is just
lack of interest. Do most people just use the `for' macros in these cases?

--
Dan King
College of Computer and Information Science
Northeastern University

_
  Racket Developers list:
  http://lists.racket-lang.org/dev