[racket-users] Re: Judgement not holding

[philngu...@gmail.com]

It’s difficult without seeing the definitions, but here are a few general 
comments:

1. Cases in judgment forms are not run in order. If multiple cases match, 
they’ll all hold. For example, in this case, if (anotin ((a -> b ...)) a #t) 
holds, (anotin ((a_0 -> b ...)) a #f) will also hold.

2. If your environment looks something like ((a_1 -> b_1) (a_2 -> b_2) (a_3 
-> b_3)), the pattern for the second case should be (_ ... (a -> b) _ ...). 
The ellipses after b as it currently is means a sequence of zero or more b
’s.

3. The relation is being named “not in”, but it seems like it’s computing 
both “in” and “not in” cases, which is confusing.

4. Checking for membership in an environment sounds like a (very) decidable 
problem. It maybe simpler to just write a judgment form for the positive 
case, and simply defining the negative case as “when the judgment doesn’t 
hold”.

On Wednesday, April 7, 2021 at 9:57:15 AM UTC-7 beatriz@gmail.com wrote:

> Hello,
> I'm trying to write a side condition to a function, where it checks if a 
> is in an environment ß. I tried this judgement by adding (judgment-holds 
> (anotin (ß-v ...) a #f)) at the end of the function but it is not working 
> :(
> Thank you!
> --Beatriz
>
> (define-judgment-form Flint
>   #:mode (anotin I I O)
>   #:contract (anotin env-ß a boolean)
>   [-
>(anotin () a #f)]
>   [-
>(anotin ((a -> b ...)) a #t)]
>   [-
>(anotin ((a_0 -> b ...)) a #f)]
>   [-
>(anotin (ß-v_0 ... (a -> b ...)) a #t)]
>   [(anotin (ß-v ...) a boolean)
>-
>(anotin (ß-v ... (a_0 -> b ...) ) a boolean)]
>   )
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/439fb7f2-2872-433f-bddf-2a92b16d7701n%40googlegroups.com.

Re: [racket-users] Racket slower than Chez Scheme on interpreter benchmark, potential low hanging fruit?

[philngu...@gmail.com]

Oh I see. So one problem is here that `match-define` expands to `match` 
with an implicit error case, which at the low level, isn't distinguished 
from a user-written second case, and the tag check can't just be eliminated.

On Thursday, March 4, 2021 at 9:40:22 AM UTC-8 Sam Tobin-Hochstadt wrote:

> I think there are two reasons that code gets slower.
>
> 1. The `match-define` includes pair and struct checks, which are
> omitted for plain accessor uses because of the unsafe declaration.
> 2. That use of `match` expands to `define-values` which ends up as a
> `call-with-values` and a `case-lambda` at the chez layer and is not
> removed.
>
> `match` could recognize that it's being compiled with unsafe mode and
> omit these checks, although it's not that straightforward. Also
> schemify (or Chez) could do more to eliminate the use of multiple
> values, although that's hard without eliminating the failure cases.
>
> Sam
>
> On Thu, Mar 4, 2021 at 3:23 AM philngu...@gmail.com
>  wrote:
> >
> > Thanks for the tip about PLT_CS_COMPILE_LIMIT! I submitted a revision to 
> the syntax object variant that incorporated sleepnova's and yjqww6's 
> improvements.
> >
> > Also, I never knew about `(#%declare #:unsafe)` until I saw yjqww6's 
> pull request. It makes a noticeable difference. One unsatisfying thing is 
> that in one place, if I replace the 4 separate define clauses with just 
> `(match-define (cons (op o val) rst) parsed)`, the benchmarks are more than 
> twice slower.
> >
> > On Wednesday, March 3, 2021 at 11:12:30 AM UTC-8 Sam Tobin-Hochstadt 
> wrote:
> >>
> >> First, there's no longer a difference because yjqww6 just had a PR
> >> merged that improves the Racket performance.
> >>
> >> The performance difference that was there was mostly because the Chez
> >> code was run with `--optimize-level 3` which turns off safety. If that
> >> was changed to `--optimize-level 2` the timing became much slower.
> >>
> >> Sam
> >>
> >> On Mon, Mar 1, 2021 at 2:39 AM philngu...@gmail.com
> >>  wrote:
> >> >
> >> > There’s this benchmark on BF interpreter where the Racket and Chez 
> Scheme implementations are very similar, but Chez Scheme is much faster 
> than Racket 8.0 at interpreting bench.b (3s vs 8s) and mandel.b (40s vs 
> 136s).
> >> >
> >> > There’s the “Racket (Syntax Object)” variant that directly parses 
> BF’s syntax into Racket syntax object, which is faster (3.7s for bench, 82s 
> for mandel), but still significantly behind Chez Scheme’s naive interpreter.
> >> >
> >> > Profiling doesn’t give very illuminating results, saying most of the 
> cost is from interpreting BF’s loop instruction.
> >> >
> >> > Given that Racket is on Chez, could this benchmark reveal some low 
> hanging fruit for improving Racket’s performance?
> >> >
> >> > --
> >> > You received this message because you are subscribed to the Google 
> Groups "Racket Users" group.
> >> > To unsubscribe from this group and stop receiving emails from it, 
> send an email to racket-users...@googlegroups.com.
> >> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/racket-users/83b2819d-8295-4769-944d-fa0c155976dan%40googlegroups.com
> .
> >
> > --
> > You received this message because you are subscribed to the Google 
> Groups "Racket Users" group.
> > To unsubscribe from this group and stop receiving emails from it, send 
> an email to racket-users...@googlegroups.com.
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/racket-users/a5e77286-68b8-481a-8dea-0f547c5ce968n%40googlegroups.com
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/f771a13a-9fc4-4b71-9e47-3a83eb5290e7n%40googlegroups.com.

Re: [racket-users] Racket slower than Chez Scheme on interpreter benchmark, potential low hanging fruit?

[philngu...@gmail.com]

Thanks for the tip about PLT_CS_COMPILE_LIMIT! I submitted a revision to 
the syntax object variant that incorporated sleepnova's and yjqww6's 
improvements.

Also, I never knew about `(#%declare #:unsafe)` until I saw yjqww6's pull 
request. It makes a noticeable difference. One unsatisfying thing is that 
in one place, if I replace the 4 separate define clauses 
<https://github.com/kostya/benchmarks/blob/47c256dd78b6fa884a36c88b3c936cbe135f835a/brainfuck/bf.rkt#L82>
 
with just `(match-define (cons (op o val) rst) parsed)`, the benchmarks are 
more than twice slower.

On Wednesday, March 3, 2021 at 11:12:30 AM UTC-8 Sam Tobin-Hochstadt wrote:

> First, there's no longer a difference because yjqww6 just had a PR
> merged that improves the Racket performance.
>
> The performance difference that was there was mostly because the Chez
> code was run with `--optimize-level 3` which turns off safety. If that
> was changed to `--optimize-level 2` the timing became much slower.
>
> Sam
>
> On Mon, Mar 1, 2021 at 2:39 AM philngu...@gmail.com
>  wrote:
> >
> > There’s this benchmark on BF interpreter where the Racket and Chez 
> Scheme implementations are very similar, but Chez Scheme is much faster 
> than Racket 8.0 at interpreting bench.b (3s vs 8s) and mandel.b (40s vs 
> 136s).
> >
> > There’s the “Racket (Syntax Object)” variant that directly parses BF’s 
> syntax into Racket syntax object, which is faster (3.7s for bench, 82s for 
> mandel), but still significantly behind Chez Scheme’s naive interpreter.
> >
> > Profiling doesn’t give very illuminating results, saying most of the 
> cost is from interpreting BF’s loop instruction.
> >
> > Given that Racket is on Chez, could this benchmark reveal some low 
> hanging fruit for improving Racket’s performance?
> >
> > --
> > You received this message because you are subscribed to the Google 
> Groups "Racket Users" group.
> > To unsubscribe from this group and stop receiving emails from it, send 
> an email to racket-users...@googlegroups.com.
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/racket-users/83b2819d-8295-4769-944d-fa0c155976dan%40googlegroups.com
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/a5e77286-68b8-481a-8dea-0f547c5ce968n%40googlegroups.com.

[racket-users] Racket slower than Chez Scheme on interpreter benchmark, potential low hanging fruit?

[philngu...@gmail.com]

There’s this benchmark on BF interpreter where the Racket 
 and Chez 
Scheme  
implementations are very similar, but Chez Scheme is much faster than 
Racket 8.0 at interpreting bench.b 
 (3s vs 8s) and mandel.b 
 (40s vs 136s).

There’s the “Racket (Syntax Object) 
” 
variant that directly parses BF’s syntax into Racket syntax object, which 
is faster (3.7s for bench, 82s for mandel), but still significantly behind 
Chez Scheme’s naive interpreter.

Profiling doesn’t give very illuminating results, saying most of the cost 
is from interpreting BF’s loop instruction.

Given that Racket is on Chez, could this benchmark reveal some low hanging 
fruit for improving Racket’s performance?

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/83b2819d-8295-4769-944d-fa0c155976dan%40googlegroups.com.

[racket-users] Re: [ANNOUNCE] New package typed-compose

[philngu...@gmail.com]

Nice package. I don't have an account and don't know how to do pull request 
on Marvid thing, but I suggest making a macro generating `compose-n` for 
arbitrary (statically known) n, and export it along side with the 
predefined compose-n functions, something along these lines:

#lang typed/racket/base

(provide make-compose
 compose-3 compose-4)

(require (for-syntax racket/base
 racket/match
 racket/list
 racket/syntax
 syntax/parse))

(define-for-syntax (make-compose-type n)
  (with-syntax* ([(t ...) (generate-temporaries (make-list n 't))]
 [a (generate-temporary 'a)]
 [(_ ... t₀) #'(a t ...)]
 [(F ...)
  (let step ([u #'a] [ts (syntax->list #'(t ...))])
(match ts
  ['() '()]
  [(cons t ts*) (cons #`(#,t → #,u) (step t ts*))]))])
#'(∀ (a t ...) (F ... → t₀ → a

(define-syntax make-compose
  (syntax-parser
[(_ n:nat)
 (with-syntax* ([(f ...) (generate-temporaries (make-list (syntax-e 
#'n) 'f))]
[x (generate-temporary 'x)]
[T (make-compose-type (syntax-e #'n))]
[body (foldr (λ (fᵢ res) #`(#,fᵢ #,res)) #'x 
(syntax->list #'(f ...)))])
   #'(ann (λ (f ...) (λ (x) body)) T))]))

(define compose-3 (make-compose 3))
(define compose-4 (make-compose 4))
;; and so on



On Monday, January 4, 2021 at 12:52:11 PM UTC-8 unlimitedscolobb wrote:

> Hello,
>
> I am glad to announce typed-compose, a small package defining some 
> utilities for composing functions in Typed Racket:
>
> https://pkgd.racket-lang.org/pkgn/package/typed-compose
>
> Typed Racket's compose only takes two arguments, because in general it is 
> difficult to specify that the return types and the argument types should be 
> the same for two successive functions in the argument list. This package 
> defines some further utilities to allow compose-ing more than two 
> functions more comfortable in Typed Racket.
>
> This is my first ever Racket package, so I'm taking all kinds of feedback.
>
> -
> Sergiu
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/75c18da4-1403-4f70-8c58-08511d21c71an%40googlegroups.com.