On May 14, Matthias Felleisen wrote:
>
> Aha. I finally discovered this comment in the original file, miles
> away:
>
> ;; take/drop-right are originally from srfi-1, uses the same lead-
> pointer trick
It comes immediately before the three functions that do that trick.
On May 14, Sam Tobin-H
I can confirm these times. And I have no clue how this can be!!!
How can anyone possibly predict that two nearly identical loops
over the 'lead' ptr structure beat one loop over the same S-exp
plus a tiny bit of reverse?
Here is my guess at an answer: v1 CONSes as it traverses 'lead'
and neithe
On 05/14/2010 08:45 AM, Sam Tobin-Hochstadt wrote:
> On Fri, May 14, 2010 at 10:42 AM, Jay
McCarthy wrote:
>> And how is the performance after the fix? Is the opaque coding worth it?
>
> Eli's version is about 40-50% faster than Matthias':
>
> Large lists:
> cpu time: 14697 real time: 14689 gc
Is reverse implemented in Racket or C?
On Friday, May 14, 2010, Matthias Felleisen wrote:
>
> So why is that?
>
>
> On May 14, 2010, at 10:45 AM, Sam Tobin-Hochstadt wrote:
>
>
> On Fri, May 14, 2010 at 10:42 AM, Jay McCarthy wrote:
>
> And how is the performance after the fix? Is the opaque cod
On Fri, May 14, 2010 at 10:42 AM, Jay McCarthy wrote:
> And how is the performance after the fix? Is the opaque coding worth it?
Eli's version is about 40-50% faster than Matthias':
Large lists:
cpu time: 14697 real time: 14689 gc time: 4560
cpu time: 8400 real time: 8394 gc time: 1696
Small li
So why is that?
On May 14, 2010, at 10:45 AM, Sam Tobin-Hochstadt wrote:
On Fri, May 14, 2010 at 10:42 AM, Jay McCarthy
wrote:
And how is the performance after the fix? Is the opaque coding
worth it?
Eli's version is about 40-50% faster than Matthias':
Large lists:
cpu time: 14697 real
Sam claims that the original split is twice as fast as my re-design.
On May 14, 2010, at 10:42 AM, Jay McCarthy wrote:
And how is the performance after the fix? Is the opaque coding worth
it?
On Fri, May 14, 2010 at 8:39 AM, Matthias Felleisen
wrote:
On May 14, 2010, at 9:43 AM, Matthia
And how is the performance after the fix? Is the opaque coding worth it?
On Fri, May 14, 2010 at 8:39 AM, Matthias Felleisen
wrote:
>
> On May 14, 2010, at 9:43 AM, Matthias Felleisen wrote:
>
>>
>> (define (stress-test split)
>> (define n 2)
>> (define l (build-list n add1))
>> (define _
On May 14, 2010, at 9:43 AM, Matthias Felleisen wrote:
(define (stress-test split)
(define n 2)
(define l (build-list n add1))
(define _ (begin (collect-garbage) (collect-garbage)))
(define x
(time
(for/list ((i (in-range n)))
(define-values (x y) (split-at-right l i))
Aha. I finally discovered this comment in the original file, miles away:
;; take/drop-right are originally from srfi-1, uses the same lead-
pointer trick
On May 14, 2010, at 9:43 AM, Matthias Felleisen wrote:
As I continued my contracting of racket/list last night, I
encountered a st
As I continued my contracting of racket/list last night, I encountered
a strange function:
(define (split-at-right.v1 list n)
(let loop ([list list]
[lead (or (drop* list n) (err2large 'split-at-right list
n))]
[pfx '()])
;; could throw an error for non-list
1. Whatever you do, don't do warnings. Issue error messages, insert exceptions
raises, but don't issue warnings.
2. Is this one of those places where Typed Scheme is NOT ML would have been the
appropriate short-cut? TS isn't even about typed programming per se; it's about
moving code into the
I thought you were talking about lets. I was referring to this:
Standard ML of New Jersey v110.72 [built: Wed Feb 3 11:03:59 2010]
- fun snd x = let val (a::b::c) = x in b end;
val snd = fn : 'a list -> 'a
- snd [1,2,3];
val it = 2 : int
- snd [1];
uncaught exception Bind [nonexhaustive binding
On Tue, Apr 13, 2010 at 1:09 PM, Robby Findler
wrote:
>>
>> What if we change the contract to:
>>
>> ((list/c any/c any/c) . -> . any/c)
>>
>> Now the error case is unreachable, but `match' doesn't know that.
>> This also suggests that almost every single use of `match-let' should
>> trigger a war
On Tue, Apr 13, 2010 at 11:54 AM, Sam Tobin-Hochstadt wrote:
> On Tue, Apr 13, 2010 at 12:42 PM, Robby Findler
> wrote:
>> On Tue, Apr 13, 2010 at 10:47 AM, Sam Tobin-Hochstadt
>> wrote:
>>> On Tue, Apr 13, 2010 at 9:08 AM, Robby Findler
>>> wrote:
On Tue, Apr 13, 2010 at 7:15 AM, Sam Tob
On Tue, Apr 13, 2010 at 12:42 PM, Robby Findler
wrote:
> On Tue, Apr 13, 2010 at 10:47 AM, Sam Tobin-Hochstadt
> wrote:
>> On Tue, Apr 13, 2010 at 9:08 AM, Robby Findler
>> wrote:
>>> On Tue, Apr 13, 2010 at 7:15 AM, Sam Tobin-Hochstadt
>>> wrote:
On Tue, Apr 13, 2010 at 4:42 AM, Paulo J
On Tue, Apr 13, 2010 at 10:47 AM, Sam Tobin-Hochstadt wrote:
> On Tue, Apr 13, 2010 at 9:08 AM, Robby Findler
> wrote:
>> On Tue, Apr 13, 2010 at 7:15 AM, Sam Tobin-Hochstadt
>> wrote:
>>> On Tue, Apr 13, 2010 at 4:42 AM, Paulo J. Matos wrote:
Awesome, this one of my favourite featur
On Tue, Apr 13, 2010 at 9:08 AM, Robby Findler
wrote:
> On Tue, Apr 13, 2010 at 7:15 AM, Sam Tobin-Hochstadt
> wrote:
>> On Tue, Apr 13, 2010 at 4:42 AM, Paulo J. Matos wrote:
>>>
>>> Awesome, this one of my favourite features missing in Scheme. Hopefully
>>> we will see this soon in TS, Sam?
>
On Apr 13, Sam Tobin-Hochstadt wrote:
> On Tue, Apr 13, 2010 at 4:42 AM, Paulo J. Matos wrote:
> >
> > Awesome, this one of my favourite features missing in
> > Scheme. Hopefully we will see this soon in TS, Sam?
>
> Yes, we will hopefully soon see the form Eli describes. But it
> won't give you
On Apr 13, Matthias Felleisen wrote:
>
> The idea even predates Eli. It's from a time when I saved EOPL from
> ML :-)
And Jay McCarthy wrote:
> This functionality is available for all today in the PLAI language.
> The documentation is at: [...]
Yes, I should have said that my code was loosely ba
On Tue, Apr 13, 2010 at 7:15 AM, Sam Tobin-Hochstadt wrote:
> On Tue, Apr 13, 2010 at 4:42 AM, Paulo J. Matos wrote:
>>
>> Awesome, this one of my favourite features missing in Scheme. Hopefully
>> we will see this soon in TS, Sam?
>
> Yes, we will hopefully soon see the form Eli describes. But
This functionality is available for all today in the PLAI language.
The documentation is at:
http://docs.plt-scheme.org/plai/plai-scheme.html
You can get it anywhere with
(require plai/datatype)
Jay
On Tue, Apr 13, 2010 at 2:42 AM, Paulo J. Matos wrote:
> Eli Barzilay writes:
>
>>>
>>> The c
Then provide cases, too.
On Apr 13, 2010, at 8:15 AM, Sam Tobin-Hochstadt wrote:
> On Tue, Apr 13, 2010 at 4:42 AM, Paulo J. Matos wrote:
>>
>> Awesome, this one of my favourite features missing in Scheme. Hopefully
>> we will see this soon in TS, Sam?
>
> Yes, we will hopefully soon see th
On Apr 13, 2010, at 4:23 AM, Eli Barzilay wrote:
> (Oh, and while this is a dialect of TS, the code predates it, and did
> the same with plain scheme structs previously.)
The idea even predates Eli. It's from a time when I saved EOPL from ML :-)
On Tue, Apr 13, 2010 at 4:42 AM, Paulo J. Matos wrote:
>
> Awesome, this one of my favourite features missing in Scheme. Hopefully
> we will see this soon in TS, Sam?
Yes, we will hopefully soon see the form Eli describes. But it won't
give you exhaustiveness checking in general for `match', tha
Eli Barzilay writes:
> On Apr 12, Matthias Felleisen wrote:
>> > 5. Code for exhaustiveness (pattern matches enumerate all conditions).
>>
>> What you can see is that almost all of these apply to programming in
>> PLT Scheme. Well, for 8, I will defer to Sam :-)
>
> #5 isn't in use outside of
Eli Barzilay writes:
>>
>> The code that I'm talking about is a dialect of typed scheme that has
>> ML-like type definitions and matching, with the same kind of errors
>> when matches don't cover all cases, and when there are patterns that
>> are not reachable. It's working only for these type
On Apr 13, Eli Barzilay wrote:
> On Apr 13, Paulo J. Matos wrote:
> > Eli Barzilay writes:
> >
> > > On Apr 12, Matthias Felleisen wrote:
> > >> > 5. Code for exhaustiveness (pattern matches enumerate all
> > >> >conditions).
> > >>
> > >> What you can see is that almost all of these apply t
On Apr 13, Paulo J. Matos wrote:
> Eli Barzilay writes:
>
> > On Apr 12, Matthias Felleisen wrote:
> >> > 5. Code for exhaustiveness (pattern matches enumerate all
> >> >conditions).
> >>
> >> What you can see is that almost all of these apply to programming
> >> in PLT Scheme. Well, for 8,
On Apr 12, Matthias Felleisen wrote:
> > 5. Code for exhaustiveness (pattern matches enumerate all conditions).
>
> What you can see is that almost all of these apply to programming in
> PLT Scheme. Well, for 8, I will defer to Sam :-)
#5 isn't in use outside of my class's language(s).
--
Yaron Minsky, JaneStreet, recently spoke to Olin's compiler class. I
thought I had counted ten points from his discussion of coding
techniques but as you can see below, I wrote down only 10. (Yaron was
on a plt list for a while; perhaps he can correct me)
Yaron Minsky, JaneStreet
What
31 matches
Mail list logo
