Re: [racket-dev] Again. JPEG: unsupported library version: unknown
It's weird. I cloned and modified the racket/draw/unsafe/jpeg.rkt, even the basic form (ffi-lib libjpeg) gives me the unknown version, and the only version in my system is 62. Finally I solved it by configuring with --disable-libffi. More over, I don't know the difficulties to have retina display supported either. Maybe it's time to do some researching on the source code. On Thu, Aug 15, 2013 at 10:21 AM, Matthew Flatt mfl...@cs.utah.edu wrote: At Wed, 14 Aug 2013 17:55:41 +0800, WarGrey Gyoudmon Ju wrote: racket version: from 5.3.6. (5.3.4 is okay) os version: SunOS (OpenIndiana) DrRacket cannot open Generating documents failed if the page contains picture. A difference between v5.3.4 and v5.3.6 is that the latter tries to load libjpeg.so.9 if its available (after trying libjpeg.so.62 and libjpeg.so.8, before trying libjpeg.so). Do you have a libjpeg.so.9 installed? BTW, is there any plan to make racket GUI support retina display? I don't have the hardware to work on retina-display support, so far. Patches are welcome, of course, but I don't know how difficult the problem is. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Updating dependency packages from other sources
At Thu, 15 Aug 2013 11:07:07 -0400, Asumu Takikawa wrote: On 2013-08-15 08:19:06 -0600, Jay McCarthy wrote: As for what we could do going forward, I think either of these approaches could be 'automated'. Yes, that'd be great. For instance, we could add a command like $ raco pkg replace x11 new-x11-source This would behave like either of those (which would be invisible to the user). Do you have any opinions about how you'd want to do this replacement? Maybe `raco pkg install` can have an additional flag that lets you replace existing packages? Or maybe it should allow conflicts if the package has the same name as an already installed package (possibly prompting/warning the user)? How about allowing a package source as an argument to `raco pkg update`? After all, removing an old package implementation and installing a new one is already the job of `raco pkg update`, not `raco pkg install`. Then again, dealing with package sources and recording a new name-source mapping is already the job of `raco pkg install`, not `raco pkg update`. I lean toward changing `raco pkg update`, because I think it's reasonable to treat a package source other than a package name as a replace request by default. In contrast, I don't think `raco pkg install` should ever overwrite an existing package implementation by default. For example, I can imagine raco pkg install stuff.zip ... get a new stuff.zip ... raco pkg update stuff.zip and that seems better to me than raco pkg install stuff.zip ... get a new stuff.zip ... raco pkg install --replace stuff.zip I have in mind that `raco pkg update` would treat as package name as it does now, instead of like other package sources. That is, it would update based on how the package was previously installed. There's a difference only if the package was installed from a package source other than a package name, though. Naturally, the special treatment of package names would necessitate a new flag for consistent treatment of package sources. Specifically, if you wanted to replace an existing package installation with a catalog reference, then you'd have to use a flag to `raco pkg update'. _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Generics scoping issues
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] 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] Updating dependency packages from other sources
I think that's a better idea Matthew. On Fri, Aug 16, 2013 at 2:27 PM, Matthew Flatt mfl...@cs.utah.edu wrote: At Thu, 15 Aug 2013 11:07:07 -0400, Asumu Takikawa wrote: On 2013-08-15 08:19:06 -0600, Jay McCarthy wrote: As for what we could do going forward, I think either of these approaches could be 'automated'. Yes, that'd be great. For instance, we could add a command like $ raco pkg replace x11 new-x11-source This would behave like either of those (which would be invisible to the user). Do you have any opinions about how you'd want to do this replacement? Maybe `raco pkg install` can have an additional flag that lets you replace existing packages? Or maybe it should allow conflicts if the package has the same name as an already installed package (possibly prompting/warning the user)? How about allowing a package source as an argument to `raco pkg update`? After all, removing an old package implementation and installing a new one is already the job of `raco pkg update`, not `raco pkg install`. Then again, dealing with package sources and recording a new name-source mapping is already the job of `raco pkg install`, not `raco pkg update`. I lean toward changing `raco pkg update`, because I think it's reasonable to treat a package source other than a package name as a replace request by default. In contrast, I don't think `raco pkg install` should ever overwrite an existing package implementation by default. For example, I can imagine raco pkg install stuff.zip ... get a new stuff.zip ... raco pkg update stuff.zip and that seems better to me than raco pkg install stuff.zip ... get a new stuff.zip ... raco pkg install --replace stuff.zip I have in mind that `raco pkg update` would treat as package name as it does now, instead of like other package sources. That is, it would update based on how the package was previously installed. There's a difference only if the package was installed from a package source other than a package name, though. Naturally, the special treatment of package names would necessitate a new flag for consistent treatment of package sources. Specifically, if you wanted to replace an existing package installation with a catalog reference, then you'd have to use a flag to `raco pkg update'. -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Generics scoping issues
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] Updating dependency packages from other sources
On 2013-08-16 14:27:41 -0600, Matthew Flatt wrote: How about allowing a package source as an argument to `raco pkg update`? After all, removing an old package implementation and installing a new one is already the job of `raco pkg update`, not `raco pkg install`. I like this idea better than what I suggested earlier. I have in mind that `raco pkg update` would treat as package name as it does now, instead of like other package sources. That is, it would update based on how the package was previously installed. Right now updates from the local filesystem (say in --copy mode) aren't tracked. Is the idea to change that so that `raco pkg update foo` will copy a new version of the package from the filesystem? (assuming it was installed that way to begin with) Similarly with URL installs, etc. If so, that sounds great too. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Generics scoping issues
WRT the struct abstraction, using syntax-local-introduce on #'gen:binds-variables seemed to do the trick, oddly. -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: 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
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 i...@ccs.neu.edu 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 c...@ccs.neu.edu To: J. Ian Johnson i...@ccs.neu.edu Cc: dev dev@racket-lang.org 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
[racket-dev] main-repo packages on pkg.racket-lang.org
All of the packages in the main repository are now listed on pkg.racket-lang.org. They have tags like main-distribution (for packages that are in the main distribution) and main-tests (for tests that are not in the distribution, but are for main-distribution code). If you try to install any of the packages in v5.3.6 or earlier, you get an empty package. The intent is that other packages can now declare proper dependencies for v5.90.x, and the dependency declaration won't break the package for v5.3.6 users. Meanwhile, with v5.90.x, you could build with just `make base' and then install more with, say, raco pkg install -i main-distribution For now, there's no advantage to doing that compared to just using `make PKGS=...'; you get everything with a git checkout, anyway. In the future, that might be closer to the way things work, and now we can experiment with that mode. The source for each package is an S3-hosted .zip file. Those sources are put in place by a periodic task that pulls from github, creates individual zip files, uploads to S3, and updates pkg.racket-lang.org. Currently, the job runs on a machine every 15 minutes (on the hour, 15 minutes after, etc.). We'll see how that works out, and probably we'll make it more reliable by having multiple machines check for updates --- including one triggered by notifications from Github. In any case, copying from the git repo to .zip files is expected to be a stop-gap until we're ready to split the main repository (which is some time away, I think). _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Generics scoping issues
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 c...@ccs.neu.edu 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 i...@ccs.neu.edu 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 c...@ccs.neu.edu To: J. Ian Johnson i...@ccs.neu.edu Cc: dev dev@racket-lang.org 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
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 c...@ccs.neu.edu 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 c...@ccs.neu.edu 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 i...@ccs.neu.edu 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 c...@ccs.neu.edu To: J. Ian Johnson i...@ccs.neu.edu Cc: dev dev@racket-lang.org 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
