On Tue, Sep 18, 2012 at 12:59 PM, John Clements
wrote:
>
> On Sep 18, 2012, at 5:28 AM, Matthew Flatt wrote:
>
>> Meanwhile, it might be interesting to try implementing a `generator'
>> form that rewrites its body to implement `yield's that are
>> syntactically apparent (after local-expansion), le
A few minutes ago, Jon Zeppieri wrote:
> (I assume the nightly builds on racket-lang.org are from the
> stable branch?)
No -- the stable branch corresponds to the released versions, so it's
a convenient way to get to the "most recently released" point.
--
((lambda (x) (x x)) (lambda (x
On Tue, Sep 18, 2012 at 5:29 PM, Danny Yoo wrote:
>
> >
> > I'd like to see a discussion of the tradeoffs between cond & case & match
> > and how each is best used.
1. Use 'cond' where you would use 'if...else if...else' in a C-like
language. It's just a multi-way if:
(cond [(string? value)
10 minutes ago, Matthew Flatt wrote:
> At Tue, 18 Sep 2012 20:46:40 -0400, Eli Barzilay wrote:
> > A few minutes ago, Matthew Flatt wrote:
> > >
> > > Using `call/cc' for generators is effectively a hint to the run-time
> > > system that the continuation doesn't need to compose. That hint is
> > >
At Tue, 18 Sep 2012 20:46:40 -0400, Eli Barzilay wrote:
> A few minutes ago, Matthew Flatt wrote:
> >
> > Using `call/cc' for generators is effectively a hint to the run-time
> > system that the continuation doesn't need to compose. That hint is
> > useful only because of the way that continuation
I have done some work in this area, and my patches are currently
sitting on github waiting for comments. (And also some cleanup by me).
I believe that the current version in my pull request will give a
static error here.
https://github.com/plt/racket/pull/139
On Tue, Sep 18, 2012 at 5:38 PM, Mat
A few minutes ago, Matthew Flatt wrote:
>
> Using `call/cc' for generators is effectively a hint to the run-time
> system that the continuation doesn't need to compose. That hint is
> useful only because of the way that continuations are implemented
> internally.
So `call/cc' is faster than one o
At Tue, 18 Sep 2012 19:20:29 +0200, Sam Tobin-Hochstadt wrote:
> continuations are *not* used to
> implement `thread` and associated facilities in Racket
Although Racket threads are not implemented with continuations in the
sense of `continuation?', both threads and continuations use the same
inte
+1
A flavor of this problem has come up repeatedly, and it will come up again. We
need some fix.
On Sep 18, 2012, at 6:28 PM, Ryan Culpepper wrote:
> Typed Racket should raise an error saying something like "(Setof Any) cannot
> be translated to a contract". Then elaborate in the docs w
Typed Racket should raise an error saying something like "(Setof Any)
cannot be translated to a contract". Then elaborate in the docs where
you discuss interaction with untyped code about what types cannot be
converted to contracts and maybe why.
Ryan
On 09/18/2012 06:00 PM, Sam Tobin-Hochst
Can you explain more? Surely TR must know what "Setof" is, because it
translated it to "set/c" and surely it must know what "Any" is, since
it turned it into some other contract. That seems like enough
information to me.
Robby
On Tue, Sep 18, 2012 at 5:00 PM, Sam Tobin-Hochstadt wrote:
> I'm say
I'm saying that I don't at the moment know how to avoid giving this
error, given the current behavior of `set/c`.
On Tue, Sep 18, 2012 at 5:57 PM, Robby Findler
wrote:
> Are you saying it is reasonable that a typed racket program should
> produce contract constructor errors like that?
>
> Robby
>
Are you saying it is reasonable that a typed racket program should
produce contract constructor errors like that?
Robby
On Tue, Sep 18, 2012 at 4:53 PM, Sam Tobin-Hochstadt wrote:
> The problem here is that `Any` is a special contract which isn't a
> "chaperone contract", and `set/c` requires ch
The problem here is that `Any` is a special contract which isn't a
"chaperone contract", and `set/c` requires chaperone contracts.
It's not obvious to me if this can be detected statically, but you can
work around this by changing `Any` to some other type.
Sam
On Tue, Sep 18, 2012 at 5:44 PM, To
Hi all,
What could I be doing wrong here?
#lang typed/racket
(provide (struct-out foo))
(struct: foo ([bar : (Setof Any)]))
Racket 5.3.0.24 complains about it ("racket problem.rkt"):
set/c: contract violation
expected: chaperone-contract?
given: #
context...:
>
> I'd like to see a discussion of the tradeoffs between cond & case & match
> and how each is best used.
Hi Joe,
I treat 'cond' as the general, all-purpose conditional branching
thing, and it's my primary tool. I use the other two if the
conditions I'm testing against fit their shapes. If I'
> Yes, but you can't infer the _definitions_ of types. So what I meant was,
> you must define your types before writing programs. In Racket, you can just
> think about a class of data (e.g. "all the numbers and strings") and write a
not sure this is a black and white situation; seems like haskel
On 9/18/12 4:59 PM, Raoul Duke wrote:
No, by "types first" I think John and Vincent are talking about a conceptual
order. I would phrase it a little more subtly: an ML (or Haskell)
programmer writes their types, then their programs (as you must); a TR
programmer thinks about their data, writes d
> No, by "types first" I think John and Vincent are talking about a conceptual
> order. I would phrase it a little more subtly: an ML (or Haskell)
> programmer writes their types, then their programs (as you must); a TR
> programmer thinks about their data, writes down a program, then writes down
On 9/18/12 4:08 PM, thorso...@lavabit.com wrote:
It's also possible to write Typed Racket programs "types first", like
one would in Haskell, and I sometimes do. The "sums-of-products"
programming style of Haskell and ML can be expressed easily with Typed
Racket's structs and union types. You can
At Tue, 18 Sep 2012 16:08:29 -0400 (EDT),
thorso...@lavabit.com wrote:
>
> > It's also possible to write Typed Racket programs "types first", like
> > one would in Haskell, and I sometimes do. The "sums-of-products"
> > programming style of Haskell and ML can be expressed easily with Typed
> > Rac
Haskell is a mature, 20-year old compiler.
Typed Racket is an evolving, 3-year old language for which we have only
recently turned to performance issues. Also it runs atop a jit compiler that
does not know anything about types. We need to develop new and different ways
to perform optimization
http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=racket&lang2=ghc
?
Racket Users list:
http://lists.racket-lang.org/users
I forgot to ask about performance.
I know that all benchmarks lie, but which one is faster: Haskell or Typed
Racket?
Racket Users list:
http://lists.racket-lang.org/users
Thanks for the question, Kieron. It got me to look up case and think a
little about its usage.
I'd like to see a discussion of the tradeoffs between cond & case & match
and how each is best used.
Thanks,
-joe
On Tue, Sep 18, 2012 at 7:07 AM, Kieron Hardy wrote:
> Thanks for the info guys, now
> It's also possible to write Typed Racket programs "types first", like
> one would in Haskell, and I sometimes do. The "sums-of-products"
> programming style of Haskell and ML can be expressed easily with Typed
> Racket's structs and union types. You can also mix and match between
> "Haskell" and
p.s. Actually the closest to the simple producer function is this
buffer generator:
;; TO-DO: macro-ize
(define buffer-generator
(let* ([xs '()]
[ready? #f]
[yield (lambda (x) (set! xs (cons x xs)))])
(lambda ()
(unless ready?
;; --> User code here
(fo
At Tue, 18 Sep 2012 09:55:36 -0700,
John Clements wrote:
> On Sep 18, 2012, at 8:30 AM, thorso...@lavabit.com wrote:
>
> > Hi,
> >
> > I'm a beginner, but I have some experience with Scheme and Haskell.
> >
> > Haskell is famous for its strict type system. Is it possible to achieve
> > this in a
On Tue, Sep 18, 2012 at 6:52 PM, Greg Hendershott
wrote:
>> I agree with others that the cost of capturing continuations is the
>> culprit in this case. The run-time system has support for faster
>> continuations that work in constrained settings (currently used to
>> implement futures), and it mi
On Sep 18, 2012, at 5:28 AM, Matthew Flatt wrote:
> I don't think the parameter overhead is relevant. In Jay's post, he
> performs 100k parameter accesses, and it takes 16 milliseconds; we can
> reasonably extrapolate 160 msec for 1M accesses. Patrick's generator
> example yields 1M times, and ta
On Sep 18, 2012, at 8:30 AM, thorso...@lavabit.com wrote:
> Hi,
>
> I'm a beginner, but I have some experience with Scheme and Haskell.
>
> Haskell is famous for its strict type system. Is it possible to achieve
> this in a Lisp-like language? Is Typed Racket as strict as Haskell?
>
> I'd like
> I agree with others that the cost of capturing continuations is the
> culprit in this case. The run-time system has support for faster
> continuations that work in constrained settings (currently used to
> implement futures), and it might be possible to make those
> continuations kick in work for
I'm on 5.3.0.21 - haven't updated from the nightly build in a couple weeks.
I'll grab a new version from the nightly builds soon and check again then.
Cheers,
Kieron.
On Tue, Sep 18, 2012 at 10:30 AM, Robby Findler wrote:
> It is only in the pre-release. Possibly you're using 5.3?
>
> Robby
>
It is only in the pre-release. Possibly you're using 5.3?
Robby
On Tue, Sep 18, 2012 at 11:08 AM, Kieron Hardy wrote:
> I'm not seeing this at all on Windows - how do I enable?
>
> Kieron.
>
>
> On Mon, Sep 17, 2012 at 1:44 PM, Robby Findler
> wrote:
>>
>> It will appear when the online check s
I'm not seeing this at all on Windows - how do I enable?
Kieron.
On Mon, Sep 17, 2012 at 1:44 PM, Robby Findler
wrote:
> It will appear when the online check syntax finds some documentation
> for the identifier at the insertion point. If you edit the identifier,
> it will disappear (but it may r
Hi,
I'm a beginner, but I have some experience with Scheme and Haskell.
Haskell is famous for its strict type system. Is it possible to achieve
this in a Lisp-like language? Is Typed Racket as strict as Haskell?
I'd like to see a comparison between the two.
(Please don't refer me to the docs. B
Thanks for the info guys, now I understand what's going on.
Cheers,
Kieron
Racket Users list:
http://lists.racket-lang.org/users
I don't think the parameter overhead is relevant. In Jay's post, he
performs 100k parameter accesses, and it takes 16 milliseconds; we can
reasonably extrapolate 160 msec for 1M accesses. Patrick's generator
example yields 1M times, and takes 18 seconds --- 100x the parameter
overhead.
I agree wit
An hour ago, Greg Hendershott wrote:
> In generator.rkt I notice an early version that didn't support
> multiple values. The new version does, keeping a "yielder" proc in a
> parameter.
>
> Could a single-valued generator yield be faster enough? Or am I
> misapplying my misunderstanding? :)
That
This stuff is still over my head; I'm at that "know just enough to be
dangerous" stage. With that caveat:
Jay's blog post
http://jeapostrophe.github.com/blog/2012/07/25/cont-marks2/ mentions
that parameters can be >10X slower than dynamic-wind.
In generator.rkt I notice an early version that didn
On 18/09/2012 00:24, Matthias Felleisen wrote:
On Sep 16, 2012, at 2:36 PM, Patrick Useldinger wrote:
Which makes me wonder if continuations are really usable in Racket (in terms of
performance)?
That is a good question, and the answer is 'yes, in the right situation'. I
think the use in the
Someday I hope to make check syntax work better in situations like
that, but in the meantime, you can also hash-quote identifiers too,
ie:
#lang racket
#'lambda
will make CS find the docs.
Robby
On Tue, Sep 18, 2012 at 12:58 AM, Laurent wrote:
> Fantastic!
> Thank you very much, I prefer it ov
42 matches
Mail list logo
