Re: [racket-dev] Surprising behavior of for/fold. Bug?

[J. Ian Johnson]

I forgot that aspect of #:when and #:unless. Sorry for the noise.
-Ian
- Original Message -
From: "Sam Tobin-Hochstadt" 
To: "J. Ian Johnson" 
Cc: "dev" 
Sent: Tuesday, July 29, 2014 4:46:49 PM GMT -05:00 US/Canada Eastern
Subject: Re: [racket-dev] Surprising behavior of for/fold. Bug?

`#:when` and `#:unless` introduce nesting, a la `for/fold*`. So yes,
you should expect this.

Sam

On Tue, Jul 29, 2014 at 1:23 PM, J. Ian Johnson  wrote:
> This will eat all your memory,
>
> (for/list ([x '(0 1 2 3 4 5 6)]
>#:unless (= x 4)
>[i (in-naturals)])
>   x)
>
> and this won't.
>
> (for/list ([x '(0 1 2 3 4 5 6)]
>[i (in-naturals)]
>#:unless (= x 4))
>   x)
>
> Should we expect this behavior? I was really surprised by this.
> -Ian
> _
>   Racket Developers list:
>   http://lists.racket-lang.org/dev
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

[racket-dev] Surprising behavior of for/fold. Bug?

[J. Ian Johnson]

This will eat all your memory,

(for/list ([x '(0 1 2 3 4 5 6)]
   #:unless (= x 4)
   [i (in-naturals)])
  x)

and this won't.

(for/list ([x '(0 1 2 3 4 5 6)]
   [i (in-naturals)]
   #:unless (= x 4))
  x)

Should we expect this behavior? I was really surprised by this.
-Ian
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] pkg account creator not working?

[J. Ian Johnson]

I've tried both now. No go.
-Ian
- Original Message -
From: "Leif Andersen" 
To: "J. Ian Johnson" 
Cc: "dev" 
Sent: Monday, July 21, 2014 12:35:06 PM GMT -05:00 US/Canada Eastern
Subject: Re: [racket-dev] pkg account creator not working?

What web browser are you using?

I was only able to make an account using Chromium. (Firefox didn't work for me.)

~Leif Andersen


On Mon, Jul 21, 2014 at 12:27 PM, J. Ian Johnson  wrote:
> I tried to make an account of pkgs.racket-lang.org, and it never emailed me a 
> code. Is something in the pipeline not working?
> -Ian
> _
>   Racket Developers list:
>   http://lists.racket-lang.org/dev
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

[racket-dev] pkg account creator not working?

[J. Ian Johnson]

I tried to make an account of pkgs.racket-lang.org, and it never emailed me a 
code. Is something in the pipeline not working?
-Ian
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Semantics of struct-out with except-out

[J. Ian Johnson]

Code will break if it uses struct to produce structs, provides a renamed an 
accessor function, and uses an unhygienic feature to name the field.
The features I know of are struct-copy, struct* match patterns, and 
contract-out's struct form.

No one but me probably did this, and that's what led to my discovery of the 
unhygienic state of struct-copy and my previous regex-based PR to "fix" it.
I don't /need/ to rename fields, since in the case that a field accessor is 
renamed to something entirely different (e.g., Foo-x => Qux), a renamed field 
doesn't quite benefit readability of a struct-copy that uses field "x". If 
renaming Foo-x to Foo-y, then a x -> y rename is helpful. I have not yet come 
across a need for this however.
I can wait on this feature of struct-out (and probably contract-out's struct 
form as well).

Thanks,
-Ian
- Original Message -----
From: "Sam Tobin-Hochstadt" 
To: "J. Ian Johnson" 
Cc: "dev" 
Sent: Tuesday, July 15, 2014 9:35:01 AM GMT -05:00 US/Canada Eastern
Subject: Re: [racket-dev] Semantics of struct-out with except-out

On Tue, Jul 15, 2014 at 9:23 AM, J. Ian Johnson  wrote:
> I'm working on enhancing struct-info to carry field names as symbols to do 
> nice hygienic things:
>
> http://lists.racket-lang.org/users/archive/2014-July/063271.html
>
> I now see that struct-out always provides all field accessors in the static 
> struct-info associated with the struct identifier.
> This means the following produces (list 0 1) instead of an error saying that 
> Foo-x is undefined, or something along those lines:
>
> #lang racket/load
> (module A racket
>   (struct Foo (x y))
>   (provide (except-out (struct-out Foo)
>Foo-x)))
> (module B racket
>   (require 'A)
>   (match (Foo 0 1)
> [(Foo x y) (list x y)]))
> (require 'B)
>
> To make struct-out not so greedy about what it provides would require a 
> backwards-incompatible change. The problem then is, should we (I) do it?

No, the current behavior is reasonable -- static struct info provides
access to the accessors.

> Part of me says yes for "intuitive semantics" and part of me says no because 
> the implications are that struct-info values will have to be meticulously 
> checked and rebound to mangled identifiers with new information when passing 
> through provide-specs that can affect struct identifiers.
> Should that burden be pushed to future provide-spec implementors? Should it 
> already have been?
> The alternative is to provide special syntax in struct-out to do all the 
> "common" provide-spec stuff and still not play nice with other provide-specs.
> The upside to this is no name mangling, but the downside is yet more special 
> syntax for what provide-specs should already do, IMHO.
>
> I'm planning to extend struct-out to allow renaming the fields associated 
> with a struct so the following (contrived example) is possible:

I think this should be delayed to a separate change. Are there cases
in the code base currently where this would be used?

Sam
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

[racket-dev] Semantics of struct-out with except-out

[J. Ian Johnson]

I'm working on enhancing struct-info to carry field names as symbols to do nice 
hygienic things:

http://lists.racket-lang.org/users/archive/2014-July/063271.html

I now see that struct-out always provides all field accessors in the static 
struct-info associated with the struct identifier.
This means the following produces (list 0 1) instead of an error saying that 
Foo-x is undefined, or something along those lines:

#lang racket/load
(module A racket
  (struct Foo (x y))
  (provide (except-out (struct-out Foo)
   Foo-x)))
(module B racket
  (require 'A)
  (match (Foo 0 1)
[(Foo x y) (list x y)]))
(require 'B)

To make struct-out not so greedy about what it provides would require a 
backwards-incompatible change. The problem then is, should we (I) do it?
Part of me says yes for "intuitive semantics" and part of me says no because 
the implications are that struct-info values will have to be meticulously 
checked and rebound to mangled identifiers with new information when passing 
through provide-specs that can affect struct identifiers.
Should that burden be pushed to future provide-spec implementors? Should it 
already have been?
The alternative is to provide special syntax in struct-out to do all the 
"common" provide-spec stuff and still not play nice with other provide-specs.
The upside to this is no name mangling, but the downside is yet more special 
syntax for what provide-specs should already do, IMHO.

I'm planning to extend struct-out to allow renaming the fields associated with 
a struct so the following (contrived example) is possible:

#lang racket/load
(module A racket
  (struct Foo (x y))
  (provide (struct-out Foo #:rename-fields ([x y] [y x]
(module B racket
  (require 'A)
  (match (Foo 0 1)
[(Foo [#:x 0] [#:y 1]) #f]
[(Foo [#:x 1] [#:y 0]) #t]))
(require 'B)
;=> #t

The #:rename-fields is pseudo-code. Ideally we want to provide any or all 
struct identifiers with or without renaming.
Fields are special to the struct-info itself, so that will need to be tied to 
struct-out.
If a struct's field accessor is not provided, that means it is not in the 
struct-info. That means match looks weird and asymmetric, but so be it:

#lang racket/load
(module A racket
  (struct Foo (x y))
  (provide (except-out (struct-out Foo)
   Foo-x)))
(module B racket
  (require 'A)
  (match (Foo 0 1)
[(Foo y) y]))
(require 'B)
;=> 1

If we don't want it to be asymmetric but instead require that positionally it 
is uninspected (so that the unsafe-struct-ref logic in match still works), that
would require a representation change for struct-info. Instead of accessors 
being given as (list id ... #f) (optional #f for missing super type info), they 
would be given as (list id-or-#f ... 'unknown) (optional 'unknown for missing 
super type info).
The 'unknown instead of #f is probably the only thing that would break existing 
code.
If they are using except-out with struct-out and depending on a full 
struct-info, they have a bug, IMHO.
I'm willing to update the current codebase to the new representation.

I have a feature branch with everything in it except any changes to struct-out. 
I did have to make changes to providing contracted structs, due to name 
mangling needing to carry forward my extended-struct-info. Foreshadowing.

https://github.com/ianj/racket/tree/match-named

Comments welcome.
Thanks,
-Ian
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Racket peephole opt in lieu of TR's generalized ListDots to usefully type hash

[J. Ian Johnson]

Thanks, that works even marginally better than (hash k v).
-Ian
- Original Message -
From: "Matthew Flatt" 
To: "J. Ian Johnson" 
Cc: "dev" 
Sent: Sunday, June 29, 2014 2:08:06 AM GMT -05:00 US/Canada Eastern
Subject: Re: [racket-dev] Racket peephole opt in lieu of TR's generalized 
ListDots to usefully type hash

How about `(hash-set #hash() k v)`?

(I probably should have been more careful in defining `hash` to allow
it to return a constant when given 0 arguments.)

At Sat, 28 Jun 2014 09:56:05 -0400 (EDT), "J. Ian Johnson" wrote:
> I depend highly on creating singleton hashes in my program (one key maps). I 
> tried a few ways to create them, but alas directly using hash is the best. TR 
> can't type non-nullary applications hash though.
> The times of the following test are the same in TR as in normal Racket, so 
> I'd 
> like to see peephole optimizations that turn the first two into the last one:
> 
> #lang racket
> 
> (define N 500)
> (define keys (build-list N (λ (d) (random
> (define values (build-list N (λ (d) (random
> 
> (define (clean!)
>   (collect-garbage)
>   (collect-garbage)
>   (collect-garbage))
> (clean!)
> (time (for ([k (in-list keys)]
> [v (in-list values)])
> (hash-set (hash) k v)))
> ;cpu time: 460 real time: 461 gc time: 13
> 
> (clean!)
> (time (for ([k (in-list keys)]
> [v (in-list values)])
> (make-immutable-hash (list (cons k v)
> ;cpu time: 507 real time: 506 gc time: 29
> 
> (clean!)
> (time (for ([k (in-list keys)]
> [v (in-list values)])
> (hash k v)))
> ;cpu time: 393 real time: 392 gc time: 17
> 
> ;;;
> 
> I'd provide a patch, but I don't know where this kind of thing lives in the 
> compiler if it exists at all.
> -Ian
> 
> _
>   Racket Developers list:
>   http://lists.racket-lang.org/dev

_
  Racket Developers list:
  http://lists.racket-lang.org/dev

[racket-dev] Racket peephole opt in lieu of TR's generalized ListDots to usefully type hash

[J. Ian Johnson]

I depend highly on creating singleton hashes in my program (one key maps). I 
tried a few ways to create them, but alas directly using hash is the best. TR 
can't type non-nullary applications hash though.
The times of the following test are the same in TR as in normal Racket, so I'd 
like to see peephole optimizations that turn the first two into the last one:

#lang racket

(define N 500)
(define keys (build-list N (λ (d) (random
(define values (build-list N (λ (d) (random

(define (clean!)
  (collect-garbage)
  (collect-garbage)
  (collect-garbage))
(clean!)
(time (for ([k (in-list keys)]
[v (in-list values)])
(hash-set (hash) k v)))
;cpu time: 460 real time: 461 gc time: 13

(clean!)
(time (for ([k (in-list keys)]
[v (in-list values)])
(make-immutable-hash (list (cons k v)
;cpu time: 507 real time: 506 gc time: 29

(clean!)
(time (for ([k (in-list keys)]
[v (in-list values)])
(hash k v)))
;cpu time: 393 real time: 392 gc time: 17

;;;

I'd provide a patch, but I don't know where this kind of thing lives in the 
compiler if it exists at all.
-Ian

_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] for loops with interleaved escape continuations

[J. Ian Johnson]

There are a couple issues here,
One is that #:when in for-clauses allows you to skip iterations, but you want 
it in the body. This is a cosmetic difference that you can get around by doing 
#:when (begin imperative-stuff-before-guard guard). If you want ecs to escape 
an entire for loop, that's what #:break is for. If you want ecs to escape even 
more for loops, well, that is an unplanned but a possibly useful feature for 
nested for loops.
The other is that this is not Rackety and thus not natively supported for the 
same reason there are no "return" statements. The for macros are so much more 
than Python's for - they can produce values. Don't throw everything into the 
void :)
-Ian
 Original Message -
From: Jay Kominek 
To: dev 
Sent: Fri, 27 Jun 2014 17:15:45 -0400 (EDT)
Subject: [racket-dev] for loops with interleaved escape continuations

I've been converting a bunch of Python to Racket lately, and I have a
lot of loops that use break and continue. I end up turning them into:

(let/ec break
  (for (...)
(let/ec continue
  ; do some work
  (when this-iteration-isn't-what-i-want
(continue))
  ; do more expensive work
  (when found-what-i-want
(break what-i-want)

I thought it would be nice if the let/ec's could be integrated with
for, so that you could instead write:

(for (#:ec break
   ...
   #:ec continue)
  ; ...same as above...

In an attempt to help convey the behavior I want, I threw this patch together:

https://github.com/jkominek/racket/commit/b291a0b994c679445b3210bd3efba8c6cea867e4

I feel it behaves reasonably when using for and for/fold, but for/list
doesn't behave in any way I'd hope for.

Ideally somebody who understands for's implementation will agree that
this is a great idea, and go make it all work nicely. :) Failing that
I'm open to suggestions for how to make it behave better, in a fashion
which would make it appropriate for inclusion.

-- 
Jay Kominek
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Broken build?

[J. Ian Johnson]

Fixed. Sorry for the noise.
-Ian
- Original Message -
From: "Sam Tobin-Hochstadt" 
To: "J. Ian Johnson" 
Cc: "dev" 
Sent: Friday, June 20, 2014 10:06:40 AM GMT -05:00 US/Canada Eastern
Subject: Re: [racket-dev] Broken build?

The current Travis build succeed https://travis-ci.org/plt/racket so I
think you probably have some stale compiled files somewhere.

Sam

On Fri, Jun 20, 2014 at 10:03 AM, J. Ian Johnson  wrote:
> I just pulled and make gives me this
>
> libracket.a(optimize.o): In function `expr_implies_predicate':
> /home/ianj/racket/racket/src/build/racket/src/../../../racket/src/optimize.c:2353:
>  undefined reference to `scheme_syntax_p_proc'
> libracket.a(optimize.o): In function `relevant_predicate':
> /home/ianj/racket/racket/src/build/racket/src/../../../racket/src/optimize.c:3539:
>  undefined reference to `scheme_syntax_p_proc'
> libracket.a(validate.o): In function `is_functional_rator':
> /home/ianj/racket/racket/src/build/racket/src/../../../racket/src/validate.c:1235:
>  undefined reference to `scheme_is_functional_primitive'
> collect2: error: ld returned 1 exit status
>
> -Ian
> _
>   Racket Developers list:
>   http://lists.racket-lang.org/dev
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

[racket-dev] Broken build?

[J. Ian Johnson]

I just pulled and make gives me this

libracket.a(optimize.o): In function `expr_implies_predicate':
/home/ianj/racket/racket/src/build/racket/src/../../../racket/src/optimize.c:2353:
 undefined reference to `scheme_syntax_p_proc'
libracket.a(optimize.o): In function `relevant_predicate':
/home/ianj/racket/racket/src/build/racket/src/../../../racket/src/optimize.c:3539:
 undefined reference to `scheme_syntax_p_proc'
libracket.a(validate.o): In function `is_functional_rator':
/home/ianj/racket/racket/src/build/racket/src/../../../racket/src/validate.c:1235:
 undefined reference to `scheme_is_functional_primitive'
collect2: error: ld returned 1 exit status

-Ian
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] actionable items, was: comments on "comments on learning Racket"

[J. Ian Johnson]

Yes, there are many cases to cover. The important problem to solve is what is 
the right default? What is appropriate 95% of the time? I don't have that data.
You could have different distributions also, with the appropriate default. Tell 
students to get the "picturing programs" drracket or the "Pyret" drracket, etc 
etc.
Students who have a hard time finding "choose a language" will also have 
decision confusion if given a big dialog of "find your class's preference in 
the haystack."
-Ian
- Original Message -
From: "Sam Tobin-Hochstadt" 
To: "Matthias Felleisen" 
Cc: "dev@racket-lang.org Dev" 
Sent: Monday, April 28, 2014 10:40:37 AM GMT -05:00 US/Canada Eastern
Subject: Re: [racket-dev] actionable items, was: comments on "comments on 
learning Racket"

On Mon, Apr 28, 2014 at 9:47 AM, Matthias Felleisen
 wrote:
>
>  when drracket starts w/o a preference file, we pop up a radio menu:
>
>  o Are you a student learning to program?
>  o Are you an experienced programmer learning to use Racket?
>
>  Depending on which bullet the person checks, drracket starts in
>  BSL [#lang htdp/bsl, one day soon] or #lang racket.

Another problem with this approach is that BSL is not the right choice
for many people in the first category.  They might be starting using
DMDA, or Picturing Programs, or working on their own with SICP. In all
of these cases, the language dialog needs to appear.

Sam
_
  Racket Developers list:
  http://lists.racket-lang.org/dev
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] we are suspect!

[J. Ian Johnson]

And on Earth Day, no less! For shame.
-Ian
- Original Message -
From: "Robby Findler" 
To: dev@racket-lang.org
Sent: Tuesday, April 22, 2014 2:21:03 PM GMT -05:00 US/Canada Eastern
Subject: [racket-dev] we are suspect!

>From my mac os x machine's console log.

4/22/14 1:04:44.000 PM kernel[0]: process DrRacket[32404] thread
8646879 caught burning CPU! It used more than 50% CPU (Actual recent
usage: 73%) over 180 seconds. thread lifetime cpu usage 346.323259
seconds, (330.726984 user, 15.596275 system) ledger info: balance:
90003311389 credit: 345842286824 debit: 255838975435 limit:
900 (50%) period: 1800 time since last refill (ns):
122884431728

... that's just online check syntax plus syntax coloring, afaict. :)

Robby
_
  Racket Developers list:
  http://lists.racket-lang.org/dev
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Slideshow package needs more splitting

[J. Ian Johnson]

Indeed it would.
-Ian
- Original Message -
From: Robby Findler 
To: J. Ian Johnson 
Cc: dev 
Sent: Mon, 4 Nov 2013 19:58:28 -0500 (EST)
Subject: Re: [racket-dev] Slideshow package needs more splitting

I guess probably everything except play, play-n, and animate-slide could be
split out. Would that have helped you?

Robby


On Mon, Nov 4, 2013 at 5:14 PM, J. Ian Johnson  wrote:

> Mm, I believe it's collection-level. Perhaps if play.rkt were split into
> anim.rkt and play.rkt, where anim.rkt has all the non-gui code, and
> play.rkt has the gui code. Requiring slideshow/play in my library caused
> the doc failure.
> -Ian
> - Original Message -
> From: "Robby Findler" 
> To: "J. Ian Johnson" 
> Cc: "dev" 
> Sent: Monday, November 4, 2013 5:58:36 PM GMT -05:00 US/Canada Eastern
> Subject: Re: [racket-dev] Slideshow package needs more splitting
>
>
> I think there might be some collection/pkg confusion here. Are you having
> trouble with a package level dependency or a collection level one? (The
> latter is the only kind that can lead to the documentation error you're
> talking about I believe.)
>
>
> Robby
>
>
>
> On Mon, Nov 4, 2013 at 4:51 PM, J. Ian Johnson < i...@ccs.neu.edu > wrote:
>
>
> I've been working on a package of different pict transformers/constructors
> I've made while giving slideshow presentations, with some pain.
> In particular, slideshow-lib pulls in the gui dependency, making
> documentation impossible.
> I had to just copy the code for slide-pict and fast-start from
> slideshow/play into my package, which I really hate doing.
> If at all possible, can we split the pict-only parts of slideshow-lib into
> a different collection, say slideshow-pict-lib or something? Or perhaps
> just add more to pict-pkgs?
>
> Thanks,
> -Ian
> _
> Racket Developers list:
> http://lists.racket-lang.org/dev
>
>

_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Slideshow package needs more splitting

[J. Ian Johnson]

Mm, I believe it's collection-level. Perhaps if play.rkt were split into 
anim.rkt and play.rkt, where anim.rkt has all the non-gui code, and play.rkt 
has the gui code. Requiring slideshow/play in my library caused the doc failure.
-Ian
- Original Message -
From: "Robby Findler" 
To: "J. Ian Johnson" 
Cc: "dev" 
Sent: Monday, November 4, 2013 5:58:36 PM GMT -05:00 US/Canada Eastern
Subject: Re: [racket-dev] Slideshow package needs more splitting


I think there might be some collection/pkg confusion here. Are you having 
trouble with a package level dependency or a collection level one? (The latter 
is the only kind that can lead to the documentation error you're talking about 
I believe.) 


Robby 



On Mon, Nov 4, 2013 at 4:51 PM, J. Ian Johnson < i...@ccs.neu.edu > wrote: 


I've been working on a package of different pict transformers/constructors I've 
made while giving slideshow presentations, with some pain. 
In particular, slideshow-lib pulls in the gui dependency, making documentation 
impossible. 
I had to just copy the code for slide-pict and fast-start from slideshow/play 
into my package, which I really hate doing. 
If at all possible, can we split the pict-only parts of slideshow-lib into a 
different collection, say slideshow-pict-lib or something? Or perhaps just add 
more to pict-pkgs? 

Thanks, 
-Ian 
_ 
Racket Developers list: 
http://lists.racket-lang.org/dev 

_
  Racket Developers list:
  http://lists.racket-lang.org/dev

[racket-dev] Slideshow package needs more splitting

[J. Ian Johnson]

I've been working on a package of different pict transformers/constructors I've 
made while giving slideshow presentations, with some pain.
In particular, slideshow-lib pulls in the gui dependency, making documentation 
impossible.
I had to just copy the code for slide-pict and fast-start from slideshow/play 
into my package, which I really hate doing.
If at all possible, can we split the pict-only parts of slideshow-lib into a 
different collection, say slideshow-pict-lib or something? Or perhaps just add 
more to pict-pkgs?

Thanks,
-Ian
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Generics updates

[J. Ian Johnson]

This means I can't interchange between mutable and immutable sets for my 
functions that only need to read generic sets, unless we further subdivide and 
have gen:set-query gen:set-constructor gen:set-mconstruct.

-Ian
- Original Message -
From: "Jay McCarthy" 
To: "Carl Eastlund" 
Cc: "Racket Developers" 
Sent: Wednesday, October 2, 2013 3:23:07 PM GMT -05:00 US/Canada Eastern
Subject: Re: [racket-dev] Generics updates

Regarding a point from RacketCon, I don't like that gen:set includes
functions like set-add! and set-remove!. I think that sets with
mutations are subclass of get:set and we should have a separate
gen:mset (or something) interface for mutable versions.

I dislike that an obvious implementation of sets, hash tables, are not
sets to gen:set, because there are operations that cannot be performed
on them.

I think that "X implements generic G" should imply "All functions of G
work on X". But this is not the case with gen:set and hasheq sets, for
instance.

Jay


On Tue, Jul 23, 2013 at 9:37 AM, Carl Eastlund  wrote:
> My work on adding gen:set, and related changes to define-generics and
> gen:dict, is ready for review and (hopefully) to push to the master branch.
> The branch moved in the process of cleaning things up, it's now at:
>
>   https://github.com/carl-eastlund/racket/tree/generics-from-scratch
>
> (The "from scratch" just refers to the process of rebuilding the git
> history, I didn't go out of my way to rewrite anything in the code base from
> scratch, although in some places a lot of code did move around.)
>
> What's new in the branch:
>
> - Generics now support a few new options
>   - #:fallbacks specifies fallback method implementations for instances with
> no implementation
>   - #:fast-defaults specifies instances on a "fast path", useful for
> built-in types
>   - #:defined-predicate gives a more intuitive and efficient interface than
> #:defined-table
>   - #:derive-property allows generics to piggy-back on existing struct
> properties
>
> - Sets are now a generic datatype through gen:set
>   - lists are now sets
>   - the built-in set types are now documented as "hash sets"
>   - there are mutable and weak hash sets
>   - you can define new set types quickly with define-custom-set-types
>   - most set operations are now methods with fallbacks
>   - sets now support -copy and -clear operations, plus mutating [!] versions
> of operations
>
> - Dictionaries have a few changes
>   - new macro define-custom-hash-types [*]
>   - most dict operations are now methods with fallbacks
>   - dicts now support -copy, -clear, -clear!, and -empty? operations
>
> I've run some benchmarks and performance of the various generic operations
> are comparable to the current HEAD, so there should be no major performance
> changes with this patch.
>
> [*] I've added define-custom-hash-types and define-custom-set-types rather
> than just adding make-custom-set akin to make-custom-hash because
> make-custom-hash is hard to use.  The documented behavior -- that any custom
> hash is equal to any other created with the same bindings and predicates /
> hash functions -- was never true and can be expensive or at least tricky to
> implement.  It seemed more sensible to just remove the erroneous
> documentation on make-custom-hash, and add the definition form to create
> constructors for new, explicitly-compatible dict and set types.  Both
> definition forms bind predicates and constructors for new (set or dict)
> types with immutable, mutable, and weak variants that inter-operate.
>
> If there are no serious issues brought up in the next day or two, I'll push
> it to the development branch, since our current release process isn't
> following HEAD.
>
> Carl Eastlund
>
> _
>   Racket Developers list:
>   http://lists.racket-lang.org/dev
>



-- 
Jay McCarthy 
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

"The glory of God is Intelligence" - D&C 93
_
  Racket Developers list:
  http://lists.racket-lang.org/dev
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] call-with-limits memory bound isn't actually bounding memory usage

[J. Ian Johnson]

Okay, stamourv made your response make sense. I added parameterize 
([current-namespace (make-base-namespace)]) inside the thunk, and it works. 
Albeit ''A was no longer a valid module path in #lang racket/load, it works for 
files.
What is the right way to refer to module A in racket/load, though?

Thanks,
-Ian
- Original Message -----
From: "J. Ian Johnson" 
To: "Robby Findler" 
Cc: "dev" , "J. Ian Johnson" 
Sent: Wednesday, September 11, 2013 3:49:50 PM GMT -05:00 US/Canada Eastern
Subject: Re: [racket-dev] call-with-limits memory bound isn't actually bounding 
memory usage

Just so we're clear, this should not OOM, but rather print #t?

#lang racket/load

(module A racket
 (provide global go)
 (define global '())
 (define (go) (set! global (cons (random) global)) (go)))

(module B racket
  (require racket/sandbox)
  (display
   (with-handlers ([exn:fail:resource? (λ (e)
  (case (exn:fail:resource-resource e)
[(memory) #t]
[else #f]))])
 (call-with-limits 1 512 (λ () ((dynamic-require ''A 'go)))

(require 'B)

-Ian
- Original Message -
From: "Robby Findler" 
To: "J. Ian Johnson" 
Cc: "dev" 
Sent: Wednesday, September 11, 2013 3:34:55 PM GMT -05:00 US/Canada Eastern
Subject: Re: [racket-dev] call-with-limits memory bound isn't actually bounding 
memory usage


The namespace...? 



On Wed, Sep 11, 2013 at 2:20 PM, J. Ian Johnson < i...@ccs.neu.edu > wrote: 


I've since changed to using a dynamic-require, but still the memory limit is 
not respected. Why wouldn the globals from a dynamic-require be considered 
reachable outside the sandbox that calls dynamic-require? There's no other way 
to get it. 

-Ian 
- Original Message - 


From: "J. Ian Johnson" < i...@ccs.neu.edu > 
To: "David Vanderson" < david.vander...@gmail.com > 
Cc: "dev" < dev@racket-lang.org >, "J. Ian Johnson" < i...@ccs.neu.edu > 
Sent: Monday, September 9, 2013 2:01:02 PM GMT -05:00 US/Canada Eastern 
Subject: Re: [racket-dev] call-with-limits memory bound isn't actually bounding 
memory usage 

Ah, that would probably be the problem. Without having to modify too much code, 
would the proper way to call a function entirely within the sandbox be to use 
dynamic-require in the thunk, rather than require in the module using 
call-with-limits? 
-Ian 
- Original Message - 
From: "David Vanderson" < david.vander...@gmail.com > 
To: "J. Ian Johnson" < i...@ccs.neu.edu > 
Cc: "dev" < dev@racket-lang.org > 
Sent: Monday, September 9, 2013 1:50:13 PM GMT -05:00 US/Canada Eastern 
Subject: Re: [racket-dev] call-with-limits memory bound isn't actually bounding 
memory usage 

Just to make sure, is the memory being allocated reachable from outside 
the sandbox? 

http://www.cs.utah.edu/plt/publications/ismm04-addendum.txt 

On 09/09/2013 01:29 PM, J. Ian Johnson wrote: 
> I don't use the gui framework at all. This is all just pounding on global 
> hash-tables and vectors. Or are you talking about the sandbox queuing up 
> callbacks? 
> -Ian 
> - Original Message - 
> From: "Robby Findler" < ro...@eecs.northwestern.edu > 
> To: "J. Ian Johnson" < i...@ccs.neu.edu > 
> Cc: "dev" < dev@racket-lang.org > 
> Sent: Monday, September 9, 2013 1:16:51 PM GMT -05:00 US/Canada Eastern 
> Subject: Re: [racket-dev] call-with-limits memory bound isn't actually 
> bounding memory usage 
> 
> 
> The framework will, sometimes do stuff that queues callbacks and, depending 
> on how you've set up other things, the code running there might escape from 
> the limit. Did you try putting the eventspace under the limit too? 
> 
> Robby 
> 
> 
> 
> On Mon, Sep 9, 2013 at 10:54 AM, J. Ian Johnson < i...@ccs.neu.edu > wrote: 
> 
> 
> I'm running my analysis benchmarks in the context of (with-limits (* 30 60) 
> 2048 ), and it's been good at killing the process when the run 
> should time out, but now I have an instantiation of the framework that just 
> gobbles up 15GiB of memory without getting killed. What might be going on 
> here? 
> 
> Running 5.90.0.9 
> -Ian 
> _ 
> Racket Developers list: 
> http://lists.racket-lang.org/dev 
> 
> _ 
> Racket Developers list: 
> http://lists.racket-lang.org/dev 
> 

_ 
Racket Developers list: 
http://lists.racket-lang.org/dev 


_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] call-with-limits memory bound isn't actually bounding memory usage

[J. Ian Johnson]

Just so we're clear, this should not OOM, but rather print #t?

#lang racket/load

(module A racket
 (provide global go)
 (define global '())
 (define (go) (set! global (cons (random) global)) (go)))

(module B racket
  (require racket/sandbox)
  (display
   (with-handlers ([exn:fail:resource? (λ (e)
  (case (exn:fail:resource-resource e)
[(memory) #t]
[else #f]))])
 (call-with-limits 1 512 (λ () ((dynamic-require ''A 'go)))

(require 'B)

-Ian
- Original Message -
From: "Robby Findler" 
To: "J. Ian Johnson" 
Cc: "dev" 
Sent: Wednesday, September 11, 2013 3:34:55 PM GMT -05:00 US/Canada Eastern
Subject: Re: [racket-dev] call-with-limits memory bound isn't actually bounding 
memory usage


The namespace...? 



On Wed, Sep 11, 2013 at 2:20 PM, J. Ian Johnson < i...@ccs.neu.edu > wrote: 


I've since changed to using a dynamic-require, but still the memory limit is 
not respected. Why wouldn the globals from a dynamic-require be considered 
reachable outside the sandbox that calls dynamic-require? There's no other way 
to get it. 

-Ian 
- Original Message - 


From: "J. Ian Johnson" < i...@ccs.neu.edu > 
To: "David Vanderson" < david.vander...@gmail.com > 
Cc: "dev" < dev@racket-lang.org >, "J. Ian Johnson" < i...@ccs.neu.edu > 
Sent: Monday, September 9, 2013 2:01:02 PM GMT -05:00 US/Canada Eastern 
Subject: Re: [racket-dev] call-with-limits memory bound isn't actually bounding 
memory usage 

Ah, that would probably be the problem. Without having to modify too much code, 
would the proper way to call a function entirely within the sandbox be to use 
dynamic-require in the thunk, rather than require in the module using 
call-with-limits? 
-Ian 
- Original Message - 
From: "David Vanderson" < david.vander...@gmail.com > 
To: "J. Ian Johnson" < i...@ccs.neu.edu > 
Cc: "dev" < dev@racket-lang.org > 
Sent: Monday, September 9, 2013 1:50:13 PM GMT -05:00 US/Canada Eastern 
Subject: Re: [racket-dev] call-with-limits memory bound isn't actually bounding 
memory usage 

Just to make sure, is the memory being allocated reachable from outside 
the sandbox? 

http://www.cs.utah.edu/plt/publications/ismm04-addendum.txt 

On 09/09/2013 01:29 PM, J. Ian Johnson wrote: 
> I don't use the gui framework at all. This is all just pounding on global 
> hash-tables and vectors. Or are you talking about the sandbox queuing up 
> callbacks? 
> -Ian 
> - Original Message - 
> From: "Robby Findler" < ro...@eecs.northwestern.edu > 
> To: "J. Ian Johnson" < i...@ccs.neu.edu > 
> Cc: "dev" < dev@racket-lang.org > 
> Sent: Monday, September 9, 2013 1:16:51 PM GMT -05:00 US/Canada Eastern 
> Subject: Re: [racket-dev] call-with-limits memory bound isn't actually 
> bounding memory usage 
> 
> 
> The framework will, sometimes do stuff that queues callbacks and, depending 
> on how you've set up other things, the code running there might escape from 
> the limit. Did you try putting the eventspace under the limit too? 
> 
> Robby 
> 
> 
> 
> On Mon, Sep 9, 2013 at 10:54 AM, J. Ian Johnson < i...@ccs.neu.edu > wrote: 
> 
> 
> I'm running my analysis benchmarks in the context of (with-limits (* 30 60) 
> 2048 ), and it's been good at killing the process when the run 
> should time out, but now I have an instantiation of the framework that just 
> gobbles up 15GiB of memory without getting killed. What might be going on 
> here? 
> 
> Running 5.90.0.9 
> -Ian 
> _ 
> Racket Developers list: 
> http://lists.racket-lang.org/dev 
> 
> _ 
> Racket Developers list: 
> http://lists.racket-lang.org/dev 
> 

_ 
Racket Developers list: 
http://lists.racket-lang.org/dev 


_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] call-with-limits memory bound isn't actually bounding memory usage

[J. Ian Johnson]

I've since changed to using a dynamic-require, but still the memory limit is 
not respected. Why wouldn the globals from a dynamic-require be considered 
reachable outside the sandbox that calls dynamic-require? There's no other way 
to get it.
-Ian
- Original Message -----
From: "J. Ian Johnson" 
To: "David Vanderson" 
Cc: "dev" , "J. Ian Johnson" 
Sent: Monday, September 9, 2013 2:01:02 PM GMT -05:00 US/Canada Eastern
Subject: Re: [racket-dev] call-with-limits memory bound isn't actually bounding 
memory usage

Ah, that would probably be the problem. Without having to modify too much code, 
would the proper way to call a function entirely within the sandbox be to use 
dynamic-require in the thunk, rather than require in the module using 
call-with-limits?
-Ian
- Original Message -
From: "David Vanderson" 
To: "J. Ian Johnson" 
Cc: "dev" 
Sent: Monday, September 9, 2013 1:50:13 PM GMT -05:00 US/Canada Eastern
Subject: Re: [racket-dev] call-with-limits memory bound isn't actually bounding 
memory usage

Just to make sure, is the memory being allocated reachable from outside 
the sandbox?

http://www.cs.utah.edu/plt/publications/ismm04-addendum.txt

On 09/09/2013 01:29 PM, J. Ian Johnson wrote:
> I don't use the gui framework at all. This is all just pounding on global 
> hash-tables and vectors. Or are you talking about the sandbox queuing up 
> callbacks?
> -Ian
> - Original Message -
> From: "Robby Findler" 
> To: "J. Ian Johnson" 
> Cc: "dev" 
> Sent: Monday, September 9, 2013 1:16:51 PM GMT -05:00 US/Canada Eastern
> Subject: Re: [racket-dev] call-with-limits memory bound isn't actually 
> bounding memory usage
>
>
> The framework will, sometimes do stuff that queues callbacks and, depending 
> on how you've set up other things, the code running there might escape from 
> the limit. Did you try putting the eventspace under the limit too?
>
> Robby
>
>
>
> On Mon, Sep 9, 2013 at 10:54 AM, J. Ian Johnson < i...@ccs.neu.edu > wrote:
>
>
> I'm running my analysis benchmarks in the context of (with-limits (* 30 60) 
> 2048 ), and it's been good at killing the process when the run 
> should time out, but now I have an instantiation of the framework that just 
> gobbles up 15GiB of memory without getting killed. What might be going on 
> here?
>
> Running 5.90.0.9
> -Ian
> _
> Racket Developers list:
> http://lists.racket-lang.org/dev
>
> _
>Racket Developers list:
>http://lists.racket-lang.org/dev
>

_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] call-with-limits memory bound isn't actually bounding memory usage

[J. Ian Johnson]

I don't use the gui framework at all. This is all just pounding on global 
hash-tables and vectors. Or are you talking about the sandbox queuing up 
callbacks?
-Ian
- Original Message -
From: "Robby Findler" 
To: "J. Ian Johnson" 
Cc: "dev" 
Sent: Monday, September 9, 2013 1:16:51 PM GMT -05:00 US/Canada Eastern
Subject: Re: [racket-dev] call-with-limits memory bound isn't actually bounding 
memory usage


The framework will, sometimes do stuff that queues callbacks and, depending on 
how you've set up other things, the code running there might escape from the 
limit. Did you try putting the eventspace under the limit too? 

Robby 



On Mon, Sep 9, 2013 at 10:54 AM, J. Ian Johnson < i...@ccs.neu.edu > wrote: 


I'm running my analysis benchmarks in the context of (with-limits (* 30 60) 
2048 ), and it's been good at killing the process when the run 
should time out, but now I have an instantiation of the framework that just 
gobbles up 15GiB of memory without getting killed. What might be going on here? 

Running 5.90.0.9 
-Ian 
_ 
Racket Developers list: 
http://lists.racket-lang.org/dev 

_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] call-with-limits memory bound isn't actually bounding memory usage

[J. Ian Johnson]

Ah, that would probably be the problem. Without having to modify too much code, 
would the proper way to call a function entirely within the sandbox be to use 
dynamic-require in the thunk, rather than require in the module using 
call-with-limits?
-Ian
- Original Message -
From: "David Vanderson" 
To: "J. Ian Johnson" 
Cc: "dev" 
Sent: Monday, September 9, 2013 1:50:13 PM GMT -05:00 US/Canada Eastern
Subject: Re: [racket-dev] call-with-limits memory bound isn't actually bounding 
memory usage

Just to make sure, is the memory being allocated reachable from outside 
the sandbox?

http://www.cs.utah.edu/plt/publications/ismm04-addendum.txt

On 09/09/2013 01:29 PM, J. Ian Johnson wrote:
> I don't use the gui framework at all. This is all just pounding on global 
> hash-tables and vectors. Or are you talking about the sandbox queuing up 
> callbacks?
> -Ian
> - Original Message -
> From: "Robby Findler" 
> To: "J. Ian Johnson" 
> Cc: "dev" 
> Sent: Monday, September 9, 2013 1:16:51 PM GMT -05:00 US/Canada Eastern
> Subject: Re: [racket-dev] call-with-limits memory bound isn't actually 
> bounding memory usage
>
>
> The framework will, sometimes do stuff that queues callbacks and, depending 
> on how you've set up other things, the code running there might escape from 
> the limit. Did you try putting the eventspace under the limit too?
>
> Robby
>
>
>
> On Mon, Sep 9, 2013 at 10:54 AM, J. Ian Johnson < i...@ccs.neu.edu > wrote:
>
>
> I'm running my analysis benchmarks in the context of (with-limits (* 30 60) 
> 2048 ), and it's been good at killing the process when the run 
> should time out, but now I have an instantiation of the framework that just 
> gobbles up 15GiB of memory without getting killed. What might be going on 
> here?
>
> Running 5.90.0.9
> -Ian
> _
> Racket Developers list:
> http://lists.racket-lang.org/dev
>
> _
>Racket Developers list:
>http://lists.racket-lang.org/dev
>

_
  Racket Developers list:
  http://lists.racket-lang.org/dev

[racket-dev] call-with-limits memory bound isn't actually bounding memory usage

[J. Ian Johnson]

I'm running my analysis benchmarks in the context of (with-limits (* 30 60) 
2048 ), and it's been good at killing the process when the run 
should time out, but now I have an instantiation of the framework that just 
gobbles up 15GiB of memory without getting killed. What might be going on here?

Running 5.90.0.9
-Ian
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] call-with-limits memory bound isn't actually bounding memory usage

[J. Ian Johnson]

I changed it to (call-with-limits (* 30 60) 2048 (lambda () )) 
for a sanity check, which I thought with-limits was just a macro for. Same 
problem. The execution takes at least 20 seconds to get to 15GiB, so it can't 
be just that GC isn't running in order for the custodian to notice the usage 
over the limit.
-Ian
- Original Message -
From: "Carl Eastlund" 
To: "J. Ian Johnson" 
Cc: "dev" 
Sent: Monday, September 9, 2013 12:05:21 PM GMT -05:00 US/Canada Eastern
Subject: Re: [racket-dev] call-with-limits memory bound isn't actually bounding 
memory usage



Does  have the form (lambda () )? Because 
if not, that's the problem. 

Carl Eastlund 

-- 
WARNING! Poorly-typed cell phone email precedes. 
On Sep 9, 2013 11:55 AM, "J. Ian Johnson" < i...@ccs.neu.edu > wrote: 


I'm running my analysis benchmarks in the context of (with-limits (* 30 60) 
2048 ), and it's been good at killing the process when the run 
should time out, but now I have an instantiation of the framework that just 
gobbles up 15GiB of memory without getting killed. What might be going on here? 

Running 5.90.0.9 
-Ian 
_ 
Racket Developers list: 
http://lists.racket-lang.org/dev 

_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Output value of program changes depending on whether I pretty-print an opaque struct value

[J. Ian Johnson]

I determined this morning that the cause was a bad hash code for my generic 
hashes/sets. I use an injection from the value space into the natural numbers 
by assigning atoms prime numbers (thanks math/number-theory for next-prime!), 
and I multiply them together to produce the encoding of sets (I check 
divisibility before multiplying, so I always have a <=1 multiplicity). I use 
Cantor's injection for producing the number of pairs, so I can make a set of 
pairs encode finite functions (hashes). The result should be that equal numbers 
imply equal values, so I hashed on the numbers for hash-proc and hash2-proc 
instead of the values. I still compare equality only using the numbers since 
it's 3 orders of magnitude faster. I changed the hash-proc to hash on the 
values instead and got consistent results for the analysis. I'm perplexed by 
this, so I'm trying to write a smaller example that demonstrates the problem.

I only use hasheq for seen checks when traversing through a hash that has 
circular references, and I never change the hash during these traversals, and 
the result is a set. The order doesn't matter. I also changed all hasheqs in my 
code to hashes to see if that was a problem. It wasn't.

-Ian
- Original Message -----
From: "Carl Eastlund" 
To: "J. Ian Johnson" 
Cc: "Matthew Flatt" , "dev" 
Sent: Wednesday, August 28, 2013 12:34:08 PM GMT -05:00 US/Canada Eastern
Subject: Re: [racket-dev] Output value of program changes depending on whether 
I pretty-print an opaque struct value


Is it possible your analysis is depending on the order of graph traversal? That 
is, do you ever use in-hash on the hasheq, and if so is it possible the results 
of your analysis would change if in-hash produced hash table entries in a 
different order? Same for in-hash-keys or in-hash-values, obviously. 



Carl Eastlund 


On Tue, Aug 27, 2013 at 6:58 PM, J. Ian Johnson < i...@ccs.neu.edu > wrote: 


Weird you can't repro. 
I only use hasheq when I know the keys are symbols, or the table is local and 
only used for a graph traversal (where the graph is not changing during 
traversal). 
-Ian 


----- Original Message - 
From: "Matthew Flatt" < mfl...@cs.utah.edu > 
To: "J. Ian Johnson" < i...@ccs.neu.edu > 
Cc: "dev" < dev@racket-lang.org > 
Sent: Tuesday, August 27, 2013 6:33:02 PM GMT -05:00 US/Canada Eastern 
Subject: Re: [racket-dev] Output value of program changes depending on whether 
I pretty-print an opaque struct value 

I haven't been able to get a different result by changing printing. 

One thing that printing might do, however, is assign `eq?`-based hash 
codes to objects that did not already have them. That assignment, in 
turn, could affect the order in which objects appear later in a hash 
table. 

I hacked Racket to make the internal hash-code generator count down 
instead of up, and I was able to get a different result that way. 

Are you using `eq?`-based hashing at all? Could there be some 
dependency on the order of values within a hash table (or hash set)? 

At Tue, 27 Aug 2013 14:02:50 -0400 (EDT), "J. Ian Johnson" wrote: 
> This is mostly an mflatt-only problem. 
> 
> My analysis framework is now using a generic dictionary for its abstract 
> heap, 
> and depending on whether or not I pretty-print this heap before continuing on 
> analyzing, the result of the analysis changes (sound versus unsound). I found 
> the problem doing some printf debugging, and when fixed, I tried removing the 
> print statements. The answer changed. There must be some problem in the C 
> code 
> somewhere, because this is just bonkers. 
> 
> (Note: I've had previous bugs where rewriting a (begin (void) e) => e caused 
> a 
> similar value-changing bug. Updating the compiler to head fixed it at that 
> point. I'm running yesterday's HEAD now, though.) 
> 
> https://github.com/dvanhorn/oaam/tree/thocon 
> 
> See the ;; mflatt: comment in code/kcfa.rkt 
> 
> To see the problem, 
> racket code/run-benchmark.rkt --lcg benchmarks/temp-c/sort2.sch 
> 
> Thanks, 
> -Ian 
> _ 
> Racket Developers list: 
> http://lists.racket-lang.org/dev 
_ 
Racket Developers list: 
http://lists.racket-lang.org/dev 

_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Output value of program changes depending on whether I pretty-print an opaque struct value

[J. Ian Johnson]

Weird you can't repro.
I only use hasheq when I know the keys are symbols, or the table is local and 
only used for a graph traversal (where the graph is not changing during 
traversal).
-Ian
- Original Message -
From: "Matthew Flatt" 
To: "J. Ian Johnson" 
Cc: "dev" 
Sent: Tuesday, August 27, 2013 6:33:02 PM GMT -05:00 US/Canada Eastern
Subject: Re: [racket-dev] Output value of program changes depending on whether 
I pretty-print an opaque struct value

I haven't been able to get a different result by changing printing.

One thing that printing might do, however, is assign `eq?`-based hash
codes to objects that did not already have them. That assignment, in
turn, could affect the order in which objects appear later in a hash
table.

I hacked Racket to make the internal hash-code generator count down
instead of up, and I was able to get a different result that way.

Are you using `eq?`-based hashing at all? Could there be some
dependency on the order of values within a hash table (or hash set)?

At Tue, 27 Aug 2013 14:02:50 -0400 (EDT), "J. Ian Johnson" wrote:
> This is mostly an mflatt-only problem.
> 
> My analysis framework is now using a generic dictionary for its abstract 
> heap, 
> and depending on whether or not I pretty-print this heap before continuing on 
> analyzing, the result of the analysis changes (sound versus unsound). I found 
> the problem doing some printf debugging, and when fixed, I tried removing the 
> print statements. The answer changed. There must be some problem in the C 
> code 
> somewhere, because this is just bonkers.
> 
> (Note: I've had previous bugs where rewriting a (begin (void) e) => e caused 
> a 
> similar value-changing bug. Updating the compiler to head fixed it at that 
> point. I'm running yesterday's HEAD now, though.)
> 
> https://github.com/dvanhorn/oaam/tree/thocon
> 
> See the ;; mflatt: comment in code/kcfa.rkt
> 
> To see the problem,
> racket code/run-benchmark.rkt --lcg benchmarks/temp-c/sort2.sch
> 
> Thanks,
> -Ian
> _
>   Racket Developers list:
>   http://lists.racket-lang.org/dev
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

[racket-dev] Output value of program changes depending on whether I pretty-print an opaque struct value

[J. Ian Johnson]

This is mostly an mflatt-only problem.

My analysis framework is now using a generic dictionary for its abstract heap, 
and depending on whether or not I pretty-print this heap before continuing on 
analyzing, the result of the analysis changes (sound versus unsound). I found 
the problem doing some printf debugging, and when fixed, I tried removing the 
print statements. The answer changed. There must be some problem in the C code 
somewhere, because this is just bonkers.

(Note: I've had previous bugs where rewriting a (begin (void) e) => e caused a 
similar value-changing bug. Updating the compiler to head fixed it at that 
point. I'm running yesterday's HEAD now, though.)

https://github.com/dvanhorn/oaam/tree/thocon

See the ;; mflatt: comment in code/kcfa.rkt

To see the problem,
racket code/run-benchmark.rkt --lcg benchmarks/temp-c/sort2.sch

Thanks,
-Ian
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Lists aren't sets, but have set-like operations

[J. Ian Johnson]

I like this, except now the hash sets have too little exposed. There isn't a 
special sequence-syntax that I can get a hold of for faster iteration when I 
know the type of data I'm working with.
-Ian
- Original Message -
From: "Matthias Felleisen" 
To: "Carl Eastlund" 
Cc: "J. Ian Johnson" , "Racket Developers" 

Sent: Thursday, August 22, 2013 2:47:44 PM GMT -05:00 US/Canada Eastern
Subject: Re: [racket-dev] Lists aren't sets, but have set-like operations




On Aug 22, 2013, at 2:31 PM, Carl Eastlund wrote: 





Here's what I propose to do now: 

- rename set? to generic-set?; this predicate recognizes the new all-inclusive 
generic set type 

- rename set-immutable? to set?; this predicate recognizes the pre-existing 
immutable hash set type 

- leave set-mutable? and set-weak? alone; they recognize the other two hash set 
types (on the mutability axis) 

- allow multiple-set operations to combine equal-based hash sets and lists, 
since both use equal? for equality 




Sounds like the right direction to me. -- Matthias 

_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] generic binding forms

[J. Ian Johnson]

I've been wanting a match-for for quite some time, but there are design 
decisions to be made in such cases. Non-linear patterns are tricky to 
coordinate - should all clauses of a for/fold be considered part of the same 
match pattern? How about for*/fold? (My opinions are yes then no). If you have 
several binding forms that would work together in this way, and not just match 
patterns, then what is the proper way to set up and interact with such scopes? 
Do we need something as involved as an internal definition context?

I'll take a closer look at your repo when I come into the lab today.
-Ian
- Original Message -
From: "Jay McCarthy" 
To: "Stephen Chang" 
Cc: "dev" 
Sent: Monday, August 26, 2013 8:27:06 AM GMT -05:00 US/Canada Eastern
Subject: Re: [racket-dev] generic binding forms

On Sun, Aug 25, 2013 at 10:54 PM, Stephen Chang  wrote:
> Hi dev,
>
> I've noticed that Racket has a lot of convenient binding forms but
> they don't fit together unless someone does it manually (for example
> there's match-let and match-let-values, but no match-for).
>
> As an educational side project, I've been toying around with a
> different way of organizing all the binding forms. What I wanted to do
> is remove the need to manually combine current (and future) binding
> forms by moving the binding "logic" to the binding site itself.
>
> Inspired by the in-vogue generics movement in the Racket world, I've
> hacked together a sort of "generic interface" for bindings (in
> reality, it's just a bunch of syntax properties right now), and
> implemented alternate versions of some of the main binding forms that
> support "instances" of these generic bindings.
>
> To illustrate, here are some test cases for a generic define I
> implemented (~define). I also implemented binding "instances" for
> match and values (which I arbitrarily named $ and ~v below) and I can
> use these forms in (mostly) any binding position that supports generic
> bindings.
>
> ;; functions
>> (~define (f1 x y) (+ x y))
>> (f1 10 20)
> 30
>> (~define (f2 ($ (list x y))) (+ x y))
>> (f2 (list 10 20))
> 30
>
> ;; non-functions
>> (~define a1 100)
>> a1
> 100
>> (~define (~v a2 a3) (values 134 456))
>> a2
> 134
>> a3
> 456
>
> You can nest bind instances too:
>
>> (~define (~v ($ (list b1 b2)) b3) (values (list 22 33) 44))
>> b1
> 22
>> b2
> 33
>> b3
> 44
>
> Does anyone think this is useful? Or is it just a lot of work to save
> a little bit of typing? Has anyone tried something like this before?
>
> It's still very much a work in progress but I figure I would ask for
> some feedback earlier rather than too later, in case there is
> something that makes this infeasible.
>
> Brave souls can look at the hackery here:
> https://github.com/stchang/generic-bind/blob/master/generic-bind.rkt
> (Warning: I'm still trying to figure out all the toys in the Racket
> macro toolbox. For the most part, everything still looks like a
> syntax-rule/case/parse/->datum nail to my hammer.)
>
> Technical question: I couldn't figure out a nice way to implement
> ~let. Essentially, I want a let form where some clauses are let-values
> and some are match-let, but I need to bind them all at the same time,
> like let.

I'd introduce new names to bind them in sequence and then rename
everything after it's all available. My letwreck does something
similar:

http://jeapostrophe.github.io/2013-08-05-letwreck-post.html#%28elem._%28chunk._~3cletwreck-defn~3e~3a1%29%29

> I can't define a ~lambda that works with values because
> functions in racket can't receive values. Anyone have any ideas?
>
> Side observation: Trying to get things to work with multiple return
> values was a pain because they don't compose (as in, functions can
> produce them but can't receive them). Not sure if anything can be done
> about this though.
> _
>   Racket Developers list:
>   http://lists.racket-lang.org/dev



-- 
Jay McCarthy 
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

"The glory of God is Intelligence" - D&C 93
_
  Racket Developers list:
  http://lists.racket-lang.org/dev
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Lists aren't sets, but have set-like operations

[J. Ian Johnson]

No, it doesn't seem to be using the fallback in this case. 

ianj@sampson:~/racket/racket/bin$ ./racket -il xrepl
Welcome to Racket v5.90.0.8.
-> (set-union '() (set))
; in-list: contract violation
;   expected: list?
;   given: (set)
; [,bt for context]
-> 

-Ian
- Original Message -
From: "Sam Tobin-Hochstadt" 
To: "J. Ian Johnson" , "Carl Eastlund" 
Cc: dev@racket-lang.org, "Matthew Flatt" 
Sent: Thursday, August 22, 2013 8:51:30 AM GMT -05:00 US/Canada Eastern
Subject: Re: [racket-dev] Lists aren't sets, but have set-like operations

Wait, `set-union` of two different set representations doesn't work?

Sam

On Thu, Aug 22, 2013 at 8:07 AM, J. Ian Johnson  wrote:
> You misunderstand. I used set-union, but single dispatch saw '() and used 
> list-union for the '() (set) combination.
> -Ian
> - Original Message -
> From: "Sam Tobin-Hochstadt" 
> To: "J. Ian Johnson" 
> Cc: dev@racket-lang.org, "Matthew Flatt" 
> Sent: Thursday, August 22, 2013 8:02:50 AM GMT -05:00 US/Canada Eastern
> Subject: Re: [racket-dev] Lists aren't sets, but have set-like operations
>
>
>
> But 'list-union' is not a generic operation so it isn't surprising that this 
> didn't work. To do this generically, you'd need to use 'set-union'.
>
> Sam
> On Aug 22, 2013 7:59 AM, "J. Ian Johnson" < i...@ccs.neu.edu > wrote:
>
>
> The problem manifested itself when I got an exception that in-list can't be 
> called on (set), which really confused me. (set? '()) answered true, so it 
> tried to do (list-union '() (set)), which failed.
> Generic sets as they are don't work generically. Some action should be taken. 
> Either set? means what it once did, or we do some awfully slow multiple 
> dispatch for set operations. My bias shows.
> -Ian
> - Original Message -
> From: "Matthew Flatt" < mfl...@cs.utah.edu >
> To: "Carl Eastlund" < c...@ccs.neu.edu >
> Cc: "J. Ian Johnson" < i...@ccs.neu.edu >, "dev" < dev@racket-lang.org >
> Sent: Thursday, August 22, 2013 7:22:25 AM GMT -05:00 US/Canada Eastern
> Subject: Re: [racket-dev] Lists aren't sets, but have set-like operations
>
> How much should we prioritize backward compatibility in this case?
>
> One possibility is to make `set?' mean `hash-set?', and add
> `generic-set?' in place of the current `set?'. That's uglier,
> obviously, but it would be better if we want to prioritize backward
> compatibility.
>
> At Wed, 21 Aug 2013 19:14:06 -0400, Carl Eastlund wrote:
>> Ah, yes. The set? predicate no longer distinguishes a representation.
>> There are several predicates for the original set type, now called "hash
>> sets": set-eq?, set-eqv?, set-equal?, set-mutable?, set-immtuable?, and
>> set-weak?. I didn't add the basic "hash-set?", but perhaps I should. It's
>> a weird name, since "hash-set" and "hash-set!" are already existing,
>> unrelated functions.
>>
>> Carl Eastlund
>>
>>
>> On Wed, Aug 21, 2013 at 7:08 PM, J. Ian Johnson < i...@ccs.neu.edu > wrote:
>>
>> > Okay, I can abide. However, that doesn't really get at my frustration. I'm
>> > using the set constructor, that appears to now be an immutable-custom-set
>> > with make-immutable-hash as its make-table. So what I'm looking for is not
>> > set?, but set-immutable?, as it's a distinct (family of) struct types that
>> > won't clash with the primitive data that I'm otherwise using.
>> > -Ian
>> > ----- Original Message -
>> > From: "Carl Eastlund" < c...@ccs.neu.edu >
>> > To: "J. Ian Johnson" < i...@ccs.neu.edu >
>> > Cc: "dev" < dev@racket-lang.org >
>> > Sent: Wednesday, August 21, 2013 6:58:56 PM GMT -05:00 US/Canada Eastern
>> > Subject: Re: [racket-dev] Lists aren't sets, but have set-like operations
>> >
>> >
>> > Ian, sets are now a generic datatype, like dictionaries. Association lists
>> > are dictionaries, and lists are now sets. They're also streams and
>> > sequences. They're not just "set-like".
>> >
>> >
>> >
>> > Carl Eastlund
>> >
>> >
>> > On Wed, Aug 21, 2013 at 6:56 PM, J. Ian Johnson < i...@ccs.neu.edu >
>> > wrote:
>> >
>> >
>> > I just wasted about 2 hours tracking down a bug that ended up being due to
>> > (set? '()) now evaluating to #t. I have no problems with set-union,
>> > intersection, etc. being defined for lists, but to treat lists as sets
>> > always is perverse to me. The contracts for set operations should use
>> > set-like? for (or/c set? list?) and keep the two constructions separate.
>> >
>> > This conflation is almost as bad as treating empty list as false.
>> >
>> > -Ian
>> > _
>> > Racket Developers list:
>> > http://lists.racket-lang.org/dev
>> >
>> >
>> >
>> >
>> _
>> Racket Developers list:
>> http://lists.racket-lang.org/dev
> _
> Racket Developers list:
> http://lists.racket-lang.org/dev
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Lists aren't sets, but have set-like operations

[J. Ian Johnson]

You misunderstand. I used set-union, but single dispatch saw '() and used 
list-union for the '() (set) combination.
-Ian
- Original Message -
From: "Sam Tobin-Hochstadt" 
To: "J. Ian Johnson" 
Cc: dev@racket-lang.org, "Matthew Flatt" 
Sent: Thursday, August 22, 2013 8:02:50 AM GMT -05:00 US/Canada Eastern
Subject: Re: [racket-dev] Lists aren't sets, but have set-like operations



But 'list-union' is not a generic operation so it isn't surprising that this 
didn't work. To do this generically, you'd need to use 'set-union'. 

Sam 
On Aug 22, 2013 7:59 AM, "J. Ian Johnson" < i...@ccs.neu.edu > wrote: 


The problem manifested itself when I got an exception that in-list can't be 
called on (set), which really confused me. (set? '()) answered true, so it 
tried to do (list-union '() (set)), which failed. 
Generic sets as they are don't work generically. Some action should be taken. 
Either set? means what it once did, or we do some awfully slow multiple 
dispatch for set operations. My bias shows. 
-Ian 
- Original Message - 
From: "Matthew Flatt" < mfl...@cs.utah.edu > 
To: "Carl Eastlund" < c...@ccs.neu.edu > 
Cc: "J. Ian Johnson" < i...@ccs.neu.edu >, "dev" < dev@racket-lang.org > 
Sent: Thursday, August 22, 2013 7:22:25 AM GMT -05:00 US/Canada Eastern 
Subject: Re: [racket-dev] Lists aren't sets, but have set-like operations 

How much should we prioritize backward compatibility in this case? 

One possibility is to make `set?' mean `hash-set?', and add 
`generic-set?' in place of the current `set?'. That's uglier, 
obviously, but it would be better if we want to prioritize backward 
compatibility. 

At Wed, 21 Aug 2013 19:14:06 -0400, Carl Eastlund wrote: 
> Ah, yes. The set? predicate no longer distinguishes a representation. 
> There are several predicates for the original set type, now called "hash 
> sets": set-eq?, set-eqv?, set-equal?, set-mutable?, set-immtuable?, and 
> set-weak?. I didn't add the basic "hash-set?", but perhaps I should. It's 
> a weird name, since "hash-set" and "hash-set!" are already existing, 
> unrelated functions. 
> 
> Carl Eastlund 
> 
> 
> On Wed, Aug 21, 2013 at 7:08 PM, J. Ian Johnson < i...@ccs.neu.edu > wrote: 
> 
> > Okay, I can abide. However, that doesn't really get at my frustration. I'm 
> > using the set constructor, that appears to now be an immutable-custom-set 
> > with make-immutable-hash as its make-table. So what I'm looking for is not 
> > set?, but set-immutable?, as it's a distinct (family of) struct types that 
> > won't clash with the primitive data that I'm otherwise using. 
> > -Ian 
> > - Original Message - 
> > From: "Carl Eastlund" < c...@ccs.neu.edu > 
> > To: "J. Ian Johnson" < i...@ccs.neu.edu > 
> > Cc: "dev" < dev@racket-lang.org > 
> > Sent: Wednesday, August 21, 2013 6:58:56 PM GMT -05:00 US/Canada Eastern 
> > Subject: Re: [racket-dev] Lists aren't sets, but have set-like operations 
> > 
> > 
> > Ian, sets are now a generic datatype, like dictionaries. Association lists 
> > are dictionaries, and lists are now sets. They're also streams and 
> > sequences. They're not just "set-like". 
> > 
> > 
> > 
> > Carl Eastlund 
> > 
> > 
> > On Wed, Aug 21, 2013 at 6:56 PM, J. Ian Johnson < i...@ccs.neu.edu > 
> > wrote: 
> > 
> > 
> > I just wasted about 2 hours tracking down a bug that ended up being due to 
> > (set? '()) now evaluating to #t. I have no problems with set-union, 
> > intersection, etc. being defined for lists, but to treat lists as sets 
> > always is perverse to me. The contracts for set operations should use 
> > set-like? for (or/c set? list?) and keep the two constructions separate. 
> > 
> > This conflation is almost as bad as treating empty list as false. 
> > 
> > -Ian 
> > _ 
> > Racket Developers list: 
> > http://lists.racket-lang.org/dev 
> > 
> > 
> > 
> > 
> _ 
> Racket Developers list: 
> http://lists.racket-lang.org/dev 
_ 
Racket Developers list: 
http://lists.racket-lang.org/dev 
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Lists aren't sets, but have set-like operations

[J. Ian Johnson]

The problem manifested itself when I got an exception that in-list can't be 
called on (set), which really confused me. (set? '()) answered true, so it 
tried to do (list-union '() (set)), which failed.
Generic sets as they are don't work generically. Some action should be taken. 
Either set? means what it once did, or we do some awfully slow multiple 
dispatch for set operations. My bias shows.
-Ian
- Original Message -
From: "Matthew Flatt" 
To: "Carl Eastlund" 
Cc: "J. Ian Johnson" , "dev" 
Sent: Thursday, August 22, 2013 7:22:25 AM GMT -05:00 US/Canada Eastern
Subject: Re: [racket-dev] Lists aren't sets, but have set-like operations

How much should we prioritize backward compatibility in this case?

One possibility is to make `set?' mean `hash-set?', and add
`generic-set?' in place of the current `set?'. That's uglier,
obviously, but it would be better if we want to prioritize backward
compatibility.

At Wed, 21 Aug 2013 19:14:06 -0400, Carl Eastlund wrote:
> Ah, yes.  The set? predicate no longer distinguishes a representation.
> There are several predicates for the original set type, now called "hash
> sets": set-eq?, set-eqv?, set-equal?, set-mutable?, set-immtuable?, and
> set-weak?.  I didn't add the basic "hash-set?", but perhaps I should.  It's
> a weird name, since "hash-set" and "hash-set!" are already existing,
> unrelated functions.
> 
> Carl Eastlund
> 
> 
> On Wed, Aug 21, 2013 at 7:08 PM, J. Ian Johnson  wrote:
> 
> > Okay, I can abide. However, that doesn't really get at my frustration. I'm
> > using the set constructor, that appears to now be an immutable-custom-set
> > with make-immutable-hash as its make-table. So what I'm looking for is not
> > set?, but set-immutable?, as it's a distinct (family of) struct types that
> > won't clash with the primitive data that I'm otherwise using.
> > -Ian
> > - Original Message -
> > From: "Carl Eastlund" 
> > To: "J. Ian Johnson" 
> > Cc: "dev" 
> > Sent: Wednesday, August 21, 2013 6:58:56 PM GMT -05:00 US/Canada Eastern
> > Subject: Re: [racket-dev] Lists aren't sets, but have set-like operations
> >
> >
> > Ian, sets are now a generic datatype, like dictionaries. Association lists
> > are dictionaries, and lists are now sets. They're also streams and
> > sequences. They're not just "set-like".
> >
> >
> >
> > Carl Eastlund
> >
> >
> > On Wed, Aug 21, 2013 at 6:56 PM, J. Ian Johnson < i...@ccs.neu.edu >
> > wrote:
> >
> >
> > I just wasted about 2 hours tracking down a bug that ended up being due to
> > (set? '()) now evaluating to #t. I have no problems with set-union,
> > intersection, etc. being defined for lists, but to treat lists as sets
> > always is perverse to me. The contracts for set operations should use
> > set-like? for (or/c set? list?) and keep the two constructions separate.
> >
> > This conflation is almost as bad as treating empty list as false.
> >
> > -Ian
> > _
> > Racket Developers list:
> > http://lists.racket-lang.org/dev
> >
> >
> >
> >
> _
>   Racket Developers list:
>   http://lists.racket-lang.org/dev
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Lists aren't sets, but have set-like operations

[J. Ian Johnson]

Okay, I can abide. However, that doesn't really get at my frustration. I'm 
using the set constructor, that appears to now be an immutable-custom-set with 
make-immutable-hash as its make-table. So what I'm looking for is not set?, but 
set-immutable?, as it's a distinct (family of) struct types that won't clash 
with the primitive data that I'm otherwise using.
-Ian
- Original Message -
From: "Carl Eastlund" 
To: "J. Ian Johnson" 
Cc: "dev" 
Sent: Wednesday, August 21, 2013 6:58:56 PM GMT -05:00 US/Canada Eastern
Subject: Re: [racket-dev] Lists aren't sets, but have set-like operations


Ian, sets are now a generic datatype, like dictionaries. Association lists are 
dictionaries, and lists are now sets. They're also streams and sequences. 
They're not just "set-like". 



Carl Eastlund 


On Wed, Aug 21, 2013 at 6:56 PM, J. Ian Johnson < i...@ccs.neu.edu > wrote: 


I just wasted about 2 hours tracking down a bug that ended up being due to 
(set? '()) now evaluating to #t. I have no problems with set-union, 
intersection, etc. being defined for lists, but to treat lists as sets always 
is perverse to me. The contracts for set operations should use set-like? for 
(or/c set? list?) and keep the two constructions separate. 

This conflation is almost as bad as treating empty list as false. 

-Ian 
_ 
Racket Developers list: 
http://lists.racket-lang.org/dev 


_
  Racket Developers list:
  http://lists.racket-lang.org/dev

[racket-dev] Lists aren't sets, but have set-like operations

[J. Ian Johnson]

I just wasted about 2 hours tracking down a bug that ended up being due to 
(set? '()) now evaluating to #t. I have no problems with set-union, 
intersection, etc. being defined for lists, but to treat lists as sets always 
is perverse to me. The contracts for set operations should use set-like? for 
(or/c set? list?) and keep the two constructions separate.

This conflation is almost as bad as treating empty list as false.

-Ian
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Generics scoping issues

[J. Ian Johnson]

I discovered that afterwards, yes. However I do want to short-circuit just 
calls to free to use the defaults, not free-box. Currently I have to check the 
box in each instance.
-Ian
- Original Message -
From: Carl Eastlund 
To: J. Ian Johnson 
Cc: dev 
Sent: Fri, 16 Aug 2013 19:48:58 -0400 (EDT)
Subject: Re: [racket-dev] Generics scoping issues

Mind you, I don't think this example -- using a method in a #:fast-defaults
predicate -- can work.  The implementation of free-box will have to check
the predicate in order to perform generic dispatch, and the predicate has
to call free-box, so it will diverge.

Carl Eastlund


On Fri, Aug 16, 2013 at 6:51 PM, Carl Eastlund  wrote:

> The method name you give to define/generic is interpreted in the context
> of the generic interface name you provide.  So if you supply the name
> "free" inside a macro, that's the wrong context.  That error goes away, as
> you found, if you pass "free" as an argument to def-free.
>
> After that, you get the error "free-box: undefined" because the
> #:fast-defaults predicate is lifted to a definition that comes before the
> definition of the free-box method.  I'll fix that by reordering the
> definitions; meanwhile you can fix that by just eta-expanding your use of
> "compose".
>
> Carl Eastlund
>
>
> On Fri, Aug 16, 2013 at 5:41 PM, Carl Eastlund  wrote:
>
>> The method names are always going to be in the context of the generic
>> interface name.  There's nowhere else they can come from.
>>
>> Carl Eastlund
>>
>>
>> On Fri, Aug 16, 2013 at 5:39 PM, J. Ian Johnson  wrote:
>>
>>> WRT the struct abstraction, using syntax-local-introduce on
>>> #'gen:binds-variables seemed to do the trick, oddly.
>>> -Ian
>>> - Original Message -
>>> From: "Carl Eastlund" 
>>> To: "J. Ian Johnson" 
>>> Cc: "dev" 
>>> Sent: Friday, August 16, 2013 5:23:33 PM GMT -05:00 US/Canada Eastern
>>> Subject: Re: [racket-dev] Generics scoping issues
>>>
>>>
>>> Okay, let me dig into this. The expansion of define/generic is an odd
>>> thing in the way it treats the method names; I'm not at all sure I've
>>> gotten it right, or that it's clear what "right" should even be. I'll get
>>> back to you shortly.
>>>
>>>
>>>
>>> Carl Eastlund
>>>
>>>
>>> On Fri, Aug 16, 2013 at 5:17 PM, J. Ian Johnson < i...@ccs.neu.edu >
>>> wrote:
>>>
>>>
>>> Re: problem 1 - ah yes I see.
>>> Problem 2:
>>> In the body of def-free:
>>>
>>> generic-problems.rkt:16:26: define/generic: free is not a method of
>>> generic interfaces gen:binds-variables
>>> at: free
>>> in: (define/generic gfree free)
>>>
>>> This compiles if I additionally supply def-free with free, but it
>>> doesn't run:
>>> free-box: undefined;
>>> cannot reference an identifier before its definition
>>> in module: "/home/ianj/projects/oaam/code/generic-problems.rkt"
>>> context...:
>>> /home/ianj/projects/oaam/code/generic-problems.rkt: [running body]
>>>
>>> Furthermore, if I abstract over the struct form so that #:methods
>>> gen:binds-variables is part of the macro expansion, even passing free to
>>> def-free won't work anymore:
>>>
>>> (define-syntax-rule (astruct name (fields ...) (methods ...))
>>> (struct name exp (fields ...) #:transparent #:methods
>>> gen:binds-variables [methods ...]))
>>>
>>> (astruct avar (name)
>>> [(def-free e gfree free bound avar [(x) (if (x . ∈ . bound) ∅ (set
>>> x))])])
>>>
>>> generic-problems.rkt:31:27: define/generic: free is not a method of
>>> generic interfaces gen:binds-variables
>>> at: free
>>> in: (define/generic gfree free)
>>>
>>>
>>>
>>>
>>> - Original Message -
>>> From: "Carl Eastlund" < c...@ccs.neu.edu >
>>> To: "J. Ian Johnson" < i...@ccs.neu.edu >
>>> Cc: "dev" < dev@racket-lang.org >
>>> Sent: Friday, August 16, 2013 4:50:53 PM GMT -05:00 US/Canada Eastern
>>> Subject: Re: [racket-dev] Generics scoping issues
>>>
>>>
>>>
>>> Problem 1 -- you have to use define/generic if you want to use the
>>> generic version of something in the context of a set of specific method
>>> implementations. Th

Re: [racket-dev] Generics scoping issues

[J. Ian Johnson]

WRT the struct abstraction, using syntax-local-introduce on 
#'gen:binds-variables seemed to do the trick, oddly.
-Ian
- Original Message -
From: "Carl Eastlund" 
To: "J. Ian Johnson" 
Cc: "dev" 
Sent: Friday, August 16, 2013 5:23:33 PM GMT -05:00 US/Canada Eastern
Subject: Re: [racket-dev] Generics scoping issues


Okay, let me dig into this. The expansion of define/generic is an odd thing in 
the way it treats the method names; I'm not at all sure I've gotten it right, 
or that it's clear what "right" should even be. I'll get back to you shortly. 



Carl Eastlund 


On Fri, Aug 16, 2013 at 5:17 PM, J. Ian Johnson < i...@ccs.neu.edu > wrote: 


Re: problem 1 - ah yes I see. 
Problem 2: 
In the body of def-free: 

generic-problems.rkt:16:26: define/generic: free is not a method of generic 
interfaces gen:binds-variables 
at: free 
in: (define/generic gfree free) 

This compiles if I additionally supply def-free with free, but it doesn't run: 
free-box: undefined; 
cannot reference an identifier before its definition 
in module: "/home/ianj/projects/oaam/code/generic-problems.rkt" 
context...: 
/home/ianj/projects/oaam/code/generic-problems.rkt: [running body] 

Furthermore, if I abstract over the struct form so that #:methods 
gen:binds-variables is part of the macro expansion, even passing free to 
def-free won't work anymore: 

(define-syntax-rule (astruct name (fields ...) (methods ...)) 
(struct name exp (fields ...) #:transparent #:methods gen:binds-variables 
[methods ...])) 

(astruct avar (name) 
[(def-free e gfree free bound avar [(x) (if (x . ∈ . bound) ∅ (set x))])]) 

generic-problems.rkt:31:27: define/generic: free is not a method of generic 
interfaces gen:binds-variables 
at: free 
in: (define/generic gfree free) 




----- Original Message - 
From: "Carl Eastlund" < c...@ccs.neu.edu > 
To: "J. Ian Johnson" < i...@ccs.neu.edu > 
Cc: "dev" < dev@racket-lang.org > 
Sent: Friday, August 16, 2013 4:50:53 PM GMT -05:00 US/Canada Eastern 
Subject: Re: [racket-dev] Generics scoping issues 



Problem 1 -- you have to use define/generic if you want to use the generic 
version of something in the context of a set of specific method 
implementations. That's by design. 

Problem 2 -- what error message or unexpected behavior are you getting? That 
should work, it sounds like a bug in define/generic if it's not working. 



Carl Eastlund 


On Fri, Aug 16, 2013 at 4:36 PM, J. Ian Johnson < i...@ccs.neu.edu > wrote: 


I'm starting to use generics, and me being myself, I wrote some macros to make 
writing method definitions easier. 
But, I'm seeing that #:methods seems to rebind method identifiers in a way that 
hygiene interferes with. 

I would expect to be allowed to do the following two things (problems 
annotated): 

(struct exp (label fvs-box)) ;; parent struct for all expressions 
(define-generics binds-variables 
[free-box binds-variables] 
[free binds-variables #:bound [bound]] 
#:fallbacks [(define (free e #:bound [bound ∅]) ∅) 
(define free-box exp-fvs-box)] 
#:fast-defaults ([(compose unbox free-box) 
(define (free e #:bound bound) (unbox (free-box e)))])) ;; problem 1: free-box 
not in scope 

(define-syntax-rule (def-free e gfree bound struct [(pats ...) rhss ...]) 
(begin 
(define/generic gfree free) ;; problem 2: since #:methods rebinds free, this is 
not in the scope one would expect with its definition in the define-generics 
form. 
(define (free e #:bound [bound ∅]) 
(match e [(struct _ fvs-box pats ...) 
(set-box! fvs-box 
(let () rhss ...))] 

(struct var exp (name) #:transparent 
#:methods gen:binds-variables 
[(def-free e gfree bound var [(x) (if (x . ∈ . bound) ∅ (set x))])]) 

I have workarounds thanks to stamourv, but they're unpleasant: 
Problem 1: define free in fast-defaults as an eta-expansion of a definition 
outside the define-generics form that does what you want. 
Problem 2: add free as a parameter to def-free, and pass free in at all uses of 
def-free. 

The first problem seems like more of a programming error than the use of the 
wrong tool. 
The second problem seems like generic method identifiers should be 
syntax-parameters, if they indeed need to be rebound in the rhs of the 
#:methods argument. 

Are these expectations unreasonable/against the design decisions for generics? 
Thanks, 
-Ian 

_ 
Racket Developers list: 
http://lists.racket-lang.org/dev 




_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Generics scoping issues

[J. Ian Johnson]

Re: problem 1 - ah yes I see.
Problem 2:
In the body of def-free:

generic-problems.rkt:16:26: define/generic: free is not a method of generic 
interfaces gen:binds-variables
  at: free
  in: (define/generic gfree free)

This compiles if I additionally supply def-free with free, but it doesn't run:
free-box: undefined;
 cannot reference an identifier before its definition
  in module: "/home/ianj/projects/oaam/code/generic-problems.rkt"
  context...:
   /home/ianj/projects/oaam/code/generic-problems.rkt: [running body]

Furthermore, if I abstract over the struct form so that #:methods 
gen:binds-variables is part of the macro expansion, even passing free to 
def-free won't work anymore:

(define-syntax-rule (astruct name (fields ...) (methods ...))
  (struct name exp (fields ...) #:transparent #:methods gen:binds-variables 
[methods ...]))

(astruct avar (name)
[(def-free e gfree free bound avar [(x) (if (x . ∈ . bound) ∅ (set 
x))])])

generic-problems.rkt:31:27: define/generic: free is not a method of generic 
interfaces gen:binds-variables
  at: free
  in: (define/generic gfree free)
 

- Original Message -
From: "Carl Eastlund" 
To: "J. Ian Johnson" 
Cc: "dev" 
Sent: Friday, August 16, 2013 4:50:53 PM GMT -05:00 US/Canada Eastern
Subject: Re: [racket-dev] Generics scoping issues



Problem 1 -- you have to use define/generic if you want to use the generic 
version of something in the context of a set of specific method 
implementations. That's by design. 

Problem 2 -- what error message or unexpected behavior are you getting? That 
should work, it sounds like a bug in define/generic if it's not working. 



Carl Eastlund 


On Fri, Aug 16, 2013 at 4:36 PM, J. Ian Johnson < i...@ccs.neu.edu > wrote: 


I'm starting to use generics, and me being myself, I wrote some macros to make 
writing method definitions easier. 
But, I'm seeing that #:methods seems to rebind method identifiers in a way that 
hygiene interferes with. 

I would expect to be allowed to do the following two things (problems 
annotated): 

(struct exp (label fvs-box)) ;; parent struct for all expressions 
(define-generics binds-variables 
[free-box binds-variables] 
[free binds-variables #:bound [bound]] 
#:fallbacks [(define (free e #:bound [bound ∅]) ∅) 
(define free-box exp-fvs-box)] 
#:fast-defaults ([(compose unbox free-box) 
(define (free e #:bound bound) (unbox (free-box e)))])) ;; problem 1: free-box 
not in scope 

(define-syntax-rule (def-free e gfree bound struct [(pats ...) rhss ...]) 
(begin 
(define/generic gfree free) ;; problem 2: since #:methods rebinds free, this is 
not in the scope one would expect with its definition in the define-generics 
form. 
(define (free e #:bound [bound ∅]) 
(match e [(struct _ fvs-box pats ...) 
(set-box! fvs-box 
(let () rhss ...))] 

(struct var exp (name) #:transparent 
#:methods gen:binds-variables 
[(def-free e gfree bound var [(x) (if (x . ∈ . bound) ∅ (set x))])]) 

I have workarounds thanks to stamourv, but they're unpleasant: 
Problem 1: define free in fast-defaults as an eta-expansion of a definition 
outside the define-generics form that does what you want. 
Problem 2: add free as a parameter to def-free, and pass free in at all uses of 
def-free. 

The first problem seems like more of a programming error than the use of the 
wrong tool. 
The second problem seems like generic method identifiers should be 
syntax-parameters, if they indeed need to be rebound in the rhs of the 
#:methods argument. 

Are these expectations unreasonable/against the design decisions for generics? 
Thanks, 
-Ian 

_ 
Racket Developers list: 
http://lists.racket-lang.org/dev 


_
  Racket Developers list:
  http://lists.racket-lang.org/dev

[racket-dev] Generics scoping issues

[J. Ian Johnson]

I'm starting to use generics, and me being myself, I wrote some macros to make 
writing method definitions easier.
But, I'm seeing that #:methods seems to rebind method identifiers in a way that 
hygiene interferes with.

I would expect to be allowed to do the following two things (problems 
annotated):

(struct exp (label fvs-box)) ;; parent struct for all expressions
(define-generics binds-variables
  [free-box binds-variables]
  [free binds-variables #:bound [bound]]
  #:fallbacks [(define (free e #:bound [bound ∅]) ∅)
   (define free-box exp-fvs-box)]
  #:fast-defaults ([(compose unbox free-box)
(define (free e #:bound bound) (unbox (free-box e)))])) ;; 
problem 1: free-box not in scope

(define-syntax-rule (def-free e gfree bound struct [(pats ...) rhss ...])
  (begin 
(define/generic gfree free) ;; problem 2: since #:methods rebinds free, 
this is not in the scope one would expect with its definition in the 
define-generics form.
(define (free e #:bound [bound ∅])
 (match e [(struct _ fvs-box pats ...)
   (set-box! fvs-box
 (let () rhss ...))]

(struct var exp (name) #:transparent
#:methods gen:binds-variables
[(def-free e gfree bound var [(x) (if (x . ∈ . bound) ∅ (set x))])])

I have workarounds thanks to stamourv, but they're unpleasant:
Problem 1: define free in fast-defaults as an eta-expansion of a definition 
outside the define-generics form that does what you want.
Problem 2: add free as a parameter to def-free, and pass free in at all uses of 
def-free.

The first problem seems like more of a programming error than the use of the 
wrong tool.
The second problem seems like generic method identifiers should be 
syntax-parameters, if they indeed need to be rebound in the rhs of the 
#:methods argument.

Are these expectations unreasonable/against the design decisions for generics?
Thanks,
-Ian

_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] "Too many" struct definitions leads to literal error

[J. Ian Johnson]

Many thanks. First call-with-values/begin0 and now this. I should be the 
dep bug finder, heh.
-Ian
- Original Message -
From: Matthew Flatt 
To: J. Ian Johnson 
Cc: dev 
Sent: Wed, 7 Aug 2013 11:43:12 -0400 (EDT)
Subject: Re: [racket-dev] "Too many" struct definitions leads to literal 
 error

Thanks --- I've pushed a repair, finally.

Unless I'm confused, the problem was a bug in the bytecode format that
has been around since v300 or so.

At Mon, 5 Aug 2013 15:20:17 -0400 (EDT), "J. Ian Johnson" wrote:
> Pushed current branch to
> https://github.com/dvanhorn/oaam/tree/thocon
> 
> kcfa.rkt has an "mflatt" comment that will point you at the problem lines of 
> code.
> 
> The entry point for the project is kcfa-instanstantiations.rkt
> -Ian
> - Original Message -
> From: "Matthew Flatt" 
> To: "J. Ian Johnson" 
> Cc: "dev" 
> Sent: Monday, August 5, 2013 3:09:50 PM GMT -05:00 US/Canada Eastern
> Subject: Re: [racket-dev] "Too many" struct definitions leads to literal 
>  error
> 
> Seeing # is about the same as a seg fault.
> 
> Can you send me something to replicate the crash on my machine?
> 
> 
> 
> On Aug 5, 2013, at 11:55 AM, "J. Ian Johnson"  wrote:
> 
> > I'm working more on my analysis framework, and added many different kinds 
> > of 
> new continuation frames. I get to a point where I comment out all definitions 
> past a certain point (and their uses) and the program 
> > compiles. I add one more (any one) and I get the following error:
> > 
> > kcfa-instantiations.rkt:136:6: ?: literal data is not allowed;
> > no #%datum syntax transformer is bound
> >  in: #
> >  context...:
> >   /home/ianj/racket/racket/collects/racket/splicing.rkt:234:0
> >   /home/ianj/racket/racket/collects/racket/splicing.rkt:181:0
> >   /home/ianj/racket/racket/collects/racket/splicing.rkt:234:0
> >   /home/ianj/racket/racket/collects/racket/splicing.rkt:181:0
> >   /home/ianj/racket/racket/collects/racket/splicing.rkt:234:0
> >   /home/ianj/racket/racket/collects/racket/splicing.rkt:181:0
> >   /home/ianj/racket/racket/collects/racket/splicing.rkt:234:0
> >   /home/ianj/racket/racket/collects/racket/splicing.rkt:181:0
> >   /home/ianj/racket/racket/collects/racket/splicing.rkt:234:0
> >   /home/ianj/racket/racket/collects/racket/splicing.rkt:181:0
> >   /home/ianj/racket/racket/collects/racket/splicing.rkt:234:0
> >   /home/ianj/racket/racket/collects/racket/splicing.rkt:181:0
> >   /home/ianj/racket/racket/collects/racket/private/modbeg.rkt:46:4
> >   /home/ianj/racket/racket/collects/compiler/cm.rkt:345:0: compile-zo*
> >   /home/ianj/racket/racket/collects/compiler/cm.rkt:552:26
> >   /home/ianj/racket/racket/collects/compiler/cm.rkt:545:42...
> > 
> > This is blocking progress. I'm about to pull and hope for the best. Any 
> > ideas 
> what might be causing this kind of behavior in the expander?
> > -Ian
> > _
> >  Racket Developers list:
> >  http://lists.racket-lang.org/dev
> > 

_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] "Too many" struct definitions leads to literal error

[J. Ian Johnson]

Pushed current branch to
https://github.com/dvanhorn/oaam/tree/thocon

kcfa.rkt has an "mflatt" comment that will point you at the problem lines of 
code.

The entry point for the project is kcfa-instanstantiations.rkt
-Ian
- Original Message -
From: "Matthew Flatt" 
To: "J. Ian Johnson" 
Cc: "dev" 
Sent: Monday, August 5, 2013 3:09:50 PM GMT -05:00 US/Canada Eastern
Subject: Re: [racket-dev] "Too many" struct definitions leads to literal 
 error

Seeing # is about the same as a seg fault.

Can you send me something to replicate the crash on my machine?



On Aug 5, 2013, at 11:55 AM, "J. Ian Johnson"  wrote:

> I'm working more on my analysis framework, and added many different kinds of 
> new continuation frames. I get to a point where I comment out all definitions 
> past a certain point (and their uses) and the program 
> compiles. I add one more (any one) and I get the following error:
> 
> kcfa-instantiations.rkt:136:6: ?: literal data is not allowed;
> no #%datum syntax transformer is bound
>  in: #
>  context...:
>   /home/ianj/racket/racket/collects/racket/splicing.rkt:234:0
>   /home/ianj/racket/racket/collects/racket/splicing.rkt:181:0
>   /home/ianj/racket/racket/collects/racket/splicing.rkt:234:0
>   /home/ianj/racket/racket/collects/racket/splicing.rkt:181:0
>   /home/ianj/racket/racket/collects/racket/splicing.rkt:234:0
>   /home/ianj/racket/racket/collects/racket/splicing.rkt:181:0
>   /home/ianj/racket/racket/collects/racket/splicing.rkt:234:0
>   /home/ianj/racket/racket/collects/racket/splicing.rkt:181:0
>   /home/ianj/racket/racket/collects/racket/splicing.rkt:234:0
>   /home/ianj/racket/racket/collects/racket/splicing.rkt:181:0
>   /home/ianj/racket/racket/collects/racket/splicing.rkt:234:0
>   /home/ianj/racket/racket/collects/racket/splicing.rkt:181:0
>   /home/ianj/racket/racket/collects/racket/private/modbeg.rkt:46:4
>   /home/ianj/racket/racket/collects/compiler/cm.rkt:345:0: compile-zo*
>   /home/ianj/racket/racket/collects/compiler/cm.rkt:552:26
>   /home/ianj/racket/racket/collects/compiler/cm.rkt:545:42...
> 
> This is blocking progress. I'm about to pull and hope for the best. Any ideas 
> what might be causing this kind of behavior in the expander?
> -Ian
> _
>  Racket Developers list:
>  http://lists.racket-lang.org/dev
> 
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] "Too many" struct definitions leads to literal error

[J. Ian Johnson]

Just pulled and rebuilt. No go.
I'm not defining an insane amount of structs. It's at 19 or so that this starts 
being a problem. I am in a splicing-syntax-parameterize context, which might be 
where the problems are being introduced.
-Ian
- Original Message -----
From: "J. Ian Johnson" 
To: "dev" 
Sent: Monday, August 5, 2013 2:55:01 PM GMT -05:00 US/Canada Eastern
Subject: [racket-dev] "Too many" struct definitions leads to literal 
 error

I'm working more on my analysis framework, and added many different kinds of 
new continuation frames. I get to a point where I comment out all definitions 
past a certain point (and their uses) and the program 
compiles. I add one more (any one) and I get the following error:

kcfa-instantiations.rkt:136:6: ?: literal data is not allowed;
 no #%datum syntax transformer is bound
  in: #
  context...:
   /home/ianj/racket/racket/collects/racket/splicing.rkt:234:0
   /home/ianj/racket/racket/collects/racket/splicing.rkt:181:0
   /home/ianj/racket/racket/collects/racket/splicing.rkt:234:0
   /home/ianj/racket/racket/collects/racket/splicing.rkt:181:0
   /home/ianj/racket/racket/collects/racket/splicing.rkt:234:0
   /home/ianj/racket/racket/collects/racket/splicing.rkt:181:0
   /home/ianj/racket/racket/collects/racket/splicing.rkt:234:0
   /home/ianj/racket/racket/collects/racket/splicing.rkt:181:0
   /home/ianj/racket/racket/collects/racket/splicing.rkt:234:0
   /home/ianj/racket/racket/collects/racket/splicing.rkt:181:0
   /home/ianj/racket/racket/collects/racket/splicing.rkt:234:0
   /home/ianj/racket/racket/collects/racket/splicing.rkt:181:0
   /home/ianj/racket/racket/collects/racket/private/modbeg.rkt:46:4
   /home/ianj/racket/racket/collects/compiler/cm.rkt:345:0: compile-zo*
   /home/ianj/racket/racket/collects/compiler/cm.rkt:552:26
   /home/ianj/racket/racket/collects/compiler/cm.rkt:545:42...

This is blocking progress. I'm about to pull and hope for the best. Any ideas 
what might be causing this kind of behavior in the expander?
-Ian
_
  Racket Developers list:
  http://lists.racket-lang.org/dev
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

[racket-dev] "Too many" struct definitions leads to literal error

[J. Ian Johnson]

I'm working more on my analysis framework, and added many different kinds of 
new continuation frames. I get to a point where I comment out all definitions 
past a certain point (and their uses) and the program 
compiles. I add one more (any one) and I get the following error:

kcfa-instantiations.rkt:136:6: ?: literal data is not allowed;
 no #%datum syntax transformer is bound
  in: #
  context...:
   /home/ianj/racket/racket/collects/racket/splicing.rkt:234:0
   /home/ianj/racket/racket/collects/racket/splicing.rkt:181:0
   /home/ianj/racket/racket/collects/racket/splicing.rkt:234:0
   /home/ianj/racket/racket/collects/racket/splicing.rkt:181:0
   /home/ianj/racket/racket/collects/racket/splicing.rkt:234:0
   /home/ianj/racket/racket/collects/racket/splicing.rkt:181:0
   /home/ianj/racket/racket/collects/racket/splicing.rkt:234:0
   /home/ianj/racket/racket/collects/racket/splicing.rkt:181:0
   /home/ianj/racket/racket/collects/racket/splicing.rkt:234:0
   /home/ianj/racket/racket/collects/racket/splicing.rkt:181:0
   /home/ianj/racket/racket/collects/racket/splicing.rkt:234:0
   /home/ianj/racket/racket/collects/racket/splicing.rkt:181:0
   /home/ianj/racket/racket/collects/racket/private/modbeg.rkt:46:4
   /home/ianj/racket/racket/collects/compiler/cm.rkt:345:0: compile-zo*
   /home/ianj/racket/racket/collects/compiler/cm.rkt:552:26
   /home/ianj/racket/racket/collects/compiler/cm.rkt:545:42...

This is blocking progress. I'm about to pull and hope for the best. Any ideas 
what might be causing this kind of behavior in the expander?
-Ian
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Using new package system: rackunit still pointing to collects?

[J. Ian Johnson]

That dies saying it can't find ./if_mach.
-Ian
- Original Message -
From: "Carl Eastlund" 
To: "J. Ian Johnson" 
Cc: "dev" 
Sent: Monday, July 29, 2013 12:26:58 PM GMT -05:00 US/Canada Eastern
Subject: Re: [racket-dev] Using new package system: rackunit still pointing to 
collects?



Yes, instead you want to run 'make' at the top of the repository. 

Carl Eastlund 

-- 
WARNING! Poorly-typed cell phone email precedes. 
On Jul 29, 2013 12:23 PM, "J. Ian Johnson" < i...@ccs.neu.edu > wrote: 


I've done a complete nuke of my local racket install, and many things have just 
broken. The two problems that affect me the most are the disappearance of raco 
doc and rackunit. 
Is there a new incantation other than 
./configure ; make ; make install 
in racket/src 

or am I experiencing growing pains with the package system that need fixing? 

Thanks, 
-Ian 
_ 
Racket Developers list: 
http://lists.racket-lang.org/dev 
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

[racket-dev] Using new package system: rackunit still pointing to collects?

[J. Ian Johnson]

I've done a complete nuke of my local racket install, and many things have just 
broken. The two problems that affect me the most are the disappearance of raco 
doc and rackunit.
Is there a new incantation other than
 ./configure ; make ; make install
in racket/src

or am I experiencing growing pains with the package system that need fixing?

Thanks,
-Ian
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] PLaneT(2): Single vs multi-collection packages

[J. Ian Johnson]

Agreed. This looks good.
-Ian
- Original Message -
From: "Carl Eastlund" 
To: "Matthew Flatt" 
Cc: dev@racket-lang.org
Sent: Friday, June 14, 2013 10:42:06 AM GMT -05:00 US/Canada Eastern
Subject: Re: [racket-dev] PLaneT(2): Single vs multi-collection packages



I vote for this change. I'll happily update my package in order to make it 
easier for others to contribute new ones. 



Carl Eastlund 


On Fri, Jun 14, 2013 at 10:07 AM, Matthew Flatt < mfl...@cs.utah.edu > wrote: 


I think more people need to speak up on this question --- particularly 
authors of existing packages, since the current proposal necessitates 
an update to each existing package. 

The proposal is to make single-package collections the default: 

* If a directory used as a package has no "info.rkt" file, then it is 
treated as a single-collection package. 

The single collection's name is the same as the package name (which 
tends to be the directory name, but it depends on how you install 
the package). 

* If a directory used as a package has an "info.rkt" file, but 
"info.rkt" doesn't explicitly say that the package is 
multi-collection, then it's still a single-collection package. 

The "info.rkt" file might supply a name for the single collection, 
instead of leaving it to the package name; supplying a name would be 
a requirement for ring-0 packages. 

For each existing package, the author would need to add a line to the 
package's "info.rkt" to indicate that it is a multi-collection package 
(or change the layout to single-collection mode, with the caveat that 
the package won't work with v5.3.4). 

Any more votes for/against? 



_ 
Racket Developers list: 
http://lists.racket-lang.org/dev 


_
  Racket Developers list:
  http://lists.racket-lang.org/dev
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] raco pkg remove not removing

[J. Ian Johnson]

Quite right. You caught it. Thanks.
-Ian
- Original Message -
From: "Matthew Flatt" 
To: "J. Ian Johnson" 
Cc: "J. Ian Johnson" , "dev" 
Sent: Thursday, May 30, 2013 12:42:18 PM GMT -05:00 US/Canada Eastern
Subject: Re: [racket-dev] raco pkg remove not removing

Does `raco link -l' show any trace of the old package (which would
suggest that the package manager failed between the points of removing
its own registration of the package and removing the link)?

If the package install was not installation-wide, then all state should
be in your "add-on" directory as reported by `(find-system-path
'addon-dir)'. The links are in "links.rktd", and package files are in
"pkgs" or "pkgs" inside a directory whose name is a version number.

At Thu, 30 May 2013 11:38:05 -0400 (EDT), "J. Ian Johnson" wrote:
> Following Asumu's advice, I used --force. I got the same error, but then it 
> was no longer installed. I tried to install again with the fixed files. It's 
> still looking for a directory for-accumulate! There's nothing in my 
> repository 
> that references that name anymore. I'm quite confused. Are there some latent 
> files downloaded by the package manager that are being used when they 
> shouldn't? If so, that's a bug. Additionally I would want to know where they 
> are so I can delete them to work around the problem currently.
> -Ian
> - Original Message -
> From: "J. Ian Johnson" 
> To: "dev" 
> Sent: Thursday, May 30, 2013 11:31:25 AM GMT -05:00 US/Canada Eastern
> Subject: [racket-dev] raco pkg remove not removing
> 
> I tried to turn my nifty-macros repo into something that the new package 
> manager could work with. I recently changed for-accumulate.rkt to for-acc.rkt 
> but forgot to change main.rkt to require and reprovide from the new file. I 
> installed from github and it died on looking for the for-accumulate 
> directory. 
> This is weird since nothing referred to the directory - it was all the files. 
> Even so, I changed main.rkt to reflect the changes and tried to install. No 
> go, the package was already installed (albeit incorrectly). I try to remove. 
> It has the same error and fails to remove the package. I'm now stuck. How to 
> I 
> remove an incorrectly installed package?
> 
> -Ian
> _
>   Racket Developers list:
>   http://lists.racket-lang.org/dev
> _
>   Racket Developers list:
>   http://lists.racket-lang.org/dev
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] raco pkg remove not removing

[J. Ian Johnson]

Following Asumu's advice, I used --force. I got the same error, but then it was 
no longer installed. I tried to install again with the fixed files. It's still 
looking for a directory for-accumulate! There's nothing in my repository that 
references that name anymore. I'm quite confused. Are there some latent files 
downloaded by the package manager that are being used when they shouldn't? If 
so, that's a bug. Additionally I would want to know where they are so I can 
delete them to work around the problem currently.
-Ian
- Original Message -
From: "J. Ian Johnson" 
To: "dev" 
Sent: Thursday, May 30, 2013 11:31:25 AM GMT -05:00 US/Canada Eastern
Subject: [racket-dev] raco pkg remove not removing

I tried to turn my nifty-macros repo into something that the new package 
manager could work with. I recently changed for-accumulate.rkt to for-acc.rkt 
but forgot to change main.rkt to require and reprovide from the new file. I 
installed from github and it died on looking for the for-accumulate directory. 
This is weird since nothing referred to the directory - it was all the files. 
Even so, I changed main.rkt to reflect the changes and tried to install. No go, 
the package was already installed (albeit incorrectly). I try to remove. It has 
the same error and fails to remove the package. I'm now stuck. How to I remove 
an incorrectly installed package?

-Ian
_
  Racket Developers list:
  http://lists.racket-lang.org/dev
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

[racket-dev] raco pkg remove not removing

[J. Ian Johnson]

I tried to turn my nifty-macros repo into something that the new package 
manager could work with. I recently changed for-accumulate.rkt to for-acc.rkt 
but forgot to change main.rkt to require and reprovide from the new file. I 
installed from github and it died on looking for the for-accumulate directory. 
This is weird since nothing referred to the directory - it was all the files. 
Even so, I changed main.rkt to reflect the changes and tried to install. No go, 
the package was already installed (albeit incorrectly). I try to remove. It has 
the same error and fails to remove the package. I'm now stuck. How to I remove 
an incorrectly installed package?

-Ian
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] for/fold feature request

[J. Ian Johnson]

The for[/*] macros are fairly low in the language tower for Racket, so making 
these kinds of changes robust in the original implementation is cumbersome and 
error-prone. I've written a shim to use on top of for/fold and for*/fold to 
alleviate some pain in multiple value accumulation, post-processing and 
irrelevant intermediate accumulators. It uses syntax/parse, which is higher in 
the language tower. Check it out at

https://github.com/ianj/nifty-macros/tree/master/for-accumulate

If you find any bugs, just shoot me an email and I'll make sure to fix the 
problems.
-Ian
- Original Message -
From: "oev" 
To: dev@racket-lang.org
Sent: Wednesday, May 29, 2013 7:30:59 AM GMT -05:00 US/Canada Eastern
Subject: [racket-dev]  for/fold feature request

Hi, all!

Using `for/fold' with more than one accumulator is inconvenient, when
there is a need for auxiliary operations with accumulators before return.

For example:

(define (partition pred lst)
  (define-values (a1 a2)
(for/fold ([acc1 null]
   [acc2 null])
  ([v (in-list lst)])
  (if (pred v)
  (values (cons v acc1) acc2)
  (values acc1 (cons v acc2)
  (values (reverse a1)
  (reverse a2)))

In example, it's impossible to reverse accumulators without using
intermediate definitions and applying `values' again.

IMHO, very often in `loop with accumulator' cases, there is a final
operation with accumulator before return.

Is it possible to add ability for defining such final operation as
optional or keyword argument?

For example:

(define (partition pred lst)
  (for/fold ([acc1 null reverse]
 [acc2 null reverse])
([v (in-list lst)])
(if (pred v)
(values (cons v acc1) acc2)
(values acc1 (cons v acc2))

... or even better:

(define (partition pred lst)
  (for/fold ([acc1 null #:do-finally reverse]
 [acc2 null #:do-finally reverse])
([v (in-list lst)])
(if (pred v)
(values (cons v acc1) acc2)
(values acc1 (cons v acc2))




_
  Racket Developers list:
  http://lists.racket-lang.org/dev
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Constructing an identifier to an unexported binding

[J. Ian Johnson]

There are several identifiers that get introduced via expansion that TR needs 
to give types to. Not all are exported. Sam probably knows the reasons why they 
are not. I had to use the same code when concocting an analysis of racket core 
forms.
-Ian
- Original Message -
From: Matthias Felleisen 
To: Eric Dobson 
Cc: dev 
Sent: Thu, 23 May 2013 08:54:36 -0400 (EDT)
Subject: Re: [racket-dev] Constructing an identifier to an unexported binding


This has a scary feeling to it. 

Can you raise the level of discourse one level and perhaps figure out whether 
this is needed at all? I.e., find a different way to solve the problem? (What 
is the real problem?) 



On May 23, 2013, at 1:57 AM, Eric Dobson  wrote:

> Some modules have macros which expand into identifiers that are not
> exported, as they want to protect those bindings. TR currently has the
> following code which allows it to generate an identifier which is
> free-identifier=? to what would appear in the output of the macros.
> 
> define (make-template-identifier what where)
>  (let ([name (module-path-index-resolve (module-path-index-join where #f))])
>(parameterize ([current-namespace (make-empty-namespace)])
>  (namespace-attach-module (current-namespace) ''#%kernel)
>  (parameterize ([current-module-declare-name name])
>(eval `(,#'module any '#%kernel
> (#%provide ,what)
> (define-values (,what) #f
>  (namespace-require `(for-template ,name))
>  (namespace-syntax-introduce (datum->syntax #f what)
> 
> This turns out to be a slightly slow part of the initialization of TR.
> Does anyone know another way to get such an identifier?
> _
>  Racket Developers list:
>  http://lists.racket-lang.org/dev


_
  Racket Developers list:
  http://lists.racket-lang.org/dev

_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Racket2 suggestion: Attaching properties to operators

[J. Ian Johnson]

Isn't it true that Eiffel does compiler transforms given that a user has 
"proven" their operators associative/commutative, etc?
-Ian
- Original Message -
From: "Laurent" 
To: "Matthias Felleisen" 
Cc: dev@racket-lang.org
Sent: Sunday, May 5, 2013 1:28:59 PM GMT -05:00 US/Canada Eastern
Subject: Re: [racket-dev] Racket2 suggestion: Attaching properties to operators



...or keywords that would simplify my search. Don't take too much time digging 
old references that will not be much more than informative to me. 




On Sun, May 5, 2013 at 7:16 PM, Laurent < laurent.ors...@gmail.com > wrote: 



Would you happen to have a reference on that? 






On Sun, May 5, 2013 at 7:15 PM, Matthias Felleisen < matth...@ccs.neu.edu > 
wrote: 







On May 5, 2013, at 1:12 PM, Laurent wrote: 


Do you know why C++ has stopped pursuing this idea by any chance? 

No, and they may have more work going on besides standard work. 
It's worth reading up on it if you're interested. 




_
  Racket Developers list:
  http://lists.racket-lang.org/dev
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] else clauses: possible change to match?

[J. Ian Johnson]

Nothing readily available. I commonly use a shimmed match that gives better 
match failure errors that help me pinpoint a problem (though it's not for 
everyone):

(define-syntax (matche stx)
 (syntax-case stx () [(_ e [p rhs] ...) #`(matche e [p rhs ...] [else (error 
'bad-match "~a didn't match in ~a" else '#,stx)])]))

A macro is easy enough to change. I'm not saying to stay the backwards 
incompatible change because of me (and I don't use "else" like this anymore). 
I'm just noting that this seems like a plausible pattern out there.

-Ian
----- Original Message -
From: "Robby Findler" 
To: "J. Ian Johnson" 
Cc: "Robby Findler" , dev@racket-lang.org, "Sam 
Tobin-Hochstadt" 
Sent: Friday, May 3, 2013 11:12:34 AM GMT -05:00 US/Canada Eastern
Subject: Re: else clauses: possible change to match?

Can you point to some examples? 


Note that you can still use else, as long as you don't refer to it as a 
variable. 

On Friday, May 3, 2013, J. Ian Johnson wrote: 


I've used else as a catch-all binding in match. Yes, it's not the best 
practice, but I think since I've done it, other people must have done it too. 
This could annoy them. 
-Ian 
- Original Message - 
From: "Robby Findler" < ro...@eecs.northwestern.edu > 
To: "Sam Tobin-Hochstadt" < sa...@ccs.neu.edu > 
Cc: dev@racket-lang.org 
Sent: Friday, May 3, 2013 11:04:27 AM GMT -05:00 US/Canada Eastern 
Subject: Re: [racket-dev] else clauses: possible change to match? 


Given that we don't yet even have a prototype of racket2, I'm going to guess 
that "near" isn't all that near. IMO, there are other big things that we should 
be focused on going first (notably the package system). 


Just to check again: Is no one concerned with the backwards incompatibility 
issue? 



Robby 

On Friday, May 3, 2013, Sam Tobin-Hochstadt wrote: 


Right, I agree with this. My question is basically: are we going to, 
in the reasonably near future, be encouraging people to program in a 
`#lang racket2` where `cond` works differently, in which case it 
doesn't seem worth it to change `match`. Otherwise, I'll do this now. 

Sam 

On Fri, May 3, 2013 at 10:42 AM, Robby Findler 
< ro...@eecs.northwestern.edu > wrote: 
> Cond's else cannot change. I agree that that's what I would change if I 
> could have it back to do it over, but we cannot. 
> 
> That's the way to perhaps be thinking about racket2, tho. 
> 
> Robby 
> 
> 
> On Friday, May 3, 2013, Sam Tobin-Hochstadt wrote: 
>> 
>> On Fri, May 3, 2013 at 10:22 AM, Robby Findler 
>> < ro...@eecs.northwestern.edu > wrote: 
>> > 
>> > For this kind of thing, my preference would be to change match than to 
>> > issue 
>> > a warning. I don't like warnings that are basically admitting weaknesses 
>> > in 
>> > the language design Of course, changing a core thing like that may 
>> > be 
>> > more trouble than it is worth, due to backwards compatibility concerns, 
>> > which is why I think it is worth raising here to see what others think. 
>> 
>> I'm happy to make this change to `match`, except that I've heard 
>> Matthew say that he would have used a keyword for `else` in `cond` if 
>> he had it to do over again, and I wouldn't want to change one way, and 
>> then change back. 
>> 
>> Sam 

_ 
Racket Developers list: 
http://lists.racket-lang.org/dev 
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] else clauses: possible change to match?

[J. Ian Johnson]

I've used else as a catch-all binding in match. Yes, it's not the best 
practice, but I think since I've done it, other people must have done it too. 
This could annoy them.
-Ian
- Original Message -
From: "Robby Findler" 
To: "Sam Tobin-Hochstadt" 
Cc: dev@racket-lang.org
Sent: Friday, May 3, 2013 11:04:27 AM GMT -05:00 US/Canada Eastern
Subject: Re: [racket-dev] else clauses: possible change to match?


Given that we don't yet even have a prototype of racket2, I'm going to guess 
that "near" isn't all that near. IMO, there are other big things that we should 
be focused on going first (notably the package system). 


Just to check again: Is no one concerned with the backwards incompatibility 
issue? 



Robby 

On Friday, May 3, 2013, Sam Tobin-Hochstadt wrote: 


Right, I agree with this. My question is basically: are we going to, 
in the reasonably near future, be encouraging people to program in a 
`#lang racket2` where `cond` works differently, in which case it 
doesn't seem worth it to change `match`. Otherwise, I'll do this now. 

Sam 

On Fri, May 3, 2013 at 10:42 AM, Robby Findler 
< ro...@eecs.northwestern.edu > wrote: 
> Cond's else cannot change. I agree that that's what I would change if I 
> could have it back to do it over, but we cannot. 
> 
> That's the way to perhaps be thinking about racket2, tho. 
> 
> Robby 
> 
> 
> On Friday, May 3, 2013, Sam Tobin-Hochstadt wrote: 
>> 
>> On Fri, May 3, 2013 at 10:22 AM, Robby Findler 
>> < ro...@eecs.northwestern.edu > wrote: 
>> > 
>> > For this kind of thing, my preference would be to change match than to 
>> > issue 
>> > a warning. I don't like warnings that are basically admitting weaknesses 
>> > in 
>> > the language design Of course, changing a core thing like that may 
>> > be 
>> > more trouble than it is worth, due to backwards compatibility concerns, 
>> > which is why I think it is worth raising here to see what others think. 
>> 
>> I'm happy to make this change to `match`, except that I've heard 
>> Matthew say that he would have used a keyword for `else` in `cond` if 
>> he had it to do over again, and I wouldn't want to change one way, and 
>> then change back. 
>> 
>> Sam 

_
  Racket Developers list:
  http://lists.racket-lang.org/dev
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] [plt] Push #26372: master branch updated

[J. Ian Johnson]

I should mention that the literature on staged metaprogramming calls this 
"cross-stage persistence," (CSP) so I second Carl's proposal of cross-phase.
 -Ian
- Original Message -
From: Carl Eastlund 
To: Norman Gray 
Cc: dev Developers 
Sent: Wed, 27 Feb 2013 05:43:49 -0500 (EST)
Subject: Re: [racket-dev] [plt] Push #26372: master branch updated

First of all, thanks very much, Matthew, for implementing this!  This looks
like a great feature to me.  I have often been frustrated that users' data
structures aren't easy to quote or to manipulate in macros in the same way
as pairs or vectors; this should go a long way to improving the situation.

Second, for a name, how about some variation of "phase-global" or
"cross-phase"?

An amusing but probably not too informative name: "one-phase-fits-all".  ;)

Carl Eastlund

On Wed, Feb 27, 2013 at 4:58 AM, Norman Gray  wrote:

>
> Greetings.
>
> On 2013 Feb 27, at 01:14, Matthew Flatt  wrote:
>
> > I think part of the problem is distinguishing "module declarations"
> > (which don't have a phase) from "module instantiations" (which are
> > normally phase-specific).
>
> If 'which don't have a phase' is the key phrase, how about:
>
> phase-neutral
> phase-independent
> unphased
> phase-exempt
>
> 'phase-invariant' prompts (to me) the question '...under what
> transformation?'; 'phase-independent', like 'phase-neutral', in contrast
> suggests that the phase isn't relevant to them.
>
> Norman
>
>
> >
> > I want an adjective for a declaration that describes a treatment of its
> > instances. "Phaseless" is bad, because no module declaration has a
> > phase, but "all-phase" has the same problem.
> >
> > "Phase-invariant" could work, although that sounds like a property that
> > module declarations might have even if they're not treated specially.
> >
> > How about "phase-collapsing"? That suggests more (to me) that something
> > special is happening.
> >
> > At Tue, 26 Feb 2013 17:53:14 -0500, Ray Racine wrote:
> >> all-phase modules
> >> static modules
> >> static-phase modules
> >> phase-invariant modules
> >>
> >>
> >>
> >>
> >> On Tue, Feb 26, 2013 at 5:31 PM, Vincent St-Amour  >wrote:
> >>
> >>> At Tue, 26 Feb 2013 16:59:01 -0500,
> >>> mfl...@racket-lang.org wrote:
>  899a327 Matthew Flatt  2013-02-26 14:14
>  :
>  | add experimental support for "phaseless" modules
>  |
> >>>
> >>> After reading the docs, I find the name "phaseless" confusing. IIUC,
> >>> these modules are not special because they have no phase, but rather
> >>> because they're the same at all phases.
> >>>
> >>> Would "pan-phase", "omni-phase" or "cross-phase" be an accurate
> >>> description?
> >>>
> >>> Vincent
> >>> _
> >>>  Racket Developers list:
> >>>  http://lists.racket-lang.org/dev
> >>>
> > _
> >  Racket Developers list:
> >  http://lists.racket-lang.org/dev
>
> --
> Norman Gray  :  http://nxg.me.uk
> SUPA School of Physics and Astronomy, University of Glasgow, UK
>
>
> _
>   Racket Developers list:
>   http://lists.racket-lang.org/dev
>

_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Expansion of optional arguments in lambda

[J. Ian Johnson]

Scratch that, didn't look very deeply at your solution.
-Ian
- Original Message -
From: J. Ian Johnson 
To: Eric Dobson 
Cc: dev 
Sent: Sun, 24 Feb 2013 13:46:14 -0500 (EST)
Subject: Re: [racket-dev] Expansion of optional arguments in lambda

My guess would be code explosion.
-Ian
- Original Message -
From: Eric Dobson 
To: dev 
Sent: Sun, 24 Feb 2013 12:51:12 -0500 (EST)
Subject: [racket-dev] Expansion of optional arguments in lambda

lambda supports optional arguments, and does this by expanding out into a
core form that has flag arguments for if each argument is supplied. This is
tricky to type in TR and so I was investigating why it did it this way. I
did a micro benchmark on another method of expansion and it was 60% faster.
Is there a reason that racket does it the current way that I am missing.

#lang racket

(define f
  (case-lambda
(() (f 1))
((a) (f a (+ 3 a)))
((a b) (f a b (* a b)))
((a b c) (f a b c (- a (/ c b
((a b c d) (+ a b c d

(define (g (a 1) (b (+ 3 a)) (c (* a b)) (d (- a (/ c b
  (+ a b c d))

(define N 100)

(collect-garbage)
(collect-garbage)
(time
  (for ((i (in-range N)))
(f i)))

(collect-garbage)
(collect-garbage)
(time
  (for ((i (in-range N)))
(g i)))


(collect-garbage)
(collect-garbage)
(time
  (for ((i (in-range N)))
(f i)))

(collect-garbage)
(collect-garbage)
(time
  (for ((i (in-range N)))
(g i)))

_
  Racket Developers list:
  http://lists.racket-lang.org/dev

_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Expansion of optional arguments in lambda

[J. Ian Johnson]

My guess would be code explosion.
-Ian
- Original Message -
From: Eric Dobson 
To: dev 
Sent: Sun, 24 Feb 2013 12:51:12 -0500 (EST)
Subject: [racket-dev] Expansion of optional arguments in lambda

lambda supports optional arguments, and does this by expanding out into a
core form that has flag arguments for if each argument is supplied. This is
tricky to type in TR and so I was investigating why it did it this way. I
did a micro benchmark on another method of expansion and it was 60% faster.
Is there a reason that racket does it the current way that I am missing.

#lang racket

(define f
  (case-lambda
(() (f 1))
((a) (f a (+ 3 a)))
((a b) (f a b (* a b)))
((a b c) (f a b c (- a (/ c b
((a b c d) (+ a b c d

(define (g (a 1) (b (+ 3 a)) (c (* a b)) (d (- a (/ c b
  (+ a b c d))

(define N 100)

(collect-garbage)
(collect-garbage)
(time
  (for ((i (in-range N)))
(f i)))

(collect-garbage)
(collect-garbage)
(time
  (for ((i (in-range N)))
(g i)))


(collect-garbage)
(collect-garbage)
(time
  (for ((i (in-range N)))
(f i)))

(collect-garbage)
(collect-garbage)
(time
  (for ((i (in-range N)))
(g i)))

_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Fwd:

[J. Ian Johnson]

Uh, spam zombie to broken website?

Fatal error:  Call to undefined function: str_split() in 
/web/htdocs/www.radiovasco.com/home/j6ctxt.php on line 20
-Ian
- Original Message -
From: "Doug Williams" 
To: dev@racket-lang.org
Sent: Friday, February 8, 2013 4:11:12 PM GMT -05:00 US/Canada Eastern
Subject: [racket-dev] Fwd:

http://www.radiovasco.com/j6ctxt.php?s=lf

_
  Racket Developers list:
  http://lists.racket-lang.org/dev
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] [racket] When does 3D syntax get marshalled?

[J. Ian Johnson]

[Moving to dev]
The problem is with the implementation of splicing-syntax-parameterize, which 
turns the parameterization of p to #,new-tr into a TOP LEVEL define-syntax, 
which does NOT expand away, leading to this borkage. This calls for an mflatt.
-Ian
- Original Message -
From: "J. Ian Johnson" 
To: "J. Ian Johnson" 
Cc: "users" 
Sent: Tuesday, January 22, 2013 6:08:49 PM GMT -05:00 US/Canada Eastern
Subject: Re: [racket] When does 3D syntax get marshalled?

I found that this example does NOT work if you take the use of M out of its 
expression context. Problem program:

#lang racket
(require racket/stxparam racket/splicing)
(define-syntax-parameter p #f)
(define-syntax-rule (M id body)
(splicing-let-syntax
 ([id
   (let* ([p-tr (syntax-parameter-value #'p)]
  [new-tr (λ (syn) (syntax-case syn () [(_ e) (p-tr #'(foo e))]))])
 (λ (stx)
(syntax-case stx () [(_ blah)
 #`(splicing-syntax-parameterize ([p #,new-tr])
 (id blah))])))])
 body))
(define-syntax-rule (F x) (list x))
(splicing-syntax-parameterize ([p (syntax-rules () [(_ e) e])])
  (M F (F 'small-example)))

Thoughts?
-Ian
- Original Message -
From: "J. Ian Johnson" 
To: "J. Ian Johnson" 
Cc: "users" 
Sent: Tuesday, January 22, 2013 1:48:55 PM GMT -05:00 US/Canada Eastern
Subject: Re: [racket] When does 3D syntax get marshalled?

Here is a concrete example that is an outline of what I do. It works.
However, in my project, when I replace F with the form that I actually defined 
and mix in more for p's transformer, I get that new-tr cannot be marshalled in 
the compiled code. This baffles me.

#lang racket
(module A racket
  (require racket/stxparam racket/splicing)
  (provide M p)
  (define-syntax-parameter p #f)
  (define-syntax-rule (M id body)
(splicing-let-syntax
   ([id
 (let* ([p-tr (syntax-parameter-value #'p)]
[new-tr (λ (syn) (syntax-case syn () [(_ e) (p-tr #'(foo e 
#;mix-in-more-here))]))])
   (λ (stx)
  (syntax-case stx () [(_ blah)
   #`(splicing-syntax-parameterize ([p 
#,new-tr])
   (id blah #;mix-in-more-here))])))])
   body)))
(module B racket
  (require (submod ".." A) racket/splicing)
  (define-syntax-rule (F x) (list x))
  (splicing-syntax-parameterize ([p (syntax-rules () [(_ e) e])])
(printf "~a~%" (M F (F 'small-example)
(require 'B)

Very frustrating.
-Ian
- Original Message -
From: "J. Ian Johnson" 
To: "users" 
Sent: Tuesday, January 22, 2013 12:12:28 PM GMT -05:00 US/Canada Eastern
Subject: [racket] When does 3D syntax get marshalled?

I have a fairly crazy macro that chains together syntax transformers that are 
stored in syntax-parameters to get a sort of "macro mix-in" if you will. In 
order to do this, I have code that looks like the following:
(define old-tr (syntax-parameter-value #'p))
(define new-tr (syntax-parser [(_ blah) (old-tr #'(modified-blah))]))
(syntax-parser [(_ macro-in) #'(syntax-parameterize ([p #,new-tr]) macro-out)])

Often this works. However, I am now putting this kind of code inside of a 
let-syntax that is the product of a macro that is given the identifier to bind 
in the let-syntax. The use of this macro uses the bound identifier, which (in 
my head) should just use this transformer, expand away and not have to be 
marshalled. There is no documentation for the term "3D syntax" so I wasn't sure 
where I could read why my mental model is flawed.

So, what could be happening here that would cause the marshalling?

-Ian

  Racket Users list:
  http://lists.racket-lang.org/users

_
  Racket Developers list:
  http://lists.racket-lang.org/dev

[racket-dev] egal?

[J. Ian Johnson]

Short message: is there any chance of getting egal and egal hashes any time 
soon?

Longer message: I have a situation where I key my hashes with immutable 
structs, but something they contain has a box that later is updated and never 
changed. I'd really like for the struct value before the set-box! to be keyed 
to and positively compare to the value after this set-box! happens. Otherwise I 
have to do something abstraction-breaking to separate these boxes from the 
structures which would likely introduce more overhead (yet another hash lookup).

I'm going to look into just hacking egal in myself, but want to know what the 
other devs know about this.
Thanks,
-Ian
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

[racket-dev] And/or as procedures when not in application position

[J. Ian Johnson]

I just made a pull request for making and/or expand to functions that perform 
and/or following a discussion with stamourv and asumu. Vincent believes these 
additions should also be made to the student languages, but I thought I'd start 
a discussion about this before doing that work.
What are people's thoughts on this?
-Ian
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] splicing-syntax-parameterize and syntax-parameter-value

[J. Ian Johnson]

Thanks so much.
-Ian
- Original Message -
From: "Matthew Flatt" 
To: "J. Ian Johnson" 
Cc: "dev" 
Sent: Saturday, December 1, 2012 10:29:13 AM GMT -05:00 US/Canada Eastern
Subject: Re: [racket-dev] splicing-syntax-parameterize and 
syntax-parameter-value

Interesting problem. I almost gave up, but I think I've sorted it out
--- repair pushed.

At Thu, 29 Nov 2012 18:20:18 -0500 (EST), "J. Ian Johnson" wrote:
> Simpler example:
> 
> (require racket/splicing racket/stxparam)
> (define-syntax-parameter f #f)
> (define x 0)
> ;; 0
> (syntax-parameterize ([f (make-rename-transformer #'x)]) 
> (splicing-syntax-parameterize ([f (syntax-parameter-value #'f)]) f))
> ;; 0
> (splicing-syntax-parameterize ([f (make-rename-transformer #'x)]) 
> (syntax-parameterize ([f (syntax-parameter-value #'f)]) f))
> ;; error
> > (splicing-syntax-parameterize ([f (make-rename-transformer #'x)]) 
> (splicing-syntax-parameterize ([f (syntax-parameter-value #'f)]) f))
> stdin::334: f: bad syntax
>   in: f
>   context...:
>/home/ianj/racket/collects/racket/splicing.rkt:224:0
>/home/ianj/racket/collects/racket/splicing.rkt:177:0
>/home/ianj/racket/collects/racket/splicing.rkt:224:0
>/home/ianj/racket/collects/racket/splicing.rkt:177:0
>/home/ianj/racket/collects/racket/private/misc.rkt:87:7
> 
> -Ian
> - Original Message -
> From: "J. Ian Johnson" 
> To: "dev" 
> Sent: Thursday, November 29, 2012 4:01:09 PM GMT -05:00 US/Canada Eastern
> Subject: [racket-dev] splicing-syntax-parameterize and syntax-parameter-value
> 
> (require racket/stxparam racket/splicing)
> (define-syntax-parameter f #f)
> (splicing-syntax-parameterize ([f #t])
>   (begin-for-syntax (printf "~a~%" (syntax-parameter-value #'f)))
>   (void))
> 
> This prints #f.
> 
> If I instead add a macro indirection
> 
> (define-syntax (blah stx) (syntax-case stx () [(_ f) (printf "~a~%" 
> (syntax-parameter-value #'f)) #'(void)]))
> 
> Then
> 
> (splicing-syntax-parameterize ([f #t])
>   (blah f)
>   (void))
> 
> prints #t
> 
> This is messing up some of my syntax parameters that build their definitions 
> from the existing value in the parameter. Why does the first program have 
> this 
> behavior? This feels bug-like to me.
> -Ian

_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] splicing-syntax-parameterize and syntax-parameter-value

[J. Ian Johnson]

Simpler example:

(require racket/splicing racket/stxparam)
(define-syntax-parameter f #f)
(define x 0)
;; 0
(syntax-parameterize ([f (make-rename-transformer #'x)]) 
(splicing-syntax-parameterize ([f (syntax-parameter-value #'f)]) f))
;; 0
(splicing-syntax-parameterize ([f (make-rename-transformer #'x)]) 
(syntax-parameterize ([f (syntax-parameter-value #'f)]) f))
;; error
> (splicing-syntax-parameterize ([f (make-rename-transformer #'x)]) 
> (splicing-syntax-parameterize ([f (syntax-parameter-value #'f)]) f))
stdin::334: f: bad syntax
  in: f
  context...:
   /home/ianj/racket/collects/racket/splicing.rkt:224:0
   /home/ianj/racket/collects/racket/splicing.rkt:177:0
   /home/ianj/racket/collects/racket/splicing.rkt:224:0
   /home/ianj/racket/collects/racket/splicing.rkt:177:0
   /home/ianj/racket/collects/racket/private/misc.rkt:87:7

-Ian
----- Original Message -
From: "J. Ian Johnson" 
To: "dev" 
Sent: Thursday, November 29, 2012 4:01:09 PM GMT -05:00 US/Canada Eastern
Subject: [racket-dev] splicing-syntax-parameterize and syntax-parameter-value

(require racket/stxparam racket/splicing)
(define-syntax-parameter f #f)
(splicing-syntax-parameterize ([f #t])
  (begin-for-syntax (printf "~a~%" (syntax-parameter-value #'f)))
  (void))

This prints #f.

If I instead add a macro indirection

(define-syntax (blah stx) (syntax-case stx () [(_ f) (printf "~a~%" 
(syntax-parameter-value #'f)) #'(void)]))

Then

(splicing-syntax-parameterize ([f #t])
  (blah f)
  (void))

prints #t

This is messing up some of my syntax parameters that build their definitions 
from the existing value in the parameter. Why does the first program have this 
behavior? This feels bug-like to me.
-Ian
_
  Racket Developers list:
  http://lists.racket-lang.org/dev
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

[racket-dev] splicing-syntax-parameterize and syntax-parameter-value

[J. Ian Johnson]

(require racket/stxparam racket/splicing)
(define-syntax-parameter f #f)
(splicing-syntax-parameterize ([f #t])
  (begin-for-syntax (printf "~a~%" (syntax-parameter-value #'f)))
  (void))

This prints #f.

If I instead add a macro indirection

(define-syntax (blah stx) (syntax-case stx () [(_ f) (printf "~a~%" 
(syntax-parameter-value #'f)) #'(void)]))

Then

(splicing-syntax-parameterize ([f #t])
  (blah f)
  (void))

prints #t

This is messing up some of my syntax parameters that build their definitions 
from the existing value in the parameter. Why does the first program have this 
behavior? This feels bug-like to me.
-Ian
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] [plt] Push #25789: master branch updated

[J. Ian Johnson]

Thanks, Matthew. I should have added an empty set case too, since that 
allocates (as opposed to list and mlist). Submitted another pull request (this 
time with a test, sorry about that).
-Ian
- Original Message -
From: mfl...@racket-lang.org
To: dev@racket-lang.org
Sent: Thursday, November 29, 2012 9:20:22 AM GMT -05:00 US/Canada Eastern
Subject: [plt] Push #25789: master branch updated

mflatt has updated `master' from 15cbfa1947 to bd16f1e302.
  http://git.racket-lang.org/plt/15cbfa1947..bd16f1e302

=[ 4 Commits ]==
Directory summary:
  25.1% collects/racket/private/
  11.7% collects/racket/
  32.6% collects/scribble/
  10.3% collects/scribblings/main/private/
  20.1% collects/tests/racket/

~~

889f159 J. Ian Johnson  2012-11-28 13:05
:
| Singleton optimization for sequences that would allocate.
:
  M collects/racket/private/for.rkt | 6 --
  M collects/racket/set.rkt | 3 ++-

~~

6bfc03d Matthew Flatt  2012-11-29 06:57
:
| add tests for `in-list', `in-mlist', and `in-set' shortcut
:
  M collects/tests/racket/for.rktl | 4 
  M collects/tests/racket/set.rktl | 1 +

~~

d6b0dfc Sam Tobin-Hochstadt  2012-11-28 14:14
:
| Switch to use almost-standard DOCTYPE for Scribble.
|
| Also switches scribble search trampoline to standard DOCTYPE.
|
| Scribble's HTML output currently relies on the quirks-mode
| box model for layout of the many tables used in rendering.
| However, Scribble doesn't need the rest of the changes in
| browser quirks modes, so we choose a DOCTYPE that just
| changes the box model.
|
| It's non-obvious how to replicated this formatting with CSS
| in standard-mode rendering.  Probably a better long term
| solution is to move away from table-based layout.
|
| See further discussion on GitHub pull request 158 here:
|   https://github.com/plt/racket/pull/158
:
  M collects/scribble/scribble-prefix.html| 2 +-
  M collects/scribblings/main/private/search-context.html | 2 +-

~~

bd16f1e Matthew Flatt  2012-11-29 07:18
:
| scribble HTML: no extra breaking at the end of an identifier
:
  M collects/scribble/html-render.rkt | 2 +-

=[ Overall Diff ]===

collects/racket/private/for.rkt
~~~
--- OLD/collects/racket/private/for.rkt
+++ NEW/collects/racket/private/for.rkt
@@ -1725,7 +1725,8 @@
   (define-sequence-syntax *in-list
 (lambda () #'in-list)
 (lambda (stx)
-  (syntax-case stx ()
+  (syntax-case stx (list)
+[[(id) (_ (list expr))] #'[(id) (:do-in ([(id) expr]) #t () #t () #t 
#f ())]]
 [[(id) (_ lst-expr)]
  (for-clause-syntax-protect
   #'[(id)
@@ -1751,7 +1752,8 @@
   (define-sequence-syntax *in-mlist
 (lambda () #'in-mlist)
 (lambda (stx)
-  (syntax-case stx ()
+  (syntax-case stx (mlist)
+[[(id) (_ (mlist expr))] #'[(id) (:do-in ([(id) expr]) #t () #t () #t 
#f ())]]
 [[(id) (_ lst-expr)]
  (for-clause-syntax-protect
   #'[(id)

collects/racket/set.rkt
~~~
--- OLD/collects/racket/set.rkt
+++ NEW/collects/racket/set.rkt
@@ -308,7 +308,8 @@
 (define-sequence-syntax *in-set
   (lambda () #'in-set)
   (lambda (stx)
-(syntax-case stx ()
+(syntax-case stx (set)
+  [[(id) (_ (set expr))] #'[(id) (:do-in ([(id) expr]) #t () #t () #t #f 
())]]
   [[(id) (_ st)]
#`[(id)
   (:do-in

collects/scribble/html-render.rkt
~
--- OLD/collects/scribble/html-render.rkt
+++ NEW/collects/scribble/html-render.rkt
@@ -1385,7 +1385,7 @@
   (cond
 [(string? i)
  (let ([m (and (extra-breaking?)
-   (regexp-match-positions #rx"[-:/+_]|[a-z](?=[A-Z])" 
i))])
+   (regexp-match-positions 
#rx"[-:/+_](?=.)|[a-z](?=[A-Z])" i))])
(if m
  (list* (substring i 0 (cdar m))
 ;; Most browsers wrap after a hyphen. The one that

collects/scribble/scribble-prefix.html
~~
--- OLD/collects/scribble/scribble-prefix.html
+++ NEW/collects/scribble/scribble-prefix.html
@@ -1 +1 @@
-http://www.w3.org/TR/html4/loose.dtd";>
+http://www.w3.org/TR/html4/loose.dtd";>

collects/scribblings/main/private/search-context.html
~
--- OLD/collects/scribblings/main/private/search-context.html
+++ NEW/collects/scribblings/main/private/search-context.html
@@ -1,4 +1,4 @@
-http://www.w3.org/TR/html4/loose.dtd";>
+
 
 

Re: [racket-dev] for loop singleton optimization

[J. Ian Johnson]

That's not free-identifier=? so it wouldn't be optimized.
-Ian
- Original Message -
From: "Tobias Hammer" 
To: "Matthew Flatt" , "J. Ian Johnson" 
Cc: "dev" 
Sent: Thursday, November 29, 2012 4:49:15 AM GMT -05:00 US/Canada Eastern
Subject: Re: [racket-dev] for loop singleton optimization

What about

(let ([set (lambda (a) (set 1 2 a))])
   (for/list ([x (in-set (set 3))])
 x))

?

Tobias


On Wed, 28 Nov 2012 19:24:12 +0100, J. Ian Johnson   
wrote:

> Cool. I submitted a pull request with this change since it's always an  
> improvement.
> Thanks,
> -Ian
> - Original Message -
> From: "Matthew Flatt" 
> To: "J. Ian Johnson" 
> Cc: "dev" 
> Sent: Wednesday, November 28, 2012 12:58:09 PM GMT -05:00 US/Canada  
> Eastern
> Subject: Re: [racket-dev] for loop singleton optimization
>
> I think that would be an ad hoc optimization in each `in-'. For example,
>
> (define-sequence-syntax *in-set
>   (lambda () #'in-set)
>   (lambda (stx)
> (syntax-case stx ()
>   [[(id) (_ st)]
>
>
> in `racket/set' could change to
>
> (define-sequence-syntax *in-set
>   (lambda () #'in-set)
>   (lambda (stx)
>     (syntax-case stx (set)
>   [[(id) (_ (set v))]
>#`[(id) (in-value v)]]
>   [[(id) (_ st)]
>
>
>
> At Wed, 28 Nov 2012 12:50:49 -0500 (EST), "J. Ian Johnson" wrote:
>> It would be great to optimize singletons out of comprehensions, since I  
>> (and
>> probably others) have macros that expand into singleton constructors  
>> that are
>> much better suited to just be a rebinding.
>>
>> > (time (for ([n (in-range 1 100)]) (for ([k (in-set (set n))])  
>> (random
>> k
>> cpu time: 340 real time: 338 gc time: 16
>> > (time (for ([n (in-range 1 100)]) (for ([k (in-value n)]) (random  
>> k
>> cpu time: 120 real time: 118 gc time: 0
>>
>> Is this easily added to for.rkt?
>>
>> -Ian
>> _
>>   Racket Developers list:
>>   http://lists.racket-lang.org/dev
> _
>   Racket Developers list:
>   http://lists.racket-lang.org/dev


-- 
-
Tobias Hammer
DLR / Institute of Robotics and Mechatronics
Muenchner Str. 20, D-82234 Wessling
Tel.: 08153/28-1487
Mail: tobias.ham...@dlr.de
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] for loop singleton optimization

[J. Ian Johnson]

Cool. I submitted a pull request with this change since it's always an 
improvement.
Thanks,
-Ian
- Original Message -
From: "Matthew Flatt" 
To: "J. Ian Johnson" 
Cc: "dev" 
Sent: Wednesday, November 28, 2012 12:58:09 PM GMT -05:00 US/Canada Eastern
Subject: Re: [racket-dev] for loop singleton optimization

I think that would be an ad hoc optimization in each `in-'. For example,

(define-sequence-syntax *in-set
  (lambda () #'in-set)
  (lambda (stx)
(syntax-case stx ()
  [[(id) (_ st)]
   

in `racket/set' could change to

(define-sequence-syntax *in-set
  (lambda () #'in-set)
  (lambda (stx)
(syntax-case stx (set)
  [[(id) (_ (set v))]
   #`[(id) (in-value v)]]
  [[(id) (_ st)]
       ....


At Wed, 28 Nov 2012 12:50:49 -0500 (EST), "J. Ian Johnson" wrote:
> It would be great to optimize singletons out of comprehensions, since I (and 
> probably others) have macros that expand into singleton constructors that are 
> much better suited to just be a rebinding.
> 
> > (time (for ([n (in-range 1 100)]) (for ([k (in-set (set n))]) (random 
> k
> cpu time: 340 real time: 338 gc time: 16
> > (time (for ([n (in-range 1 100)]) (for ([k (in-value n)]) (random k
> cpu time: 120 real time: 118 gc time: 0
> 
> Is this easily added to for.rkt?
> 
> -Ian
> _
>   Racket Developers list:
>   http://lists.racket-lang.org/dev
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

[racket-dev] for loop singleton optimization

[J. Ian Johnson]

It would be great to optimize singletons out of comprehensions, since I (and 
probably others) have macros that expand into singleton constructors that are 
much better suited to just be a rebinding.

> (time (for ([n (in-range 1 100)]) (for ([k (in-set (set n))]) (random 
> k
cpu time: 340 real time: 338 gc time: 16
> (time (for ([n (in-range 1 100)]) (for ([k (in-value n)]) (random k
cpu time: 120 real time: 118 gc time: 0

Is this easily added to for.rkt?

-Ian
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Implementation of bit vectors

[J. Ian Johnson]

As I intend to use bitvectors to do fast set operations, and cardinality is a 
set operation, I wrote up a "fast count bits" function that should be rolled in 
for the vector implementation:
https://gist.github.com/4154642

It depends on the fixnum representation, so I don't imagine this being 
adaptable to the bignum implementation. Bignums would have to support this kind 
of thing natively, which I don't think is the case. However, if you know the 
bignum is a fixnum, you could use this.
-Ian
- Original Message -
From: "Matthew Flatt" 
To: "Jens Axel Søgaard" 
Cc: dev@racket-lang.org
Sent: Tuesday, November 27, 2012 9:28:28 AM GMT -05:00 US/Canada Eastern
Subject: Re: [racket-dev] Implementation of bit vectors

Nicely done. I've merged with minor changes, including renaming
`bit-vector-count' to `bit-vector-length' to be more consistent with
`vector' functions.

At Sat, 24 Nov 2012 20:33:12 +0100, Jens Axel Søgaard wrote:
> Hi All,
> 
> I have written an implementation of bit vectors intended to be part of
> the data collection.
> 
> https://github.com/plt/racket/pull/176
> 
> Any comments on the implementation and documentation are welcome.
> The bit vector is represented as a vector of fixnums (packaged in a
> struct of course).
> 
> --
> Jens Axel Søgaard
> 
> _
>   Racket Developers list:
>   http://lists.racket-lang.org/dev

_
  Racket Developers list:
  http://lists.racket-lang.org/dev

_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Experiments with closure conversion

[J. Ian Johnson]

I mean the difference between a constant closure that takes an extra vector 
argument for the environment and a Racket closure that has its own environment 
representation.
Lightweight closure conversion and super-beta inlining both need a way to 
access surrounding environments for the shared bindings, so it would be nice to 
just use Racket's own closure-ref (or whathaveyou) to do that rather than 
change all affected functions to use a different calling convention with 
vectors.
-Ian
- Original Message -
From: "Matthew Flatt" 
To: "J. Ian Johnson" 
Cc: "dev" , "J. Ian Johnson" 
Sent: Friday, November 23, 2012 8:54:58 AM GMT -05:00 US/Canada Eastern
Subject: Re: [racket-dev] Experiments with closure conversion

Sorry --- I don't understand what you mean by "lightweight closures use
the same representation".

If you convert a `lambda' so that it doesn't capture any variables ---
perhaps because you moved formerly captured variables to a vector
argument --- then the compiler will compile it as a constant closure
(or a module-level closure if it captures only module-level bindings).

The compiler will not detect that a particular argument of a function
is always a vector, that the vector is always size N, that the vector
always contains the values of N variables, and therefore that the
vector argument can be replaced by N arguments to avoid constructing
the vector.

At Wed, 21 Nov 2012 13:03:06 -0500 (EST), "J. Ian Johnson" wrote:
> Your answer sounds like we're on the same page, so I'll follow up. Is there 
> any 
> way to communicate with Racket's closure conversion so that lightweight 
> closures use the same representation? I would have to ensure that lightweight 
> closures never flow to functions that I myself don't have the ability to 
> transform to use the right calling convention.
> 
> Sharing is a separate optimization I am considering (Shao & Appel 2000)
> Thanks,
> -Ian
> - Original Message -
> From: "Matthew Flatt" 
> To: "J. Ian Johnson" 
> Cc: "dev" 
> Sent: Wednesday, November 21, 2012 12:56:09 PM GMT -05:00 US/Canada Eastern
> Subject: Re: [racket-dev] Experiments with closure conversion
> 
> I think I don't yet understand the question.
> 
> Are you wondering about what happens to performance of a Racket program
> when you convert the program's source before giving it to Racket? And
> you wonder specifically about performing lightweight closure conversion
> and how Racket will treat the converted program?
> 
> If so, since Racket has its own closure conversion, my guess is that
> manually managing your own conversions will perform less well. It seems
> possible, though, that you can convert a program so that it performs
> better by using vectors that effectively allow sharing among closures.
> 
> At Wed, 21 Nov 2012 11:56:11 -0500 (EST), "J. Ian Johnson" wrote:
> > I have a control-flow analysis of a subset of Racket that is similar to 
> > R4RS 
> > Scheme (only with immutability in the right places). In fact, I have many - 
> in 
> > order to compare different analyses' effectiveness and precision, I have a 
> > series of post-hoc analyses and program transformations I want to do.
> > 
> > One is lightweight closure conversion (Wand & Steckler 1996)
> > 
> > Is a source->source transform that uses immutable vectors for passed 
> > environments and unsafe references for variable lookups enough to get the 
> > Racket compiler to pick up on what I'm doing?
> > I'm really not quite sure which question to ask, since I haven't made my 
> > own 
> > higher-order language compiler top to bottom before, and don't know if 
> > there 
> > might be internal represenations that I'd need to use rather than 
> > user-level 
> > representations.
> > 
> > Thanks,
> > -Ian
> > _
> >   Racket Developers list:
> >   http://lists.racket-lang.org/dev
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Experiments with closure conversion

[J. Ian Johnson]

Your answer sounds like we're on the same page, so I'll follow up. Is there any 
way to communicate with Racket's closure conversion so that lightweight 
closures use the same representation? I would have to ensure that lightweight 
closures never flow to functions that I myself don't have the ability to 
transform to use the right calling convention.

Sharing is a separate optimization I am considering (Shao & Appel 2000)
Thanks,
-Ian
- Original Message -
From: "Matthew Flatt" 
To: "J. Ian Johnson" 
Cc: "dev" 
Sent: Wednesday, November 21, 2012 12:56:09 PM GMT -05:00 US/Canada Eastern
Subject: Re: [racket-dev] Experiments with closure conversion

I think I don't yet understand the question.

Are you wondering about what happens to performance of a Racket program
when you convert the program's source before giving it to Racket? And
you wonder specifically about performing lightweight closure conversion
and how Racket will treat the converted program?

If so, since Racket has its own closure conversion, my guess is that
manually managing your own conversions will perform less well. It seems
possible, though, that you can convert a program so that it performs
better by using vectors that effectively allow sharing among closures.

At Wed, 21 Nov 2012 11:56:11 -0500 (EST), "J. Ian Johnson" wrote:
> I have a control-flow analysis of a subset of Racket that is similar to R4RS 
> Scheme (only with immutability in the right places). In fact, I have many - 
> in 
> order to compare different analyses' effectiveness and precision, I have a 
> series of post-hoc analyses and program transformations I want to do.
> 
> One is lightweight closure conversion (Wand & Steckler 1996)
> 
> Is a source->source transform that uses immutable vectors for passed 
> environments and unsafe references for variable lookups enough to get the 
> Racket compiler to pick up on what I'm doing?
> I'm really not quite sure which question to ask, since I haven't made my own 
> higher-order language compiler top to bottom before, and don't know if there 
> might be internal represenations that I'd need to use rather than user-level 
> representations.
> 
> Thanks,
> -Ian
> _
>   Racket Developers list:
>   http://lists.racket-lang.org/dev
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

[racket-dev] Experiments with closure conversion

[J. Ian Johnson]

I have a control-flow analysis of a subset of Racket that is similar to R4RS 
Scheme (only with immutability in the right places). In fact, I have many - in 
order to compare different analyses' effectiveness and precision, I have a 
series of post-hoc analyses and program transformations I want to do.

One is lightweight closure conversion (Wand & Steckler 1996)

Is a source->source transform that uses immutable vectors for passed 
environments and unsafe references for variable lookups enough to get the 
Racket compiler to pick up on what I'm doing?
I'm really not quite sure which question to ask, since I haven't made my own 
higher-order language compiler top to bottom before, and don't know if there 
might be internal represenations that I'd need to use rather than user-level 
representations.

Thanks,
-Ian
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] [PATCH] Add a `zip' procedure to lists

[J. Ian Johnson]

[forgot reply all]
zip is unnecessary because of n-ary map.
(zip l0 l1) = (map list l0 l1)
-Ian
- Original Message -
From: "Diogo F. S. Ramos" 
To: dev@racket-lang.org
Sent: Thursday, November 8, 2012 11:46:15 PM GMT -05:00 US/Canada Eastern
Subject: [racket-dev] [PATCH] Add a `zip' procedure to lists

`zip' gathers together each element of each list, in order, returning
a list of those elements.

For example: (zip (list 4 2) (list 3 5)) => '((4 3) (2 5))

Every list has to have the same length.
---
There was talk in the IRC about implementing a `zip' procedure. Here
is my try.

Unfortunately I still don't know what is the preferred way to check
for the validity of the parameters. I tried to copy the style of the
rest of the file.

 collects/racket/list.rkt |9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/collects/racket/list.rkt b/collects/racket/list.rkt
index fe32f68..18055e5 100644
--- a/collects/racket/list.rkt
+++ b/collects/racket/list.rkt
@@ -32,7 +32,8 @@
  append-map
  filter-not
  shuffle
- range)
+ range
+ zip)
 
 (define (first x)
   (if (and (pair? x) (list? x))
@@ -407,3 +408,9 @@
 [(end)(for/list ([i (in-range end)])i)]
 [(start end)  (for/list ([i (in-range start end)])  i)]
 [(start end step) (for/list ([i (in-range start end step)]) i)]))
+
+(define (zip list1 list2 . lists)
+  (for ((l (list* list1 list2 lists)))
+(unless (list? l)
+  (raise-argument-error 'zip "list?" l)))
+  (apply map list (list* list1 list2 lists)))
-- 
1.7.9.5

_
  Racket Developers list:
  http://lists.racket-lang.org/dev
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

[racket-dev] Odd bug with begin0 and call-with-values

[J. Ian Johnson]

Code that used to work is now failing with a pull of the master today. I can't 
reproduce it in small amounts of code, which makes me think it's another weird 
JIT problem.

I have a harness of this kind:
(define (print-values . vs) (for ([v vs]) (display v) (newline)))
 (with-limits 3600 4096 (call-with-values (lambda () (begin0 (time (analysis 
program)) (dump-memory-stats))) print-values)

The dump is not reached. Instead, (analysis program) finishes with the expected 
number of values, and once those values pass out of the expression, I get an 
error of the following kind:
exn:fail:contract:arity

It expects 1 value instead of the arbitrary amount it should expect for the 
print-values.
I can supply a large amount of code that exercises this behavior, but if this 
is enough to go off, great.
Thanks,
-Ian
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

[racket-dev] set! and provided macros

[J. Ian Johnson]

If a macro provided by a module uses set! in its expansion, then a use in 
another module will cause a "cannot mutate module-required identifier" error, 
even if the identifier is not provided. It's easy enough for me to write a 
setter function and expand to that.

I can see that it is undecidable in general to determine if a macro will expand 
into a set! of a module's identifier so that the "no set!" optimizations would 
be completely killed.
I would like to see a different error in this case (e.g. "set! in foreign 
module macro expansions prohibited"), if that is an easily detected case, that 
is.

-Ian
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

[racket-dev] Where might I find undocumented un-greppable primitives?

[J. Ian Johnson]

(open-input-file file-name)
=maacros=>
(let ((file-name1 file-name))
   (if (variable-reference-constant? open-input-file6)
 (open-input-file4 '#f '#f file-name1)
 (open-input-file6 file-name1)))

These identifiers are nowhere. I imagine these will be the first of many crazy 
things I'll run into during my implementation.

What/where are they? I'm trying to make a sound analysis/small step semantics 
here.
Thanks,
-Ian
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] GC segfault

[J. Ian Johnson]

This fixes the problem. You are magic.
-Ian
- Original Message -
From: "Matthew Flatt" 
To: "J. Ian Johnson" 
Cc: "dev" 
Sent: Tuesday, October 23, 2012 2:44:35 PM GMT -05:00 US/Canada Eastern
Subject: Re: [racket-dev] GC segfault

Thanks for the example! I've pushed a repair for a recent JIT change
that inlines structure allocation. Let me know if it doesn't solve the
problem.

At Tue, 23 Oct 2012 07:30:20 -0700, Matthew Flatt wrote:
> Smaller examples are better, but anything that I can run may be
> helpful.
> 
> At Tue, 23 Oct 2012 10:08:56 -0400 (EDT), "J. Ian Johnson" wrote:
> > Every time I run my newly finished analysis on a benchmark, it crashes with
> > 
> > Seg fault (internal error during gc) at 0x7fce50d3d010
> > SIGSEGV SEGV_ACCERR SI_CODE 2 fault on 0x7fce50d3d010
> > Aborted (core dumped)
> > 
> > What extra info can I give to help diagnose the problem? The full source 
> > code 
> > is not likely to be illuminating.
> > (tried in 5.3.1.1 and a pull from 15 minutes ago)
> > -Ian
> > _
> >   Racket Developers list:
> >   http://lists.racket-lang.org/dev
> _
>   Racket Developers list:
>   http://lists.racket-lang.org/dev
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

[racket-dev] GC segfault

[J. Ian Johnson]

Every time I run my newly finished analysis on a benchmark, it crashes with

Seg fault (internal error during gc) at 0x7fce50d3d010
SIGSEGV SEGV_ACCERR SI_CODE 2 fault on 0x7fce50d3d010
Aborted (core dumped)

What extra info can I give to help diagnose the problem? The full source code 
is not likely to be illuminating.
(tried in 5.3.1.1 and a pull from 15 minutes ago)
-Ian
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

[racket-dev] for/Type forms -> for/fold ([#:type type]) ...

[J. Ian Johnson]

I'm fairly frustrated every time I have to write
(for/fold ([res outer-set]) (guards ...) (set-add res (let () body ...)))

instead of the nicer
(for/set #:initial outer-set (guards ...) body ...)

I have also found myself wanting an analog to this for the for/hash form, since 
I extend hashes often in loops.
I almost wrote an email earlier asking for a #:default for the for/vector form, 
but I see that the pre-release has a #:fill. This is good.

Taking a closer look at the other for/* forms, it doesn't make sense to have an 
analog for the for/list* forms, since you might want to do the true recursive 
thing and add to the base list, or reverse the base list first and do the 
tail-recursive thing. Supporting both of these seems excessive.

There are also occasions that I want to give the accumulator a name that I can 
refer to.

This all fits a pattern that I think would be great for the for forms: 
user-defined accumulators. That is, instead of writing
(for/set (guards ...) body ...)

we could also write
(for/fold ([#:type set]) (guards ...) body ...)
or optionally
(for/fold ([#:type set [accumulator initial-value]]) (guards ...) body ...)
(for/fold ([#:type set accumulator]) (guards ...) body ...)
(for/fold ([#:type set #:initial initial-value]) (guards ...) body ...)

Now (for/lists (lst ...) gs b ...)is
(for/fold ([#:type list lst] ...) gs b ...)

This would allow for different positions in the values returned by body to be 
accumulated differently, according to the user-defined accumulator transform, 
and then managed after the loop by a post-process transform (to account for 
reversing the accumulated list in for/list, say). These would be associated 
with the syntax value of the type identifier.

I've rolled my own specialized forms of for/fold that handle different 
positions according to a special type, but I think it's time to extend the idea.

Does anyone else share my plight?

Also, samth: still waiting on your for/X/match macros to be released.
-Ian
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Math library initial commit almost ready; comments on issues welcome

[J. Ian Johnson]

The high level is that the predicate with identifier given by 
build-struct-names should have the same purity/predicate properties of 
something like string?. As for not, it's just an alias for false?, so it should 
have the same info again.
-Ian
- Original Message -
From: "Sam Tobin-Hochstadt" 
To: "J. Ian Johnson" 
Cc: "dev" , "Neil Toronto" 
Sent: Tuesday, October 2, 2012 10:02:50 AM GMT -05:00 US/Canada Eastern
Subject: Re: [racket-dev] Math library initial commit almost ready; comments on 
issues welcome

On Tue, Oct 2, 2012 at 9:55 AM, J. Ian Johnson  wrote:
> This surprises me, since not and make-struct-type are in '#%kernel, they 
> should have this kind of information baked in, without a purity analysis.

If you're suggesting that the Racket compiler should perform the
purity analysis, then that would be nice, but it would be harder,
since it would require recording information for the output of
`make-struct-type`. Typed Racket has information about structures at a
higher level.

> -Ian
> - Original Message -
> From: "Sam Tobin-Hochstadt" 
> To: "Neil Toronto" 
> Cc: "" 
> Sent: Tuesday, October 2, 2012 9:44:13 AM GMT -05:00 US/Canada Eastern
> Subject: Re: [racket-dev] Math library initial commit almost ready; comments 
> on issues welcome
>
> On Mon, Oct 1, 2012 at 9:44 PM, Neil Toronto  wrote:
>> The only bit that bothers me is the (begin (not (flonum-wrapper? x)) ...)
>> stuff left lying around after TR's optimizer eliminates the branches in the
>> expansions of `fw+'. IIRC, they cause futures to sync, but I'm going to
>> believe that they won't always - or will be optimized away - just so I can
>> have a decent solution to the typed macro problem.
>
> This code is left around because TR can't prove that `not` and
> `flonum-wrapper?` are pure functions.  Eventually, TR should include a
> purity analysis that can fix this, but it can't do that now.
>
> The fact that basically all structure operations are future-unsafe is
> a bigger issue.  I talked to James about it at ICFP, but I don't know
> what would be required to improve the situation.
> --
> sam th
> sa...@ccs.neu.edu
> _
>   Racket Developers list:
>   http://lists.racket-lang.org/dev



-- 
sam th
sa...@ccs.neu.edu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Falling through cond clauses

[J. Ian Johnson]

This experiment should be easy to run, no? Change the default cond and run DrDr?
-Ian
- Original Message -
From: "Carl Eastlund" 
To: "Racket Developers" 
Sent: Tuesday, October 2, 2012 9:52:38 AM GMT -05:00 US/Canada Eastern
Subject: [racket-dev] Falling through cond clauses


I often wish cond would raise an exception if all the tests failed and there 
were no else clause. I have taken to writing a macro to enforce this; I usually 
call it cond!. The void default for cond seems like an un-Racketish holdover 
from primarily-imperative programming. With some of the other changes we've 
made in Racket, are we willing to consider changing the fall-through behavior 
of cond? It seems like an experiment worth running to me. 

If not, I would at least like to add an erroring version of cond somewhere in 
the language. It's a shame to have to keep writing such a primitive feature. 
Right now in my dracula github repo I have cond! implemented in racket/cond and 
re-exported from racket, but I'm not thrilled about either the location or the 
name. I kept it out of racket/base so I could depend on the syntax collection 
for good source location reporting in the error message. 

Carl Eastlund 

_
  Racket Developers list:
  http://lists.racket-lang.org/dev
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Math library initial commit almost ready; comments on issues welcome

[J. Ian Johnson]

This surprises me, since not and make-struct-type are in '#%kernel, they should 
have this kind of information baked in, without a purity analysis.
-Ian
- Original Message -
From: "Sam Tobin-Hochstadt" 
To: "Neil Toronto" 
Cc: "" 
Sent: Tuesday, October 2, 2012 9:44:13 AM GMT -05:00 US/Canada Eastern
Subject: Re: [racket-dev] Math library initial commit almost ready; comments on 
issues welcome

On Mon, Oct 1, 2012 at 9:44 PM, Neil Toronto  wrote:
> The only bit that bothers me is the (begin (not (flonum-wrapper? x)) ...)
> stuff left lying around after TR's optimizer eliminates the branches in the
> expansions of `fw+'. IIRC, they cause futures to sync, but I'm going to
> believe that they won't always - or will be optimized away - just so I can
> have a decent solution to the typed macro problem.

This code is left around because TR can't prove that `not` and
`flonum-wrapper?` are pure functions.  Eventually, TR should include a
purity analysis that can fix this, but it can't do that now.

The fact that basically all structure operations are future-unsafe is
a bigger issue.  I talked to James about it at ICFP, but I don't know
what would be required to improve the situation.
-- 
sam th
sa...@ccs.neu.edu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Short-circuiting comprehensions

[J. Ian Johnson]

+1
I've been using let/ec for this same functionality, and it's made me sad.
-Ian
- Original Message -
From: "Carl Eastlund" 
To: "Matthew Flatt" 
Cc: "PLT Developers" 
Sent: Friday, September 14, 2012 11:49:20 AM GMT -05:00 US/Canada Eastern
Subject: Re: [racket-dev] Short-circuiting comprehensions


I agree that #:while and #:until are easily confused with #:when and #:unless. 
I slightly prefer #:stop- to #:break- as a prefix here, it seems a more natural 
word. I like the idea of allowing these clauses at the end of the body to give 
a notion of stopping after the current iteration. I had been wondering how to 
do that, and hadn't come up with anything nearly so simple. 

On Fri, Sep 14, 2012 at 11:40 AM, Matthew Flatt < mfl...@cs.utah.edu > wrote: 



I think this is a good idea. The technique to implement it is embedded 
in `for/vector' (to handle a vector length), and I can generalize that 
and move it into `for...'. 

Also, I think the names `#:while' and `#:until' are too close to 
`#:when' and `#:unless'. I suggest `#:break-when' and `#:break-unless'. 
Compare: 

> (for*/list ([j 2] [i 10] #:when (i . < . 5)) i) 
'(0 1 2 3 4 0 1 2 3 4) 
> (for*/list ([j 2] [i 10] #:break-unless (i . < . 5)) i) 
'(0 1 2 3 4) 

I imagine that `#:break-when' and `#:break-unless' are allowed among 
the clauses much like `#:when' and `#:unless', but also allowed at the 
end of the body. Is that what you had in mind? 



At Fri, 14 Sep 2012 10:09:52 -0400, Carl Eastlund wrote: 
> I would like the for/... comprehension macros to have #:while and #:until 
> clauses similar to the #:when and #:unless clauses. I often find I want to 
> short-circuit the sequence at some point, but there is no elegant way to do 
> it. I could probably write sequence-while and sequence-until, but I don't 
> want to move this condition into the sequence any more than I want to write 
> sequence-filter instead of #:when or #:unless. 
> 
> Has this been brought up before? I can't recall. Does anyone else run 
> into the same issue? 
> 
> Carl Eastlund 
> _ 
> Racket Developers list: 
> http://lists.racket-lang.org/dev 



_
  Racket Developers list:
  http://lists.racket-lang.org/dev
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Wrapping loops for TR isn't working, and the type annotations are for the wrong value

[J. Ian Johnson]

- Original Message -
From: "Neil Toronto" 
To: "Sam Tobin-Hochstadt" 
Cc: "" 
Sent: Wednesday, August 15, 2012 10:36:36 AM GMT -05:00 US/Canada Eastern
Subject: Re: [racket-dev] Wrapping loops for TR isn't working, and the type 
annotations are for the wrong value

On 08/15/2012 08:05 AM, Sam Tobin-Hochstadt wrote:
> On Wed, Aug 15, 2012 at 9:54 AM, Neil Toronto  wrote:
>> When #:length is given, it's similar in that it creates a vector outside the
>> loop and bangs values into it. But I have to start with (define vs (vector))
>> and then (set! vs (make-vector n v)) when the first value `v' is computed.
>> The docs for `for/vector' say any values not computed in the loop are
>> supposed to be 0, but that doesn't work well in TR: it'd have to create a
>> (Vectorof (U T 0)). Ick.
>
> So then the first value computed is replicated everywhere?  That seems
> unappealing as well.

>It costs nothing, and if the #:length argument matches the number of 
>iterations, the user never sees it.

Not so, it costs memory leaks if the first value would otherwise be garbage 
collected.
-Ian

_
  Racket Developers list:
  http://lists.racket-lang.org/dev
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Should I expect this program to typecheck?

[J. Ian Johnson]

I don't get the type Any, rather it doesn't know how to go from the union of 
vectors to a (vector a) for some a. Vector ref expects a vector, not a union of 
vectors, and because vectors are invariant, it cannot simplify this to (vector 
Integer).
-Ian
- Original Message -
From: "Neil Toronto" 
To: "J. Ian Johnson" 
Cc: "dev" 
Sent: Monday, August 6, 2012 5:07:38 PM GMT -05:00 US/Canada Eastern
Subject: Re: [racket-dev] Should I expect this program to typecheck?

I can't distinguish the elements' types in the simplified example I 
gave. The code I'm actually working on is this:

(: check-array-indexes (Symbol (Vectorof Index)
(U (Vectorof Index) (Vectorof Integer))
-> (Vectorof Index)))
(define (check-array-indexes name ds js)
   (define (raise-index-error)
 (error name "expected indexes for shape ~e; given ~e" ds js))
   (define dims (vector-length ds))
   (unless (= dims (vector-length js)) (raise-index-error))
   (define: new-js : (Vectorof Index) (make-vector dims 0))
   (let loop ([#{i : Nonnegative-Fixnum} 0])
 (cond [(i . < . dims)
(define di (vector-ref ds i))
(define ji (vector-ref js i))
(cond [(and (0 . <= . ji) (ji . < . di))
   (vector-set! new-js i ji)
   (loop (+ i 1))]
  [else  (raise-index-error)])]
   [else  new-js])))

I get type errors on every expression involving `ji', because TR has 
determined that it has type `Any'.

I would use a `case->' type, but I have an array transformation function 
that receives an argument with type

   ((Vectorof Index) -> (U (Vectorof Integer) (Vectorof Index)))

whose output has to be bounds-checked by `check-array-indexes', and I 
can't apply a function with a case type to an argument with a union type.

The question will of course be moot when TR has something like a `Const' 
type constructor. I'm anticipating that, and changing the user-facing 
array API to receive (U (Vectorof Integer) (Vectorof Index)) for array 
indexes instead of (Listof Integer). (It should eventually be (Const 
(Vectorof Integer)) or similar, which should be covariant.)

So are the type errors an error in TR, or a known limitation?

Neil ⊥


On 08/06/2012 02:25 PM, J. Ian Johnson wrote:
> How do you determine the difference between the two vector types is the 
> question...
> -Ian
> - Original Message -
> From: "Neil Toronto" 
> To: "" 
> Sent: Monday, August 6, 2012 4:12:53 PM GMT -05:00 US/Canada Eastern
> Subject: [racket-dev] Should I expect this program to typecheck?
>
> #lang typed/racket
>
> (: vector-first (All (A B) ((U (Vectorof A) (Vectorof B)) -> (U A B
> (define (vector-first vs)
> (vector-ref vs 0))
>
>
> I can't think of a reason this shouldn't work, but I may not be taxing
> my imagination enough to come up with one.
>
> Neil ⊥
> _
>Racket Developers list:
>http://lists.racket-lang.org/dev
>


_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Should I expect this program to typecheck?

[J. Ian Johnson]

How do you determine the difference between the two vector types is the 
question...
-Ian
- Original Message -
From: "Neil Toronto" 
To: "" 
Sent: Monday, August 6, 2012 4:12:53 PM GMT -05:00 US/Canada Eastern
Subject: [racket-dev] Should I expect this program to typecheck?

#lang typed/racket

(: vector-first (All (A B) ((U (Vectorof A) (Vectorof B)) -> (U A B
(define (vector-first vs)
   (vector-ref vs 0))


I can't think of a reason this shouldn't work, but I may not be taxing 
my imagination enough to come up with one.

Neil ⊥
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Redex for abstract machines / analysis prototypes

[J. Ian Johnson]

That line is how I would render the lookup rule for the CEK machine (in the 
below example).
I actually use \equiv to match structure instead of = in this LHS:

s{C \equiv x, E \equiv rho}

That is, I say that for whatever is in C, there exists an x of the type of x's 
nonterminal (in this case variable-not-otherwise-mentioned) such that C = x. 
This kind of implicit quantification is not always necessary. Indeed, others 
might lift the existential quantification over the entire reduction relation 
definition and make them universal. That said, I think that a visual 
distinction between matching and rewriting is important.

And I use braces to note selection of multiple fields. For a single field 
(let's say E), I would say

s.E

This selection is also written a different way in some texts (indeed in a draft 
I've written) as

E_s

Though cascading nesting leads to vanishingly small notation. I thus abandoned 
that notation.

As for the RHS, I use brackets and := to note substitutions. Usual substitution 
notation like e[v/x] has been ambiguous across texts (are we substituting v for 
x or x for v?) and its extension to many substitutions is also comma separated. 
Seeing as a field of a record should not be considered an identifier, lambda 
calculus-style substitution notation makes less sense.

As for the "rho(x)" in the "where" clause, I treat finite maps as primitive in 
most of by machines, and I lament having to escape to hash-ref or hash-set. 
Thus I suggested a special form for environment look-ups and functional 
extension. In fact that reminds me of another piece of notation I use.

Suppose I have a starting store sigma, and I construct what I see as the 
extension to sigma due to many allocations in one step, sigma'. To denote the 
store that is sigma with all mappings of sigma' preferred before going to 
sigma, I write

sigma \triangleleft sigma'

I would also want to override that notation, since when I move to an abstract 
interpretation, that would become a join,

sigma \sqcup sigma'

This is just how I note such record/environment manipulations. I would be 
interested if any other heavy users of Redex for machine semantics have a 
different opinion.

-Ian

----- Original Message -
From: "Robby Findler" 
To: "J. Ian Johnson" 
Cc: "dev" , n...@ccs.neu.edu
Sent: Wednesday, June 20, 2012 9:20:35 AM GMT -05:00 US/Canada Eastern
Subject: Re: [racket-dev] Redex for abstract machines / analysis prototypes

On Wed, Jun 20, 2012 at 7:48 AM, J. Ian Johnson  wrote:
> My papers have been using record notation. Say for lookup:
> s{C = x, E = rho} --> s[C := v, E := rho_0] where rho(x) = (v rho_0)

Can you explain this line in a little more detail?

> Is this not good enough?

I don't think I said it wasn't.

Robby

> -Ian
> - Original Message -
> From: Robby Findler 
> To: J. Ian Johnson 
> Cc: dev , n...@ccs.neu.edu
> Sent: Wed, 20 Jun 2012 01:27:18 -0400 (EDT)
> Subject: Re: [racket-dev] Redex for abstract machines / analysis prototypes
>
> I have thought about adding something that would solve this problem to
> Redex off and on for a few years and am circling something I think is
> reasonable. (The main thing I think you've not considered below is how
> to typeset things, but that said I have in mind something similar in
> spirit to what you write.)
>
> Unfortunately, I don't see myself getting to it in the short term (ie
> the coming month or two), but your message will definitely move it up
> on my list.
>
> Robby
>
> On Tue, Jun 19, 2012 at 6:08 PM, J. Ian Johnson  wrote:
>> Machine semantics for real machines (like the JVM or Racket's VM) or 
>> non-standard semantics for an abstract interpretation (like what I end up 
>> getting into) can get up to monstrous numbers of components for each state 
>> that usually don't matter. I and I'm sure many others would appreciate a 
>> reduction relation language that is a little more like UIUC's K.
>>
>> Here is a concrete suggestion of what I imagine (some support for patterns 
>> on hashes):
>> 1) Add a pattern (hash (literal pat) ...) to match hashes up to the 
>> specified keys (hashes with more keys are still accepted).
>> 2) Add rewrite rules for changing the current state.
>> -- (next-state (r r) ...)
>> -- (get r r)
>> -- (set r r r)
>> -- (set* r (r r) ...)
>> Where
>> (get r_0 r_1) is ,(hash-ref (term r_0) (term r_1) 
>> 'something-that-never-matches)
>> (set r_0 r_1 r_2) is ,(hash-set (term r_0) (term r_1) (term r_2))
>> (set* r_0 (r_k r_v) ...) is the obvious extension of set, but is annoying to 
>> write.
>> And assuming the LHS is named state,
>>  (next-state (r_k r_v) ...) is (set* state (r_

Re: [racket-dev] Redex for abstract machines / analysis prototypes

[J. Ian Johnson]

My papers have been using record notation. Say for lookup:
s{C = x, E = rho} --> s[C := v, E := rho_0] where rho(x) = (v rho_0)
Is this not good enough?
-Ian
- Original Message -
From: Robby Findler 
To: J. Ian Johnson 
Cc: dev , n...@ccs.neu.edu
Sent: Wed, 20 Jun 2012 01:27:18 -0400 (EDT)
Subject: Re: [racket-dev] Redex for abstract machines / analysis prototypes

I have thought about adding something that would solve this problem to
Redex off and on for a few years and am circling something I think is
reasonable. (The main thing I think you've not considered below is how
to typeset things, but that said I have in mind something similar in
spirit to what you write.)

Unfortunately, I don't see myself getting to it in the short term (ie
the coming month or two), but your message will definitely move it up
on my list.

Robby

On Tue, Jun 19, 2012 at 6:08 PM, J. Ian Johnson  wrote:
> Machine semantics for real machines (like the JVM or Racket's VM) or 
> non-standard semantics for an abstract interpretation (like what I end up 
> getting into) can get up to monstrous numbers of components for each state 
> that usually don't matter. I and I'm sure many others would appreciate a 
> reduction relation language that is a little more like UIUC's K.
>
> Here is a concrete suggestion of what I imagine (some support for patterns on 
> hashes):
> 1) Add a pattern (hash (literal pat) ...) to match hashes up to the specified 
> keys (hashes with more keys are still accepted).
> 2) Add rewrite rules for changing the current state.
> -- (next-state (r r) ...)
> -- (get r r)
> -- (set r r r)
> -- (set* r (r r) ...)
> Where
> (get r_0 r_1) is ,(hash-ref (term r_0) (term r_1) 
> 'something-that-never-matches)
> (set r_0 r_1 r_2) is ,(hash-set (term r_0) (term r_1) (term r_2))
> (set* r_0 (r_k r_v) ...) is the obvious extension of set, but is annoying to 
> write.
> And assuming the LHS is named state,
>  (next-state (r_k r_v) ...) is (set* state (r_k r_v) ...)
>
> Not-the-best-example-since-it's-so-minimal:
>
> (define-language CEK
>  [e x (e e) lam]
>  [lam (lambda (x) e)]
>  [rho (hash)]
>  [kont mt (ar e rho kont) (fn e rho kont))])
>
> (define R
>  (machine-step CEK
>  [--> (hash (C x) (E rho))
>       (next-state (C lam) (E rho*))
>       (where (lam rho*) (get rho x))]
>
>  [--> (hash (C (e_0 e_1)) (E rho) (K kont))
>       (next-state (C e_0) (K (ar e_1 rho kont)))]
>
>  [--> (hash (C lam) (E rho) (K (ar e rho_0 kont)))
>       (next-state (C e) (E rho_0) (K (fn lam rho kont)))]
>
>  [--> (hash (C v) (K (fn (lambda (x) e) rho kont)))
>       (next-state (C e) (E (set rho x (v rho))) (K kont))]))
>
> (define (inject e) (term (set* #hash() (C ,e) (E #hash()) (K mt
>
> Is this reasonably simple to add to Redex? It would be a very welcome 
> addition.
> -Ian
> _
>  Racket Developers list:
>  http://lists.racket-lang.org/dev


_
  Racket Developers list:
  http://lists.racket-lang.org/dev

[racket-dev] Redex for abstract machines / analysis prototypes

[J. Ian Johnson]

Machine semantics for real machines (like the JVM or Racket's VM) or 
non-standard semantics for an abstract interpretation (like what I end up 
getting into) can get up to monstrous numbers of components for each state that 
usually don't matter. I and I'm sure many others would appreciate a reduction 
relation language that is a little more like UIUC's K.

Here is a concrete suggestion of what I imagine (some support for patterns on 
hashes):
1) Add a pattern (hash (literal pat) ...) to match hashes up to the specified 
keys (hashes with more keys are still accepted).
2) Add rewrite rules for changing the current state.
-- (next-state (r r) ...)
-- (get r r)
-- (set r r r)
-- (set* r (r r) ...)
Where 
(get r_0 r_1) is ,(hash-ref (term r_0) (term r_1) 'something-that-never-matches)
(set r_0 r_1 r_2) is ,(hash-set (term r_0) (term r_1) (term r_2))
(set* r_0 (r_k r_v) ...) is the obvious extension of set, but is annoying to 
write.
And assuming the LHS is named state,
 (next-state (r_k r_v) ...) is (set* state (r_k r_v) ...)

Not-the-best-example-since-it's-so-minimal:

(define-language CEK
 [e x (e e) lam]
 [lam (lambda (x) e)]
 [rho (hash)]
 [kont mt (ar e rho kont) (fn e rho kont))])

(define R
 (machine-step CEK
  [--> (hash (C x) (E rho))
   (next-state (C lam) (E rho*))
   (where (lam rho*) (get rho x))]

  [--> (hash (C (e_0 e_1)) (E rho) (K kont))
   (next-state (C e_0) (K (ar e_1 rho kont)))]

  [--> (hash (C lam) (E rho) (K (ar e rho_0 kont)))
   (next-state (C e) (E rho_0) (K (fn lam rho kont)))]

  [--> (hash (C v) (K (fn (lambda (x) e) rho kont)))
   (next-state (C e) (E (set rho x (v rho))) (K kont))]))

(define (inject e) (term (set* #hash() (C ,e) (E #hash()) (K mt

Is this reasonably simple to add to Redex? It would be a very welcome addition.
-Ian
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] `racket/string' extensions

[J. Ian Johnson]

I'm a bit surprised list-index doesn't take an equality function.
-Ian
- Original Message -
From: Eli Barzilay 
To: dev@racket-lang.org
Sent: Thu, 24 May 2012 16:45:26 -0400 (EDT)
Subject: Re: [racket-dev] `racket/string' extensions

About a month ago, Eli Barzilay wrote:
> [...]

This is now almost completely implemented.  If you have any comments
on the below, now would be a good time.

The two things that I didn't do yet are the following (I'm still not
sure about the names and the functionality):

>   (string-index str sub [start 0] [end (string-length str)])
> Looks for occurrences of `sub' in `str', returns the index if
> found, #f otherwise.  [*2*] I'm not sure about the name, maybe
> `string-index-of' is better?
> 
>   (list-index list elt)
> Looks for `elt' in `list'.  This is a possible extension for
> `racket/list' that would be kind of obvious with adding the above.
> [*3*] I'm not sure if it should be added, but IIRC it was
> requested a few times.  If it does get added, then there's another
> question for how far the analogy goes: [*3a*] Should it take a
> start/end index too?  [*3b*] Should it take a list of elements and
> look for a matching sublist instead (which is not a function that
> is common to ask for, AFAICT)?

I might start a separate thread on suggestions for this and more
needed functions in `racket/list'.


To summarize the new things:

* (string-join strs [sep " "])

  The new thing here is that the `sep' argument now defaults to a
  space.  This is something that is often done in such functions
  elsewhere (including in srfi-1, IIRC), and with the below functions
  working with spaces by default it seems like the right thing.

* (string-trim str [sep #px"\\s+"]
   #:left? [l? #t] #:right? [r? #t] #:repeat? [+? #f])

  Trims spaces at the edges of the string.  Two notes:

  1. The default for `#:repeat?' is just #f -- an option that I
 suggested at some point would be to have it be true if `sep' is
 given as a string:

   (string-trim str [sep #px"\\s+"] ...
#:repeat? [+? (string? str)])

 The problem with that is that it makes it less uniform, and I can
 see cases where such a behavior can be undesired.  (For non
 whitespace separators and separators that are longer than one
 character.)

  2. Another subtle point is what should these return:

   (string-trim "aaa" "aa")
   (string-trim "ababa" "aba")

 After deliberating on that, I eventually made it return ""
 because it seems like that would be more expected.  (But that's
 really a subtle point, since multi-character string separators
 are very rare anyway.)  I also looked into several of these
 functions, but there's no precedent that I've seen either way.
 (In many cases it uses a regexp or uses the `sep' string as a bag
 of characters.)

 As a corollary of this, I thought that it might also mean that
 this should happen:

   (string-split "x---y---z" "--") => '("x" "y" "z")

 but in this case it looks like this wouldn't be expected.
 Perhaps a hand-wavy proof of this is that coding this behavior
 would take a little effort (need to look for all occurrences of
 the pattern) whereas in the `string-trim' case the above is very
 easy (find the start and end, return "" if start >= end).

* (string-split str [sep #px"\\s+"] #:trim? [trim? #t] #:repeat? [+? #f])

  As discussed.

* (string-normalize-spaces str [sep #px"\\s+"] [space " "]
   #:trim? [trim? #t] #:repeat? [+? #f])

  I ended up keeping the name of this.  Also, it's easy to implement
  directly as

(string-join (string-split str sep ...) space)

* (string-replace str from to #:all? [all? #t])

  As discussed -- note the different argument order (like I said, the
  focus of these things is the string).  I initially had two functions,
  `string-replace' and `string-replace*' but eventually went with a
  single function + keyword.  One reason for that is that the
  simplified interface has in several cases the behavior of operating
  over the whole string, so it seems like a better fit for a default,
  so I delegated the decision to a keyword.

-- 
  ((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 Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] [plt-scheme] Bug or misuse? match-expander ids not properly working (patch)

[J. Ian Johnson]

That behavior would be really spooky to me. I would expect binding positions to 
not depend on any environmental information. Perhaps have an (id _) form that 
would allow putting your special identifiers there.

-Ian

- Original Message -
From: "Eli Barzilay" 
To: "Sam Tobin-Hochstadt" , "Madoka Machitani" 

Cc: dev@racket-lang.org
Sent: Friday, May 4, 2012 2:16:07 PM GMT -05:00 US/Canada Eastern
Subject: Re: [racket-dev] [plt-scheme] Bug or misuse? match-expander ids not 
properly working   (patch)

This is an *ancient* patch suggestion that I dug up in my quest for
smaller inbox...  (It's really old, so won't work as is.)

It makes it possible to define identifier syntaxes as match expanders,
and that would probably make it possible to also address the
relatively common complaint about not having a `null' match pattern
that does the obvious thing.  Last time we talked about this (= me &
Sam) I think that there was some point about identifiers being
unambiguously used as patterns -- but I don't see a problem with the
following approach of specifying specific names as patterns.  If the
builtin identifier patterns are kept to a minimum (for example, only
`null', `true' and `false'), then I don't think that this will be
confusing in any way.


On November 24th 2009, Madoka Machitani wrote:
> Hi!
> 
> I've encountered a problem while implementing red-black trees:
> 
> (define-struct tree
>   (color key value left right))
> 
> (define empty (make-tree 'black #f #f #f #f))
> (define (empty? t) (eq? t empty))
> 
> 
> To ease access with the pattern match syntax, I wrote match expanders
> for trees as follows:
> 
> (define-match-expander T
>   (lambda (stx)
> (syntax-case stx ()
>   ((T c l (k v) r)
>(syntax/loc stx
>  (struct tree (c k v l r))
>   (lambda (stx)
> (syntax-case stx ()
>   ((T c l (k v) r)
>(syntax/loc stx
>  (make-tree c k v l r))
> 
> (define-match-expander R
>   (lambda (stx)
> (syntax-case stx ()
>   (R (syntax 'red
>   (lambda (stx)
> (syntax-case stx ()
>   (R (syntax 'red)
> 
> (define-match-expander B
>   (lambda (stx)
> (syntax-case stx ()
>   (B (syntax 'black
>   (lambda (stx)
> (syntax-case stx ()
>   (B (syntax 'black)
> 
> (define-match-expander E
>   (lambda (stx)
> (syntax-case stx ()
>   (E (syntax/loc stx (? empty?)
>   (lambda (stx)
> (syntax-case stx ()
>   (E (syntax/loc stx empty)
> 
> 
> which should enable one to construct and match trees a la Haskell:
> 
> (match (T B E ('a 1) E)
>   ((T B E (k v) E)
>"This is a black tree with both subtrees empty."))
> 
> 
> However, this doesn't work as I expected.  I.e., "B" and "E" in the
> pattern clause above are treated as plain variables, thus matching
> anything.  Seemingly match expander ids in pattern match clauses take
> effect only when used in "application" form.
> 
> So I wrote a patch.
> 
> The first portion is irrelevant to this particular issue, but fixes
> a bug which inecessarily converts unnamed let syntax to a named one.
> 
> The second part is required for the third one to work when only
> expander ids are used in match-let etc bindings.
> 
> I hope it's accepted.
> 
> regards,
> 
> diff -ur orig/define-forms.ss ./define-forms.ss
> --- orig/define-forms.ss  2009-09-17 12:09:40.0 +0900
> +++ ./define-forms.ss 2009-11-25 13:23:40.0 +0900
> @@ -72,7 +72,7 @@
>   ;; optimize the all-variable case
>   [(_ ([pat exp]...) body ...)
>(andmap pattern-var? (syntax->list #'(pat ...)))
> -  (syntax/loc stx (let name ([pat exp] ...) body ...))]
> +  (syntax/loc stx (let ([pat exp] ...) body ...))]
>   [(_ name ([pat exp]...) body ...)
>(and (identifier? (syntax name))
> (andmap pattern-var? (syntax->list #'(pat ...
> diff -ur orig/parse-helper.ss ./parse-helper.ss
> --- orig/parse-helper.ss  2009-09-17 12:09:40.0 +0900
> +++ ./parse-helper.ss 2009-11-25 13:44:34.0 +0900
> @@ -141,10 +141,17 @@
>  (define (match:syntax-err stx msg)
>(raise-syntax-error #f msg stx))
> 
> +;; match-var? : syntax -> bool
> +;; is p an identifier representing a pattern transformer?
> +(define (match-var? p)
> +  (match-expander?
> +   (syntax-local-value ((syntax-local-certifier) p)
> +(lambda () #f
> +
>  ;; pattern-var? : syntax -> bool
>  ;; is p an identifier representing a pattern variable?
>  (define (pattern-var? p)
> -  (and (identifier? p) (not (ddk? p
> +  (and (identifier? p) (not (ddk? p)) (not (match-var? p
> 
>  ;; ddk? : syntax -> number or boolean
>  ;; if #f is returned, was not a ddk identifier
> diff -ur orig/parse.ss ./parse.ss
> --- orig/parse.ss 2009-09-17 12:09:40.0 +0900
> +++ ./parse.ss2009-11-25 01:44:44.0 +0900
> @@ -32,6 +32,13 @@
>   (match-expander-transform
>parse/cert cert #'expander st

Re: [racket-dev] implicit begin for define-syntax-rule

[J. Ian Johnson]

I would say no, since a "syntax rule" is a single rewrite rule. Perhaps you 
want a simple shim around syntax-rules?

Like:
(define-syntax-rules [(id . pat) rhs] ...+)

where id must be the same in all templates?

Simple implementation:

(define-syntax (define-syntax-rules stx)
  (syntax-case stx ()
[(_ [(id0 pat0 ...) rhs0] [(ids pats ...) rhss] ...)
 (and (identifier? #'id0)
  (andmap (λ (i) (and (identifier? i) 
  (free-identifier=? i #'id0)))
  (syntax->list #'(ids ...
 (syntax/loc stx 
   (define-syntax (id0 stx)
 (syntax-rules stx () 
   [(_ pat0 ...) rhs0]
   [(_ pats ...) rhss] ...)))]))

-Ian

- Original Message -
From: "Marijn" 
To: dev@racket-lang.org
Sent: Thursday, May 3, 2012 5:39:10 AM GMT -05:00 US/Canada Eastern
Subject: [racket-dev] implicit begin for define-syntax-rule

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

would it make sense for define-syntax-rule to have an implicit begin
such that it could accept multiple forms for the template?

Marijn
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+iUj4ACgkQp/VmCx0OL2zrmACfQ18nV7BoxV2wm4SrPyCSD0rY
z54An3Kd24mFWFVuCxQ95J1Z6I5EuEJy
=fmgP
-END PGP SIGNATURE-
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Scribble documentation bug

[J. Ian Johnson]

I suppose I am. It's confusing that the identifier itself is not documented.
-Ian
- Original Message -
From: "Matthew Flatt" 
To: "J. Ian Johnson" 
Cc: dev@racket-lang.org
Sent: Friday, February 24, 2012 12:12:31 PM GMT -05:00 US/Canada Eastern
Subject: Re: [racket-dev] Scribble documentation bug

At Wed, 22 Feb 2012 13:38:37 -0500 (EST), "J. Ian Johnson" wrote:
> In scribblings/scribble/manual.scrbl:
> cite does not take only strings. I've been using bib-entries with it 
> exclusively, actually. What all can it take? I see it makes a link element 
> with 
> a tag like `(cite ,@all-things-that-might-be-strings). I'd rather not go 
> mucking about with what tags are and such to know what's really going on.

I'm pretty sure that `cite' from `scribble/manual' takes only strings,
and its implementation has a contract.

Are you maybe using a `cite' bound by `define-cite' from
`scriblib/autobib', along with `make-bib' from `scriblib/autobib'
(which is the right way to use that kind of `cite')?


_
  Racket Developers list:
  http://lists.racket-lang.org/dev

[racket-dev] Scribble documentation bug

[J. Ian Johnson]

In scribblings/scribble/manual.scrbl:
cite does not take only strings. I've been using bib-entries with it 
exclusively, actually. What all can it take? I see it makes a link element with 
a tag like `(cite ,@all-things-that-might-be-strings). I'd rather not go 
mucking about with what tags are and such to know what's really going on.

Thanks,
-Ian
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] An Improvement to for/set

[J. Ian Johnson]

I would prefer a simpler for/union:

(define-syntax (for/union stx)
  (syntax-case stx ()
[(_ clauses . body)
 #'(for/fold/derived stx ((accum-set (set))) clauses
 (set-union accum-set (let () . body))]))

-Ian

- Original Message -
From: "Daniel King" 
To: "Racket Dev List" 
Sent: Friday, February 17, 2012 1:07:25 PM GMT -05:00 US/Canada Eastern
Subject: [racket-dev] An Improvement to for/set

I've noticed myself desiring a for/set that would allow me to
optionally add zero, one, or more elements to the accumulated set
during each iteration. Is this something that other people would be
interested in having in the set library? If so, I can send a pull
request to the github repo.

My implementation should be backwards compatible with the old one. I
also created set-add* because I found myself wanting to add arbitrary
numbers of elements to sets as well.

;; set-add* : [Set X] X ... -> [Set X]
(define (set-add* s . vs)
  (for/fold ((s s)) ((v vs))
(set-add s v)))

(define-syntax (for/set stx)
  (syntax-case stx ()
[(_ clauses . body)
 #'(for/fold/derived stx ((accum-set (set))) clauses
 (call-with-values (lambda () . body)
   (curry set-add* accum-set)))]))

Examples:

> (for/set ((x '(1 2 3 4 5)))
  (sqr x))
(set 1 4 9 16 25)

> (for/set ((x '(1 2 3 4 5)))
(if (odd? x) x (values)))
(set 1 3 5)


-- 
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

[racket-dev] [scribble] Unicode in exact-chars elements

[J. Ian Johnson]

I've been writing a paper in scribble, dropping to LaTeX every so often to 
write in native math mode. I notice that unicode characters don't show up. I've 
ripped off display-protected from latex-render.rkt, removed the latex command 
syntax escaping (so I can have backslashes, underscores and carets) and every 
time I have a new unicode character I want to use, I have to add to the big 
case expression. I then translate all elements before putting them in the 
exact-chars element. I don't know how to wrap delayed and part-relative 
elements, but I haven't needed to yet.

What's worse is that I have to do a 1 character look-ahead for composing 
characters such as \hat{#1} and \tilde{#1} (\u0302 \u0303).
This is getting tiring, and from a short Googling I found that we could be 
using XeTeX as the backend instead to get direct unicode support. Are there 
plans for a XeTeX backend? I'm not sure how much work that would be as I don't 
know the subtle differences between it and LaTeX.

I'll keep doing my dispatching for now, I'm just curious.
Thanks,
-Ian
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

[racket-dev] Small typo in scribble/core docs

[J. Ian Johnson]

I'm not set up to make a pull request on this computer, but core.scrbl needs to 
add an "s" to make "contents" the field name for multiarg-element, not 
"content".
-Ian
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] feature request: gcd, lcm for rationals

[J. Ian Johnson]

What? The greatest common divisor would definitely not divide 1, unless it 
truly were 1.
-Ian
- Original Message -
From: "Jens Axel Søgaard" 
To: "David Van Horn" 
Cc: "Racket Dev List" 
Sent: Friday, December 9, 2011 2:04:46 PM GMT -05:00 US/Canada Eastern
Subject: Re: [racket-dev] feature request: gcd, lcm for rationals




One definition of greatest common divisor in a ring R is: 
d is a greatest common divisor of x and y when: 
i) d divides both x and y 
ii) If e is a divisor of both x and y, then d divides e 


Now let's consider the ring Q. Since Q is a field, 1 divides all elements. 


This implies that 1 is a greatest common divisor of any non-zero x and y. 
( ad i) 1 is a divisor of both x and y 
ad ii) 1 is a divisor of e ) 


It is therefore not obvious that gcd should be extendend as you suggest. 
But maybe we can finde another name for the operation? 


/Jens Axel 



2011/12/7 David Van Horn < dvanh...@ccs.neu.edu > 


It would be nice if gcd and lcm were extended to rational numbers, which seems 
in-line with Scheme's philosophy (but not standards) on numbers. 

(define (gcd-rational . rs) 
(/ (apply gcd (map numerator rs)) 
(apply lcm (map denominator rs 

(define (lcm-rational . rs) 
(/ (abs (apply * rs)) 
(apply gcd-rational rs))) 

David 
__ ___ 
For list-related administrative tasks: 
http://lists.racket-lang.org/ listinfo/dev 




-- 
-- 
Jens Axel Søgaard 



_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

[racket-dev] Subnormal numbers?

[J. Ian Johnson]

I'm currently proctoring the freshmen's lab on inexact numbers and was curious 
how to denote subnormal numbers in Racket.
Turns out that's not possible, since there is no underflow. Why does Racket 
follow the old standard of representing underflow with inexact zero?
I imagine changing it now would break a lot of code, but I'm just curious.
-Ian
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] for/match construct?

[J. Ian Johnson]

I don't like either. I'd rather shadowing, as it is more consistent with how I 
would conceive of a * binding pattern.
-Ian
- Original Message -
From: Sam Tobin-Hochstadt 
To: J. Ian Johnson 
Cc: dev 
Sent: Tue, 25 Oct 2011 20:23:28 -0400 (EDT)
Subject: Re: [racket-dev] for/match construct?

Matthew and I talked about this today, and we decided that we should
create a parallel set of matchized versions of the `for' macros,
rather than my previous experiment which added an `in-match' form that
changed the semantics of `for' clause bindings.  I've started
implementing this; fortunately it doesn't require exposing
`define-for-variants'.

The one semantic question is about match failure, should that be
treated as dropping the element from the sequence, or as a dynamic
error.  For the parallel, ie non-* variants, I don't think it makes
sense.  For the nested versions, it would make sense, but I'm unsure
about whether it's a good idea.

Any thoughts, particularly in the form of use cases, are welcome.

On Tue, Oct 25, 2011 at 6:42 AM, J. Ian Johnson  wrote:
> I'm considering putting in some effort to generalize the binding construct in 
> for-clauses so that we can have for[*]/match/X macros. This will require 
> modifying and exposing define-for-variants (due to circularity in requiring 
> match in for). Does anyone object? I'll of course need the code reviewed by 
> those more familiar with for, but I'm hoping I don't need to mess with 
> complicated implementation details such as taints.

-- 
sam th
sa...@ccs.neu.edu

_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

[racket-dev] for/match construct?

[J. Ian Johnson]

I'm considering putting in some effort to generalize the binding construct in 
for-clauses so that we can have for[*]/match/X macros. This will require 
modifying and exposing define-for-variants (due to circularity in requiring 
match in for). Does anyone object? I'll of course need the code reviewed by 
those more familiar with for, but I'm hoping I don't need to mess with 
complicated implementation details such as taints.

Example:
Here the significantly new behavior is that name should match in the for/match 
clauses in order to run the body.

(for* ([mch (redex-match L some-pat some-term)]
   [bnds (match-bindings mch)]
   [use-names (in-value use-names)])
  (for/match ([(bind name exp) bnds]
  [name use-names])
...code...))

What this looks like without for/match is

(for* ([mch (redex-match L some-pat some-term)]
   [bnds (match-bindings mch)]
   [use-names (in-value use-names)])
  (for ([bnd bnds]
[name use-names]
#:when (match* (bnd name) [((bind nm _) nm) #t] [(_ _) #f]))
(match-define-values ((name exp) name) (values bnd name))
...code...))

Notice the unnecessary second match.

-Ian
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev