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 dank...@ccs.neu.edu 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


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',
 #void, and #undefined, but I'm not really happy about that (and
 I keep thinking about ways to get rid of #undefined).

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 #undefined?  (Asking because it
might apply here too.)

(Is there any problem with #void?)

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


[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