[racket-dev] behavior of 'local-transformer-expand' changed
Hi, Commit e51ac9cc [1] from about a month ago changed the allowed values for local-transformer-expands context-v argument. It now refuses 'module and 'module-begin. Previously i could simply pass the result from syntax-local-context. I am not sure what i should pass now and what implications the change has. Any hints appreciated. Tobias [1] http://git.racket-lang.org/plt/commitdiff/e51ac9cc _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] raco pkg install should default to linking for filesystem packages
> So `--link' could be the default, while `--copy' (?) could disable >> special handling of directory sources? >> > > That sounds fine. I mean, I am unlikely to ever use --copy, but whatever > makes sense to expose in terms of the underlying model. > It could be useful if the directory is on a remote computer, but this will probably be a less frequent case. Laurent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] behavior of 'local-transformer-expand' changed
I removed those options because the implementation did not look sensible for those cases. Implementation aside, using 'module-begin doesn't make sense to me. A form in the place of `#%module-begin' is always expanded at phase-level 0, so there isn't really. I'm less certain about 'module. It may make sense to use 'module and get the same effect as wrapping the form with `begin-for-syntax', expanding with `local-expand', and removing the expansion again. Do you have an example where you use 'module? At Thu, 1 Aug 2013 10:12:16 +0200, Tobias Hammer wrote: > Hi, > > Commit e51ac9cc [1] from about a month ago changed the allowed values for > local-transformer-expands context-v argument. It now refuses 'module and > 'module-begin. Previously i could simply pass the result from > syntax-local-context. > I am not sure what i should pass now and what implications the change has. > Any hints appreciated. > > Tobias > > > [1] http://git.racket-lang.org/plt/commitdiff/e51ac9cc > _ > Racket Developers list: > http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] behavior of 'local-transformer-expand' changed
Here is a strip down example of a case that worked before and gave an error with the new version. I was only interested in the information if the argument to mac could be expanded to something bound or not. So the quick solution here was to wrap the provide in begin and expand it in 'top-level. Tobias PS: The whole local-expand construct is only needed in my case to work around the unfortunate behavior that racket lacks source locations in error message for transformer phase. It would really, really simplify debugging if that could be changed. ;; --- example #lang racket (require (for-syntax racket)) (define-syntax (mac stx) (syntax-case stx () [(_ id val) (begin (define e (local-transformer-expand #'val ;; 'module worked before (syntax-local-context) #f)) #`(begin-for-syntax #,e))])) (begin-for-syntax (define C 'C) (define-syntax (B stx) (syntax-case stx () [(_) #'(provide C)]))) (mac id (B)) On Thu, 01 Aug 2013 14:16:14 +0200, Matthew Flatt wrote: I removed those options because the implementation did not look sensible for those cases. Implementation aside, using 'module-begin doesn't make sense to me. A form in the place of `#%module-begin' is always expanded at phase-level 0, so there isn't really. I'm less certain about 'module. It may make sense to use 'module and get the same effect as wrapping the form with `begin-for-syntax', expanding with `local-expand', and removing the expansion again. Do you have an example where you use 'module? At Thu, 1 Aug 2013 10:12:16 +0200, Tobias Hammer wrote: Hi, Commit e51ac9cc [1] from about a month ago changed the allowed values for local-transformer-expands context-v argument. It now refuses 'module and 'module-begin. Previously i could simply pass the result from syntax-local-context. I am not sure what i should pass now and what implications the change has. Any hints appreciated. Tobias [1] http://git.racket-lang.org/plt/commitdiff/e51ac9cc _ Racket Developers list: http://lists.racket-lang.org/dev -- - Tobias Hammer DLR / Robotics and Mechatronics Center (RMC) 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] Generics updates
Just played a bit with gen:set. It looks great and in particular the fallback implementations are very convenient. One comment: the distinction between "primitive" methods and "derived" methods confused me somewhat. Can you explain the reasoning for determining which is which? For example, when I first read the docs, I thought that if I implemented the primitives, I would get the derived, but that's not the case since some of the derived methods depend on each other. Reading the docs more thoroughly, it sort of seems like there's an implicit separation along the lines of iterability, ie, derived sets are "iterable" since many of the derived methods require set->stream, but that's not exactly right either. On Thu, Jul 25, 2013 at 1:58 PM, Carl Eastlund wrote: > After some fixes, mostly to contracts and documentation, I've pushed the new > generics and set features to the master branch. > > Carl Eastlund > > > On Tue, Jul 23, 2013 at 11: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 > _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Generics updates
Hmm. Well, partially, I wasn't sure how to document the methods, because the relationships are complex, and because we don't have existing terminology or documentation patterns for this. I'm open to other suggestions, and especially (though not exclusively) to patches. For the other part, I either should have made it as you say -- implement the "primitive" ones and you get the others -- or else I should have clearly documented the relationship somewhere. I can't remember, now, if I thought I had made the primitive ones sufficient, or if I knew there were others you needed to implement, or if I just forgot to think that whole thing through. Do you have examples of which ones don't come "for free" with the primitive methods? Carl Eastlund On Thu, Aug 1, 2013 at 6:27 PM, Stephen Chang wrote: > Just played a bit with gen:set. It looks great and in particular the > fallback implementations are very convenient. > > One comment: the distinction between "primitive" methods and "derived" > methods confused me somewhat. Can you explain the reasoning for > determining which is which? > > For example, when I first read the docs, I thought that if I > implemented the primitives, I would get the derived, but that's not > the case since some of the derived methods depend on each other. > Reading the docs more thoroughly, it sort of seems like there's an > implicit separation along the lines of iterability, ie, derived sets > are "iterable" since many of the derived methods require set->stream, > but that's not exactly right either. > > > On Thu, Jul 25, 2013 at 1:58 PM, Carl Eastlund wrote: > > After some fixes, mostly to contracts and documentation, I've pushed the > new > > generics and set features to the master branch. > > > > Carl Eastlund > > > > > > On Tue, Jul 23, 2013 at 11: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 > > > > _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Generics updates
> For the other part, I either should have made it as you say -- implement the > > "primitive" ones and you get the others -- or else I should have clearly > documented the relationship somewhere. You did document the dependencies, but some of them are circular, ie some derived rely on other derived. I'd definitely be happy to patch things myself, but I guess I dont have a concrete complaint yet :), only that the distinctions feel somewhat arbitrary and did not match my initial intuition, which is why I'm looking for additional insight. > Do you have examples of which ones don't come "for free" with the primitive > methods? Very few of the derived come free because most rely on set->stream, but set->stream is not "primitive" which is why I thought there might be a distinction between iterable sets and non-iterable. > > Carl Eastlund > > > On Thu, Aug 1, 2013 at 6:27 PM, Stephen Chang wrote: >> >> Just played a bit with gen:set. It looks great and in particular the >> fallback implementations are very convenient. >> >> One comment: the distinction between "primitive" methods and "derived" >> methods confused me somewhat. Can you explain the reasoning for >> determining which is which? >> >> For example, when I first read the docs, I thought that if I >> implemented the primitives, I would get the derived, but that's not >> the case since some of the derived methods depend on each other. >> Reading the docs more thoroughly, it sort of seems like there's an >> implicit separation along the lines of iterability, ie, derived sets >> are "iterable" since many of the derived methods require set->stream, >> but that's not exactly right either. >> >> >> On Thu, Jul 25, 2013 at 1:58 PM, Carl Eastlund wrote: >> > After some fixes, mostly to contracts and documentation, I've pushed the >> > new >> > generics and set features to the master branch. >> > >> > Carl Eastlund >> > >> > >> > On Tue, Jul 23, 2013 at 11: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 >> > >> > >> > >> > _ >
Re: [racket-dev] Generics updates
Ah, yes, set->stream isn't primitive because it can be derived if you have set-first and either set-rest or set-remove. And I know there are dependency cycles, this is intentional so that you can implement any one of several related things, but most of them were supposed to go all the way down to primitive methods (in some sense) if all else failed. Would it be better to just remove the "primitve" / "derived" distinction, since it's somewhat artificial, and leave it up to the individual method descriptions? Is there some better way I should be describing things? Carl Eastlund On Thu, Aug 1, 2013 at 6:51 PM, Stephen Chang wrote: > > For the other part, I either should have made it as you say -- implement > the > "primitive" ones and you get the others -- or else I should have > clearly > > documented the relationship somewhere. > > You did document the dependencies, but some of them are circular, ie > some derived rely on other derived. I'd definitely be happy to patch > things myself, but I guess I dont have a concrete complaint yet :), > only that the distinctions feel somewhat arbitrary and did not match > my initial intuition, which is why I'm looking for additional insight. > > > > Do you have examples of which ones don't come "for free" with the > primitive > > methods? > > Very few of the derived come free because most rely on set->stream, > but set->stream is not "primitive" which is why I thought there might > be a distinction between iterable sets and non-iterable. > > > > > > > > Carl Eastlund > > > > > > On Thu, Aug 1, 2013 at 6:27 PM, Stephen Chang > wrote: > >> > >> Just played a bit with gen:set. It looks great and in particular the > >> fallback implementations are very convenient. > >> > >> One comment: the distinction between "primitive" methods and "derived" > >> methods confused me somewhat. Can you explain the reasoning for > >> determining which is which? > >> > >> For example, when I first read the docs, I thought that if I > >> implemented the primitives, I would get the derived, but that's not > >> the case since some of the derived methods depend on each other. > >> Reading the docs more thoroughly, it sort of seems like there's an > >> implicit separation along the lines of iterability, ie, derived sets > >> are "iterable" since many of the derived methods require set->stream, > >> but that's not exactly right either. > >> > >> > >> On Thu, Jul 25, 2013 at 1:58 PM, Carl Eastlund wrote: > >> > After some fixes, mostly to contracts and documentation, I've pushed > the > >> > new > >> > generics and set features to the master branch. > >> > > >> > Carl Eastlund > >> > > >> > > >> > On Tue, Jul 23, 2013 at 11: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 behavi
Re: [racket-dev] Generics updates
> Would it be better to just remove the "primitve" / "derived" distinction, > since it's somewhat artificial, and leave it up to the individual method > descriptions? Is there some better way I should be describing things? Ok I can see now that there's no easy way to organize the methods. I think we should keep some distinction, since as a programmer it's good to know exactly what methods I have to implement. However, to me "fallback" implies that I should get it for free, so it seems most intuitive if derived methods only depend on primitive methods. Then for some subset of primitive methods that I implement, I should get the derived methods that depend on those primitives. I'll have to think more about what should be derived and primitive, but for now I think the easiest thing is to edit the docs to move set->stream (or some equivalent) into the primitive list? > > Carl Eastlund > > > On Thu, Aug 1, 2013 at 6:51 PM, Stephen Chang wrote: >> >> > For the other part, I either should have made it as you say -- implement >> > the > "primitive" ones and you get the others -- or else I should have >> > clearly >> > documented the relationship somewhere. >> >> You did document the dependencies, but some of them are circular, ie >> some derived rely on other derived. I'd definitely be happy to patch >> things myself, but I guess I dont have a concrete complaint yet :), >> only that the distinctions feel somewhat arbitrary and did not match >> my initial intuition, which is why I'm looking for additional insight. >> >> >> > Do you have examples of which ones don't come "for free" with the >> > primitive >> > methods? >> >> Very few of the derived come free because most rely on set->stream, >> but set->stream is not "primitive" which is why I thought there might >> be a distinction between iterable sets and non-iterable. >> >> >> >> >> > >> > Carl Eastlund >> > >> > >> > On Thu, Aug 1, 2013 at 6:27 PM, Stephen Chang >> > wrote: >> >> >> >> Just played a bit with gen:set. It looks great and in particular the >> >> fallback implementations are very convenient. >> >> >> >> One comment: the distinction between "primitive" methods and "derived" >> >> methods confused me somewhat. Can you explain the reasoning for >> >> determining which is which? >> >> >> >> For example, when I first read the docs, I thought that if I >> >> implemented the primitives, I would get the derived, but that's not >> >> the case since some of the derived methods depend on each other. >> >> Reading the docs more thoroughly, it sort of seems like there's an >> >> implicit separation along the lines of iterability, ie, derived sets >> >> are "iterable" since many of the derived methods require set->stream, >> >> but that's not exactly right either. >> >> >> >> >> >> On Thu, Jul 25, 2013 at 1:58 PM, Carl Eastlund wrote: >> >> > After some fixes, mostly to contracts and documentation, I've pushed >> >> > the >> >> > new >> >> > generics and set features to the master branch. >> >> > >> >> > Carl Eastlund >> >> > >> >> > >> >> > On Tue, Jul 23, 2013 at 11: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 -
Re: [racket-dev] Generics updates
No, that doesn't work. If someone implements, say, an efficient subset? test, then set=? should use that rather than iterating using set->stream and set-member?. You should use the highest-level methods you can, in order to get the most out of an implementation. Which is why I made all the fallback implementations I did, to give implementers the best flexibility possible for getting a good implementation of all methods for the minimum possible effort on their part. Similarly, I don't want to make set->stream primitive, because if someone does implement set-first and set-rest, it should be derivable. Carl Eastlund On Thu, Aug 1, 2013 at 7:26 PM, Stephen Chang wrote: > > Would it be better to just remove the "primitve" / "derived" distinction, > > since it's somewhat artificial, and leave it up to the individual method > > descriptions? Is there some better way I should be describing things? > > Ok I can see now that there's no easy way to organize the methods. > > I think we should keep some distinction, since as a programmer it's > good to know exactly what methods I have to implement. However, to me > "fallback" implies that I should get it for free, so it seems most > intuitive if derived methods only depend on primitive methods. Then > for some subset of primitive methods that I implement, I should get > the derived methods that depend on those primitives. I'll have to > think more about what should be derived and primitive, but for now I > think the easiest thing is to edit the docs to move set->stream (or > some equivalent) into the primitive list? > > > > > > > Carl Eastlund > > > > > > On Thu, Aug 1, 2013 at 6:51 PM, Stephen Chang > wrote: > >> > >> > For the other part, I either should have made it as you say -- > implement > >> > the > "primitive" ones and you get the others -- or else I should have > >> > clearly > >> > documented the relationship somewhere. > >> > >> You did document the dependencies, but some of them are circular, ie > >> some derived rely on other derived. I'd definitely be happy to patch > >> things myself, but I guess I dont have a concrete complaint yet :), > >> only that the distinctions feel somewhat arbitrary and did not match > >> my initial intuition, which is why I'm looking for additional insight. > >> > >> > >> > Do you have examples of which ones don't come "for free" with the > >> > primitive > >> > methods? > >> > >> Very few of the derived come free because most rely on set->stream, > >> but set->stream is not "primitive" which is why I thought there might > >> be a distinction between iterable sets and non-iterable. > >> > >> > >> > >> > >> > > >> > Carl Eastlund > >> > > >> > > >> > On Thu, Aug 1, 2013 at 6:27 PM, Stephen Chang > >> > wrote: > >> >> > >> >> Just played a bit with gen:set. It looks great and in particular the > >> >> fallback implementations are very convenient. > >> >> > >> >> One comment: the distinction between "primitive" methods and > "derived" > >> >> methods confused me somewhat. Can you explain the reasoning for > >> >> determining which is which? > >> >> > >> >> For example, when I first read the docs, I thought that if I > >> >> implemented the primitives, I would get the derived, but that's not > >> >> the case since some of the derived methods depend on each other. > >> >> Reading the docs more thoroughly, it sort of seems like there's an > >> >> implicit separation along the lines of iterability, ie, derived sets > >> >> are "iterable" since many of the derived methods require set->stream, > >> >> but that's not exactly right either. > >> >> > >> >> > >> >> On Thu, Jul 25, 2013 at 1:58 PM, Carl Eastlund > wrote: > >> >> > After some fixes, mostly to contracts and documentation, I've > pushed > >> >> > the > >> >> > new > >> >> > generics and set features to the master branch. > >> >> > > >> >> > Carl Eastlund > >> >> > > >> >> > > >> >> > On Tue, Jul 23, 2013 at 11: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
[racket-dev] Planet require gone wild
I'm running HEAD = c126a8a from about 1 week ago. I wanted to try the PEG Planet 1 package. My source file was simply this: #lang racket (require (planet kazzmir/peg:2:0/peg)) 1. Using command-line Racket, I got: Welcome to Racket v5.90.0.3. ; uncaught exception: '#&"/Users/greg/src/scheme/collects/markdown/markdown/peg.rkt" Huh. I had the bright idea of trying this again, in DrRacket 5.90.0.3. 2. Right away, I got a red message: make-directory: forbidden (write) access to /Users/greg/Library/Racket/planet/300/5.90.0.3 Strange... 3. Perhaps dumbly, I decided to hit Run, anyway. What happened is that it installed a LOT of Planet packages. I let it run for awhile, thinking maybe there were more dependencies for `peg' than I realized. But the names flying by were making less and less sense. I got worried it was running wild and doing something like maybe trying to install ALL Planet packages. Plus then it started spitting out the following in the eval pane: Welcome to DrRacket, version 5.90.0.3--2013-07-30(c126a8aa/d) [3m]. Language: racket [custom]; memory limit: 2048 MB. Library/Racket/planet/300/5.90.0.3/cache/cce/scheme.plt/6/3/class.ss:36:16: module: identifier is already imported at: send+ in: (define-syntaxes (send+) (new-lambda (stx) (syntax-case stx () ((s+ expr clause ...) (syntax/loc stx (let* ((obj expr)) (send obj . clause) ... obj)) Library/Racket/planet/300/5.90.0.3/cache/cce/scheme.plt/6/3/contract.ss:319:30: proj-get: unbound identifier in module in: proj-get Library/Racket/planet/300/5.90.0.3/cache/cce/scheme.plt/6/3/contract.ss:319:30: proj-get: unbound identifier in module in: proj-get raco setup: error: during making for /cce/scheme.plt/6/3 (Scheme Utilities: (planet cce/scheme)) raco setup: Library/Racket/planet/300/5.90.0.3/cache/cce/scheme.plt/6/3/class.ss:36:16: module: identifier is already imported raco setup: at: send+ raco setup: in: (define-syntaxes (send+) (new-lambda (stx) (syntax-case stx () ((s+ expr clause ...) (syntax/loc stx (let* ((obj expr)) (send obj . clause) ... obj)) raco setup: error: during making for /cce/scheme.plt/6/3/reference raco setup: Library/Racket/planet/300/5.90.0.3/cache/cce/scheme.plt/6/3/contract.ss:319:30: proj-get: unbound identifier in module raco setup: in: proj-get raco setup: error: during Building docs for /Users/greg/Library/Racket/planet/300/5.90.0.3/cache/cce/scheme.plt/6/3/reference/manual.scrbl raco setup: Library/Racket/planet/300/5.90.0.3/cache/cce/scheme.plt/6/3/contract.ss:319:30: proj-get: unbound identifier in module raco setup: in: proj-get Library/Racket/planet/300/5.90.0.3/cache/cce/scheme.plt/6/3/contract.ss:319:30: proj-get: unbound identifier in module in: proj-get Library/Racket/planet/300/5.90.0.3/cache/cce/scheme.plt/6/3/contract.ss:319:30: proj-get: unbound identifier in module in: proj-get . . ../../../../../../../../../../../src/plt/racket/racket/collects/setup/private/omitted-paths.rkt:71:2: user break . . src/plt/racket/racket/collects/planet/private/resolver.rkt:606:8: user break > So I hit Stop in DrRacket (as you see from "user break"). Whew. 4. Here's everything it just installed. The only 2 I expected were `peg' and `memoize`: /Users/greg/Library/Racket/planet/300/5.90.0.3/cache: total used in directory 0 available 146890512 drwxr-xr-x 10 greg staff 340 Aug 1 21:34 . drwxr-xr-x 5 greg staff 170 Aug 1 21:32 .. drwxr-xr-x 9 greg staff 306 Aug 1 21:33 bzlib drwxr-xr-x 3 greg staff 102 Aug 1 21:34 cce drwxr-xr-x 3 greg staff 102 Aug 1 21:32 dherman drwxr-xr-x 3 greg staff 102 Aug 1 21:32 kazzmir drwxr-xr-x 3 greg staff 102 Aug 1 21:32 ryanc drwxr-xr-x 5 greg staff 170 Aug 1 21:35 schematics drwxr-xr-x 3 greg staff 102 Aug 1 21:33 untyped drwxr-xr-x 3 greg staff 102 Aug 1 21:33 zitterbewegung /Users/greg/Library/Racket/planet/300/5.90.0.3/cache/bzlib: total used in directory 0 available 146891616 drwxr-xr-x 9 greg staff 306 Aug 1 21:33 . drwxr-xr-x 10 greg staff 340 Aug 1 21:34 .. drwxr-xr-x 3 greg staff 102 Aug 1 21:33 base.plt drwxr-xr-x 3 greg staff 102 Aug 1 21:33 date-tz.plt drwxr-xr-x 3 greg staff 102 Aug 1 21:33 date.plt drwxr-xr-x 3 greg staff 102 Aug 1 21:33 file.plt drwxr-xr-x 3 greg staff 102 Aug 1 21:33 os.plt drwxr-xr-x 3 greg staff 102 Aug 1 21:33 parseq.plt drwxr-xr-x 3 greg staff 102 Aug 1 21:33 port.plt /Users/greg/Library/Racket/planet/300/5.90.0.3/cache/cce: total used in directory 0 available 146891608 drwxr-xr-x 3 greg staff 102 Aug 1 21:34 . drwxr-xr-x 10 greg staff 340 Aug 1 21:34 .. drwxr-xr-x 3 greg staff 102 Aug 1 21:34 scheme.plt /Users/greg/Library/Racket/planet/300/5.90.0.3/cache/dherman: total used in directory 0 available 146891608 drwxr-xr-x 3 greg staff 102 Aug 1 21:32 . drwxr-xr-x 10 greg staff 340 Aug 1 21:34 .. drwxr-xr-x 3 greg
Re: [racket-dev] Planet require gone wild
p.s. The About text from DrRacket is: Welcome to DrRacket, version 5.90.0.3--2013-07-30(c126a8aa/d), english by PLT. Just to confirm I ran the DrRacket built from HEAD = c126a8a, not an older version by accident. On Thu, Aug 1, 2013 at 9:55 PM, Greg Hendershott wrote: > I'm running HEAD = c126a8a from about 1 week ago. > > I wanted to try the PEG Planet 1 package. > > My source file was simply this: > > #lang racket > (require (planet kazzmir/peg:2:0/peg)) > > 1. Using command-line Racket, I got: > > Welcome to Racket v5.90.0.3. > ; uncaught exception: > '#&"/Users/greg/src/scheme/collects/markdown/markdown/peg.rkt" > > Huh. > > I had the bright idea of trying this again, in DrRacket 5.90.0.3. > > 2. Right away, I got a red message: > > make-directory: forbidden (write) access to > /Users/greg/Library/Racket/planet/300/5.90.0.3 > > Strange... > > 3. Perhaps dumbly, I decided to hit Run, anyway. > > What happened is that it installed a LOT of Planet packages. I let it > run for awhile, thinking maybe there were more dependencies for `peg' > than I realized. But the names flying by were making less and less > sense. I got worried it was running wild and doing something like > maybe trying to install ALL Planet packages. > > Plus then it started spitting out the following in the eval pane: > > Welcome to DrRacket, version 5.90.0.3--2013-07-30(c126a8aa/d) [3m]. > Language: racket [custom]; memory limit: 2048 MB. > Library/Racket/planet/300/5.90.0.3/cache/cce/scheme.plt/6/3/class.ss:36:16: > module: identifier is already imported > at: send+ > in: (define-syntaxes (send+) (new-lambda (stx) (syntax-case stx () > ((s+ expr clause ...) (syntax/loc stx (let* ((obj expr)) (send obj . > clause) ... obj)) > Library/Racket/planet/300/5.90.0.3/cache/cce/scheme.plt/6/3/contract.ss:319:30: > proj-get: unbound identifier in module > in: proj-get > Library/Racket/planet/300/5.90.0.3/cache/cce/scheme.plt/6/3/contract.ss:319:30: > proj-get: unbound identifier in module > in: proj-get > raco setup: error: during making for /cce/scheme.plt/6/3 > (Scheme Utilities: (planet cce/scheme)) > raco setup: > Library/Racket/planet/300/5.90.0.3/cache/cce/scheme.plt/6/3/class.ss:36:16: > module: identifier is already imported > raco setup: at: send+ > raco setup: in: (define-syntaxes (send+) (new-lambda (stx) > (syntax-case stx () ((s+ expr clause ...) (syntax/loc stx (let* ((obj > expr)) (send obj . clause) ... obj)) > raco setup: error: during making for /cce/scheme.plt/6/3/reference > raco setup: > Library/Racket/planet/300/5.90.0.3/cache/cce/scheme.plt/6/3/contract.ss:319:30: > proj-get: unbound identifier in module > raco setup: in: proj-get > raco setup: error: during Building docs for > /Users/greg/Library/Racket/planet/300/5.90.0.3/cache/cce/scheme.plt/6/3/reference/manual.scrbl > raco setup: > Library/Racket/planet/300/5.90.0.3/cache/cce/scheme.plt/6/3/contract.ss:319:30: > proj-get: unbound identifier in module > raco setup: in: proj-get > Library/Racket/planet/300/5.90.0.3/cache/cce/scheme.plt/6/3/contract.ss:319:30: > proj-get: unbound identifier in module > in: proj-get > Library/Racket/planet/300/5.90.0.3/cache/cce/scheme.plt/6/3/contract.ss:319:30: > proj-get: unbound identifier in module > in: proj-get > . . > ../../../../../../../../../../../src/plt/racket/racket/collects/setup/private/omitted-paths.rkt:71:2: > user break > . . src/plt/racket/racket/collects/planet/private/resolver.rkt:606:8: user > break >> > > So I hit Stop in DrRacket (as you see from "user break"). Whew. > > 4. Here's everything it just installed. The only 2 I expected were > `peg' and `memoize`: > > /Users/greg/Library/Racket/planet/300/5.90.0.3/cache: > total used in directory 0 available 146890512 > drwxr-xr-x 10 greg staff 340 Aug 1 21:34 . > drwxr-xr-x 5 greg staff 170 Aug 1 21:32 .. > drwxr-xr-x 9 greg staff 306 Aug 1 21:33 bzlib > drwxr-xr-x 3 greg staff 102 Aug 1 21:34 cce > drwxr-xr-x 3 greg staff 102 Aug 1 21:32 dherman > drwxr-xr-x 3 greg staff 102 Aug 1 21:32 kazzmir > drwxr-xr-x 3 greg staff 102 Aug 1 21:32 ryanc > drwxr-xr-x 5 greg staff 170 Aug 1 21:35 schematics > drwxr-xr-x 3 greg staff 102 Aug 1 21:33 untyped > drwxr-xr-x 3 greg staff 102 Aug 1 21:33 zitterbewegung > > /Users/greg/Library/Racket/planet/300/5.90.0.3/cache/bzlib: > total used in directory 0 available 146891616 > drwxr-xr-x 9 greg staff 306 Aug 1 21:33 . > drwxr-xr-x 10 greg staff 340 Aug 1 21:34 .. > drwxr-xr-x 3 greg staff 102 Aug 1 21:33 base.plt > drwxr-xr-x 3 greg staff 102 Aug 1 21:33 date-tz.plt > drwxr-xr-x 3 greg staff 102 Aug 1 21:33 date.plt > drwxr-xr-x 3 greg staff 102 Aug 1 21:33 file.plt > drwxr-xr-x 3 greg staff 102 Aug 1 21:33 os.plt > drwxr-xr-x 3 greg staff 102 Aug 1 21:33 parseq.plt > drwxr-xr-x 3 greg staff 102 Aug 1 21:33 port.plt > > /Users/greg/Lib
