About two weeks ago, Asumu Takikawa wrote:
Late reply, but better than never.
On 2013-03-10 16:20:14 -0400, Eli Barzilay wrote:
Assuming this, here's a suggestion that I made in the past for
resolving this:
* Make the existing `take', `drop', `split-at' accept their arguments
in
Is there a real need to make this whole thing a public interface? I'd
think that a general direction is to move away from making it public
(ie, remove the ability to create an arity value), and this seems to
add a pretty big chunk of stuff in the opposite direction.
About two weeks ago,
If we want people to be able to create higher-order functions with precise
arities via procedure-reduce-arity, for instance, we need to provide tools
for manipulating arity values. Manipulating them is also useful for
producing error messages that describe the arity of procedure values. I
don't
OK, that's a valid use case -- but isn't it better for both of these
uses to just use some combinator for arities that generates a properly
normalized arity instead of constructing lists and explicitly
normalizing them?
It's just that the interface looks very complex now. Some obvious
things:
*
If you're writing a higher-order tool like curry or negate, and want to
produce a meaningful arity for its result, you're going to need some
explicit representation of arity to manipulate, e.g. subtract one from
every number in the list after partially applying to a single argument.
Once users are
A few minutes ago, Carl Eastlund wrote:
If you're writing a higher-order tool like curry or negate, and want to
produce a meaningful arity for its result, you're going to need some explicit
representation of arity to manipulate, e.g. subtract one from every number in
the list after partially
Revised suggestion which I think can address both reducing the number
of functions and the argument order:
Remove the `*f' functions from the interface, and change the
non-`*f' functions to accept keywords as follows:
(take #:num N L)
(take #:while P L)
(take #:until P L)
On 2013-04-11 12:05:59 -0400, Eli Barzilay wrote:
Remove the `*f' functions from the interface, and change the
non-`*f' functions to accept keywords as follows:
(take #:num N L)
(take #:while P L)
(take #:until P L)
I like this suggestion since keywords seem like a
An hour ago, Asumu Takikawa wrote:
On 2013-04-11 12:05:59 -0400, Eli Barzilay wrote:
Remove the `*f' functions from the interface, and change the
non-`*f' functions to accept keywords as follows:
(take #:num N L)
(take #:while P L)
(take #:until P L)
I like
At Thu, 11 Apr 2013 15:20:54 -0400, Eli Barzilay wrote:
In any case, given that nobody seems sufficiently interested, maybe
it's best to remove the new functions for this release to avoid code
depending on it which will make later changes more difficult?
I don't think we're going to have any
I know the code below is wrong because it sends TR into an infinite
loop. What is the recommended way to represent mynull (and its type)
without leaking its representation to a user of this library?
#lang typed/racket
(define mynull null)
(define-type MyListof (All (A) (Rec X (U mynull (Pair A
Perhaps something like this?
;
#lang typed/racket/base
(provide mynull mycar mycdr)
(struct: MyNull ())
(define mynull (MyNull))
(define-type MyListof (All (A) (Rec X (U MyNull (Pair A X)
(: mycar : (All (A) ((MyListof A) - A)))
(define (mycar lst)
(if (MyNull? lst)
You shouldn't be able to send the TR into an inifinite loop.
Typechecking is supposed to terminate. Please try to reduce it to the
minimum testcase and file a bug.
On Thu, Apr 11, 2013 at 3:32 PM, Danny Yoo d...@hashcollision.org wrote:
Perhaps something like this?
;
#lang
On Thu, Apr 11, 2013 at 6:47 PM, Eric Dobson eric.n.dob...@gmail.com wrote:
You shouldn't be able to send the TR into an inifinite loop.
Typechecking is supposed to terminate. Please try to reduce it to the
minimum testcase and file a bug.
I just filed pr 13687.
On Thu, Apr 11, 2013 at
14 matches
Mail list logo
