Re: [racket-dev] patch for make-base-eval

[Robby Findler]

namespace-attach-module sets up shared state between two modules so that,
in this case, the racket/pretty in one namespace is the same as the
racket/pretty in the other.

Try putting a printf in the top-level of racket/pretty (and in various
other places in that code as it does what it does) and then doing the
dynamic-require with and without the attach.

Robby


On Wed, Oct 2, 2013 at 4:58 PM, Stephen Chang  wrote:

> Ok here's another dumb question. Why is that namespace-attach-module
> even needed? It seems the dynamic require on the next line does the
> desired thing?
>
> On Wed, Oct 2, 2013 at 4:16 PM, Stephen Chang  wrote:
> > Ok thanks for the explanations. I'll try doing one of the last two
> suggestions.
> >
> > On Wed, Oct 2, 2013 at 4:09 PM, Ryan Culpepper 
> wrote:
> >> No, the 'racket/pretty' module might be declared even if the symbol
> isn't
> >> defined (or "mapped") in the namespace:
> >>
> >>   > (define ns (make-base-namespace))
> >>   > (define repl-ns (current-namespace))
> >>   > (parameterize ((current-namespace ns))
> >>   (eval '(require (only-in racket/pretty
> >>   > (parameterize ((current-namespace ns))
> >>   (namespace-attach-module repl-ns 'racket/pretty))
> >>   namespace-attach-module: a different module with the same name is
> >>   already in the destination namespace
> >> module name: "/opt/racket-5.3.6/collects/racket/pretty.rkt"
> >> context...:
> >>  /opt/racket-5.3.6/collects/racket/private/misc.rkt:87:7
> >>
> >> And the symbol can be defined in the namespace even if the module is not
> >> declared:
> >>
> >>   > (define ns (make-base-namespace))
> >>   > (define repl-ns (current-namespace))
> >>   > (parameterize ((current-namespace ns))
> >>   (eval '(define pretty-print-handler #t)))
> >>   > (parameterize ((current-namespace ns))
> >>   (namespace-variable-value 'pretty-print-handler))
> >>   #t
> >>   ;; but racket/pretty is not declared,
> >>   ;; and #t is not a good print handler
> >>
> >> Ryan
> >>
> >>
> >>
> >> On 10/02/2013 03:58 PM, Stephen Chang wrote:
> 
>  A namespace is a mapping from top-level identifiers to whatever they
> are,
>  as
>  well as a separate mapping from module names to modules (roughly).
> What
>  you
>  care about here is the second mapping, but you're checking the first
> with
>  the patch.
> >>>
> >>>
> >>> Thanks for the explanation. That helps a lot. So the danger with my
> >>> check is when someone has another definition of pretty-print handler
> >>> but racket/pretty has not been attached?
> >>>
> >>> But given the context, ie the dynamic require on the next line, it
> >>> seems like there's already an assumption about what the identifier I'm
> >>> checking is, so in this specific situation, isnt my check sufficient?
> >>>
> >>>
> >>>
> 
>  Robby
> 
> 
>  On Wed, Oct 2, 2013 at 2:45 PM, Stephen Chang 
>  wrote:
> >
> >
> >> Whether that identifier exists in the namespace has nothing to do
> with
> >> whether racket/pretty can be attached.
> >
> >
> > Can you explain this a little more because it's a little unintuitive
> to
> > me?
> >
> >
> >>
> >> One option would be for install-pretty-printer! to just catch and
> >> discard
> >> the error. Evaluators for some languages would mysteriously not have
> >> pretty-printing turned on by default.
> >>
> >> Another option would be to attach racket/pretty before requiring the
> >> initial
> >> language for the namespace.
> >>
> >> Another option is use #:pretty-print? #f when attaching
> racket/pretty
> >> would
> >> fail.
> >>
> >> Ryan
> >>
> > _
> >Racket Developers list:
> >http://lists.racket-lang.org/dev
> 
> 
> 
> >>
>
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] patch for make-base-eval

[Stephen Chang]

Ok here's another dumb question. Why is that namespace-attach-module
even needed? It seems the dynamic require on the next line does the
desired thing?

On Wed, Oct 2, 2013 at 4:16 PM, Stephen Chang  wrote:
> Ok thanks for the explanations. I'll try doing one of the last two 
> suggestions.
>
> On Wed, Oct 2, 2013 at 4:09 PM, Ryan Culpepper  wrote:
>> No, the 'racket/pretty' module might be declared even if the symbol isn't
>> defined (or "mapped") in the namespace:
>>
>>   > (define ns (make-base-namespace))
>>   > (define repl-ns (current-namespace))
>>   > (parameterize ((current-namespace ns))
>>   (eval '(require (only-in racket/pretty
>>   > (parameterize ((current-namespace ns))
>>   (namespace-attach-module repl-ns 'racket/pretty))
>>   namespace-attach-module: a different module with the same name is
>>   already in the destination namespace
>> module name: "/opt/racket-5.3.6/collects/racket/pretty.rkt"
>> context...:
>>  /opt/racket-5.3.6/collects/racket/private/misc.rkt:87:7
>>
>> And the symbol can be defined in the namespace even if the module is not
>> declared:
>>
>>   > (define ns (make-base-namespace))
>>   > (define repl-ns (current-namespace))
>>   > (parameterize ((current-namespace ns))
>>   (eval '(define pretty-print-handler #t)))
>>   > (parameterize ((current-namespace ns))
>>   (namespace-variable-value 'pretty-print-handler))
>>   #t
>>   ;; but racket/pretty is not declared,
>>   ;; and #t is not a good print handler
>>
>> Ryan
>>
>>
>>
>> On 10/02/2013 03:58 PM, Stephen Chang wrote:

 A namespace is a mapping from top-level identifiers to whatever they are,
 as
 well as a separate mapping from module names to modules (roughly). What
 you
 care about here is the second mapping, but you're checking the first with
 the patch.
>>>
>>>
>>> Thanks for the explanation. That helps a lot. So the danger with my
>>> check is when someone has another definition of pretty-print handler
>>> but racket/pretty has not been attached?
>>>
>>> But given the context, ie the dynamic require on the next line, it
>>> seems like there's already an assumption about what the identifier I'm
>>> checking is, so in this specific situation, isnt my check sufficient?
>>>
>>>
>>>

 Robby


 On Wed, Oct 2, 2013 at 2:45 PM, Stephen Chang 
 wrote:
>
>
>> Whether that identifier exists in the namespace has nothing to do with
>> whether racket/pretty can be attached.
>
>
> Can you explain this a little more because it's a little unintuitive to
> me?
>
>
>>
>> One option would be for install-pretty-printer! to just catch and
>> discard
>> the error. Evaluators for some languages would mysteriously not have
>> pretty-printing turned on by default.
>>
>> Another option would be to attach racket/pretty before requiring the
>> initial
>> language for the namespace.
>>
>> Another option is use #:pretty-print? #f when attaching racket/pretty
>> would
>> fail.
>>
>> Ryan
>>
> _
>Racket Developers list:
>http://lists.racket-lang.org/dev



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

[racket-dev] raco pkg dependency checks and exit code

[Asumu Takikawa]

Hi all,

I noticed that if you don't specify any dependencies for a package, then
`raco` will warn you about that.  However, the exit code is 0 and it's
not an "error".

Comparatively, if you supply a dependencies field of `empty`, then you
will get a bunch of errors about undeclared dependencies and the exit
code is 1.

Is there a reason why these two cases are treated differently?

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

Re: [racket-dev] Generics updates

[Jay McCarthy]

Totally agree.

On Wed, Oct 2, 2013 at 2:53 PM, Sam Tobin-Hochstadt
 wrote:
> On Wed, Oct 2, 2013 at 4:44 PM, Jay McCarthy  wrote:
>> This is a good message, but I have one quibble.
>>
>> I think it makes sense to separate data immutability and logical
>> immutability. For instance, I may have a library for querying REST
>> services where a "server" object is represented by an immutable
>> string. The string is immutable? but the service behind it is not. I
>> don't want the happenstance of which data was used to construct the
>> object to give the wrong idea of its mutability.
>
> I think what you're saying here is that part of what we want from
> immutability is knowing that doing the same thing again on the
> immutable data won't change the behavior.  But of course, this is a
> property of _both_ the data and the operation -- `file->bytes` takes
> immutable input, but running it multiple times doesn't guarantee
> anything. I'm not sure where this leaves us in terms of API design,
> though.  In a capability-based language, or in a language like Clean,
> `file->bytes` might take the filesystem as input, but that's not very
> Rackety. :)
>
> My inclination is that a dictionary implemented with immutable data
> structures but representing the results of `getenv` shouldn't be
> `immutable?`, whereas maybe one with mutable insides but a functional
> interface should be, but that really depends on what we're trying to
> say.
>
> Sam
>
>>
>> Jay
>>
>> On Wed, Oct 2, 2013 at 2:41 PM, Sam Tobin-Hochstadt
>>  wrote:
>>> On Wed, Oct 2, 2013 at 4:29 PM, Robby Findler
>>>  wrote:
 That sounds right.

 But just in case there is any confusion on the larger point: predicates as
 way we check properties to ensure good properties of our abstractions is 
 one
 of the important things that we have mostly gotten right in Racket.
 Chaperones, separate pair? and mpair? predicates, and presumably lots of
 other stuff are the way they are for this kind of reason.
>>>
>>> Unfortunately, this is only half-true, I think.  In particular, a very
>>> large number of our data structures violate this rule: vectors,
>>> strings, byte strings boxes, hash tables, dictionaries, sequences, and
>>> so on, all provide the same operations on both mutable and immutable
>>> variants.  This is also true in general of structs -- a substruct can
>>> be mutable when the superstruct is immutable.
>>>
>>> Ultimately, for the purpose of consistency, I think we should try to
>>> decide what the 'Rackety' style for this is.  Should we follow the
>>> lead of hash tables, where `immutable?` is needed to determine
>>> anything?  Or should we follow the lead of pairs, where there's a
>>> whole separate type?  And how should this interact with subtyping, as
>>> in this discussion?
>>>
>>> Personally, I think I prefer separate unrelated data structures, with
>>> a generic interface [1].  Maybe this means we should make `immutable?`
>>> into a generic.
>>>
>>> [1] I think that part of the reason some of these are conflated is
>>> lack of generic operations.
>>>
>>> Sam
>>>

 Robby


 On Wed, Oct 2, 2013 at 3:21 PM, Jay McCarthy  
 wrote:
>
> Even if we were to remove set-add! from gen:set and not great gen:mset
> then that would not be a vaild property. Generics are a lower bound on
> the interface, not an upper bound, so there could be other functions
> on the data structure that implement mutation. For instance, a gen:set
> could be made for an external resource that was set-like.
>
> I think what you want is something like gen:fset that has no methods,
> but is used for set authors to tag their set as having this property
> for the benefit of consumers (which cannot be enforced.) Your library
> would then consume fsets and not sets.
>
> Jay
>
>
> On Wed, Oct 2, 2013 at 2:09 PM, Robby Findler
>  wrote:
> > If we do go this way, we should be careful about the subtyping
> > relationship
> > since we want a predicate that means "will not be mutated and I can rely
> > on
> > that to reason about my library's behavior" and if mutable sets are a
> > sub-thing of immutable ones, we might lose that (depending on how things
> > are
> > set up).
> >
> > Robby
> >
> >
> > On Wed, Oct 2, 2013 at 2:57 PM, Jay McCarthy 
> > wrote:
> >>
> >> No. Mutable sets would implement gen:set and then just have a few more
> >> methods in the gen:mset interface. Structs can implement any number of
> >> generics.
> >>
> >> Jay
> >>
> >> On Wed, Oct 2, 2013 at 1:31 PM, J. Ian Johnson 
> >> wrote:
> >> > 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.
> >> >
> >>

Re: [racket-dev] Generics updates

[Sam Tobin-Hochstadt]

On Wed, Oct 2, 2013 at 4:44 PM, Jay McCarthy  wrote:
> This is a good message, but I have one quibble.
>
> I think it makes sense to separate data immutability and logical
> immutability. For instance, I may have a library for querying REST
> services where a "server" object is represented by an immutable
> string. The string is immutable? but the service behind it is not. I
> don't want the happenstance of which data was used to construct the
> object to give the wrong idea of its mutability.

I think what you're saying here is that part of what we want from
immutability is knowing that doing the same thing again on the
immutable data won't change the behavior.  But of course, this is a
property of _both_ the data and the operation -- `file->bytes` takes
immutable input, but running it multiple times doesn't guarantee
anything. I'm not sure where this leaves us in terms of API design,
though.  In a capability-based language, or in a language like Clean,
`file->bytes` might take the filesystem as input, but that's not very
Rackety. :)

My inclination is that a dictionary implemented with immutable data
structures but representing the results of `getenv` shouldn't be
`immutable?`, whereas maybe one with mutable insides but a functional
interface should be, but that really depends on what we're trying to
say.

Sam

>
> Jay
>
> On Wed, Oct 2, 2013 at 2:41 PM, Sam Tobin-Hochstadt
>  wrote:
>> On Wed, Oct 2, 2013 at 4:29 PM, Robby Findler
>>  wrote:
>>> That sounds right.
>>>
>>> But just in case there is any confusion on the larger point: predicates as
>>> way we check properties to ensure good properties of our abstractions is one
>>> of the important things that we have mostly gotten right in Racket.
>>> Chaperones, separate pair? and mpair? predicates, and presumably lots of
>>> other stuff are the way they are for this kind of reason.
>>
>> Unfortunately, this is only half-true, I think.  In particular, a very
>> large number of our data structures violate this rule: vectors,
>> strings, byte strings boxes, hash tables, dictionaries, sequences, and
>> so on, all provide the same operations on both mutable and immutable
>> variants.  This is also true in general of structs -- a substruct can
>> be mutable when the superstruct is immutable.
>>
>> Ultimately, for the purpose of consistency, I think we should try to
>> decide what the 'Rackety' style for this is.  Should we follow the
>> lead of hash tables, where `immutable?` is needed to determine
>> anything?  Or should we follow the lead of pairs, where there's a
>> whole separate type?  And how should this interact with subtyping, as
>> in this discussion?
>>
>> Personally, I think I prefer separate unrelated data structures, with
>> a generic interface [1].  Maybe this means we should make `immutable?`
>> into a generic.
>>
>> [1] I think that part of the reason some of these are conflated is
>> lack of generic operations.
>>
>> Sam
>>
>>>
>>> Robby
>>>
>>>
>>> On Wed, Oct 2, 2013 at 3:21 PM, Jay McCarthy  wrote:

 Even if we were to remove set-add! from gen:set and not great gen:mset
 then that would not be a vaild property. Generics are a lower bound on
 the interface, not an upper bound, so there could be other functions
 on the data structure that implement mutation. For instance, a gen:set
 could be made for an external resource that was set-like.

 I think what you want is something like gen:fset that has no methods,
 but is used for set authors to tag their set as having this property
 for the benefit of consumers (which cannot be enforced.) Your library
 would then consume fsets and not sets.

 Jay


 On Wed, Oct 2, 2013 at 2:09 PM, Robby Findler
  wrote:
 > If we do go this way, we should be careful about the subtyping
 > relationship
 > since we want a predicate that means "will not be mutated and I can rely
 > on
 > that to reason about my library's behavior" and if mutable sets are a
 > sub-thing of immutable ones, we might lose that (depending on how things
 > are
 > set up).
 >
 > Robby
 >
 >
 > On Wed, Oct 2, 2013 at 2:57 PM, Jay McCarthy 
 > wrote:
 >>
 >> No. Mutable sets would implement gen:set and then just have a few more
 >> methods in the gen:mset interface. Structs can implement any number of
 >> generics.
 >>
 >> Jay
 >>
 >> On Wed, Oct 2, 2013 at 1:31 PM, J. Ian Johnson 
 >> wrote:
 >> > 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
>>

Re: [racket-dev] Generics updates

[Carl Eastlund]

Short(ish) answer until I get reliable internet in my new apartment --
gen:set is modeled after gen:dict.  I don't want us to have a new design
for each interface.  Because methods are optional, we get by with one name
for one or more related subinterfaces.  That's the principle by which I
justified set-add and set-add! In one interface.

And if we separate them, we need one interface with just queries, then four
more for add, remove, add!, and remove!, at the very least.  It's a messy
direction to go in.

Carl Eastlund

--
WARNING!  Poorly-typed cell phone email precedes.
On Oct 2, 2013 4:35 PM, "Jay McCarthy"  wrote:

> I agree. I think the important thing with generics is unlike mpair?
> the set? predicate only necessarily implies that the methods are
> available (which is the source of my original complaint). We need to
> design the meaning of predicates just like we design the interface. I
> think that if we want mset to be a set then set? cannot imply
> immutable? but since that is a valuable property, it is worth
> designing a predicate that gives it, if only as a human thing.
>
> Jay
>
> On Wed, Oct 2, 2013 at 2:29 PM, Robby Findler
>  wrote:
> > That sounds right.
> >
> > But just in case there is any confusion on the larger point: predicates
> as
> > way we check properties to ensure good properties of our abstractions is
> one
> > of the important things that we have mostly gotten right in Racket.
> > Chaperones, separate pair? and mpair? predicates, and presumably lots of
> > other stuff are the way they are for this kind of reason.
> >
> > Robby
> >
> >
> > On Wed, Oct 2, 2013 at 3:21 PM, Jay McCarthy 
> wrote:
> >>
> >> Even if we were to remove set-add! from gen:set and not great gen:mset
> >> then that would not be a vaild property. Generics are a lower bound on
> >> the interface, not an upper bound, so there could be other functions
> >> on the data structure that implement mutation. For instance, a gen:set
> >> could be made for an external resource that was set-like.
> >>
> >> I think what you want is something like gen:fset that has no methods,
> >> but is used for set authors to tag their set as having this property
> >> for the benefit of consumers (which cannot be enforced.) Your library
> >> would then consume fsets and not sets.
> >>
> >> Jay
> >>
> >>
> >> On Wed, Oct 2, 2013 at 2:09 PM, Robby Findler
> >>  wrote:
> >> > If we do go this way, we should be careful about the subtyping
> >> > relationship
> >> > since we want a predicate that means "will not be mutated and I can
> rely
> >> > on
> >> > that to reason about my library's behavior" and if mutable sets are a
> >> > sub-thing of immutable ones, we might lose that (depending on how
> things
> >> > are
> >> > set up).
> >> >
> >> > Robby
> >> >
> >> >
> >> > On Wed, Oct 2, 2013 at 2:57 PM, Jay McCarthy 
> >> > wrote:
> >> >>
> >> >> No. Mutable sets would implement gen:set and then just have a few
> more
> >> >> methods in the gen:mset interface. Structs can implement any number
> of
> >> >> generics.
> >> >>
> >> >> Jay
> >> >>
> >> >> On Wed, Oct 2, 2013 at 1:31 PM, J. Ian Johnson 
> >> >> wrote:
> >> >> > 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 rebu

Re: [racket-dev] Generics updates

[Jay McCarthy]

This is a good message, but I have one quibble.

I think it makes sense to separate data immutability and logical
immutability. For instance, I may have a library for querying REST
services where a "server" object is represented by an immutable
string. The string is immutable? but the service behind it is not. I
don't want the happenstance of which data was used to construct the
object to give the wrong idea of its mutability.

Jay

On Wed, Oct 2, 2013 at 2:41 PM, Sam Tobin-Hochstadt
 wrote:
> On Wed, Oct 2, 2013 at 4:29 PM, Robby Findler
>  wrote:
>> That sounds right.
>>
>> But just in case there is any confusion on the larger point: predicates as
>> way we check properties to ensure good properties of our abstractions is one
>> of the important things that we have mostly gotten right in Racket.
>> Chaperones, separate pair? and mpair? predicates, and presumably lots of
>> other stuff are the way they are for this kind of reason.
>
> Unfortunately, this is only half-true, I think.  In particular, a very
> large number of our data structures violate this rule: vectors,
> strings, byte strings boxes, hash tables, dictionaries, sequences, and
> so on, all provide the same operations on both mutable and immutable
> variants.  This is also true in general of structs -- a substruct can
> be mutable when the superstruct is immutable.
>
> Ultimately, for the purpose of consistency, I think we should try to
> decide what the 'Rackety' style for this is.  Should we follow the
> lead of hash tables, where `immutable?` is needed to determine
> anything?  Or should we follow the lead of pairs, where there's a
> whole separate type?  And how should this interact with subtyping, as
> in this discussion?
>
> Personally, I think I prefer separate unrelated data structures, with
> a generic interface [1].  Maybe this means we should make `immutable?`
> into a generic.
>
> [1] I think that part of the reason some of these are conflated is
> lack of generic operations.
>
> Sam
>
>>
>> Robby
>>
>>
>> On Wed, Oct 2, 2013 at 3:21 PM, Jay McCarthy  wrote:
>>>
>>> Even if we were to remove set-add! from gen:set and not great gen:mset
>>> then that would not be a vaild property. Generics are a lower bound on
>>> the interface, not an upper bound, so there could be other functions
>>> on the data structure that implement mutation. For instance, a gen:set
>>> could be made for an external resource that was set-like.
>>>
>>> I think what you want is something like gen:fset that has no methods,
>>> but is used for set authors to tag their set as having this property
>>> for the benefit of consumers (which cannot be enforced.) Your library
>>> would then consume fsets and not sets.
>>>
>>> Jay
>>>
>>>
>>> On Wed, Oct 2, 2013 at 2:09 PM, Robby Findler
>>>  wrote:
>>> > If we do go this way, we should be careful about the subtyping
>>> > relationship
>>> > since we want a predicate that means "will not be mutated and I can rely
>>> > on
>>> > that to reason about my library's behavior" and if mutable sets are a
>>> > sub-thing of immutable ones, we might lose that (depending on how things
>>> > are
>>> > set up).
>>> >
>>> > Robby
>>> >
>>> >
>>> > On Wed, Oct 2, 2013 at 2:57 PM, Jay McCarthy 
>>> > wrote:
>>> >>
>>> >> No. Mutable sets would implement gen:set and then just have a few more
>>> >> methods in the gen:mset interface. Structs can implement any number of
>>> >> generics.
>>> >>
>>> >> Jay
>>> >>
>>> >> On Wed, Oct 2, 2013 at 1:31 PM, J. Ian Johnson 
>>> >> wrote:
>>> >> > 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 

Re: [racket-dev] Generics updates

[Sam Tobin-Hochstadt]

On Wed, Oct 2, 2013 at 4:29 PM, Robby Findler
 wrote:
> That sounds right.
>
> But just in case there is any confusion on the larger point: predicates as
> way we check properties to ensure good properties of our abstractions is one
> of the important things that we have mostly gotten right in Racket.
> Chaperones, separate pair? and mpair? predicates, and presumably lots of
> other stuff are the way they are for this kind of reason.

Unfortunately, this is only half-true, I think.  In particular, a very
large number of our data structures violate this rule: vectors,
strings, byte strings boxes, hash tables, dictionaries, sequences, and
so on, all provide the same operations on both mutable and immutable
variants.  This is also true in general of structs -- a substruct can
be mutable when the superstruct is immutable.

Ultimately, for the purpose of consistency, I think we should try to
decide what the 'Rackety' style for this is.  Should we follow the
lead of hash tables, where `immutable?` is needed to determine
anything?  Or should we follow the lead of pairs, where there's a
whole separate type?  And how should this interact with subtyping, as
in this discussion?

Personally, I think I prefer separate unrelated data structures, with
a generic interface [1].  Maybe this means we should make `immutable?`
into a generic.

[1] I think that part of the reason some of these are conflated is
lack of generic operations.

Sam

>
> Robby
>
>
> On Wed, Oct 2, 2013 at 3:21 PM, Jay McCarthy  wrote:
>>
>> Even if we were to remove set-add! from gen:set and not great gen:mset
>> then that would not be a vaild property. Generics are a lower bound on
>> the interface, not an upper bound, so there could be other functions
>> on the data structure that implement mutation. For instance, a gen:set
>> could be made for an external resource that was set-like.
>>
>> I think what you want is something like gen:fset that has no methods,
>> but is used for set authors to tag their set as having this property
>> for the benefit of consumers (which cannot be enforced.) Your library
>> would then consume fsets and not sets.
>>
>> Jay
>>
>>
>> On Wed, Oct 2, 2013 at 2:09 PM, Robby Findler
>>  wrote:
>> > If we do go this way, we should be careful about the subtyping
>> > relationship
>> > since we want a predicate that means "will not be mutated and I can rely
>> > on
>> > that to reason about my library's behavior" and if mutable sets are a
>> > sub-thing of immutable ones, we might lose that (depending on how things
>> > are
>> > set up).
>> >
>> > Robby
>> >
>> >
>> > On Wed, Oct 2, 2013 at 2:57 PM, Jay McCarthy 
>> > wrote:
>> >>
>> >> No. Mutable sets would implement gen:set and then just have a few more
>> >> methods in the gen:mset interface. Structs can implement any number of
>> >> generics.
>> >>
>> >> Jay
>> >>
>> >> On Wed, Oct 2, 2013 at 1:31 PM, J. Ian Johnson 
>> >> wrote:
>> >> > 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 specif

Re: [racket-dev] Generics updates

[Jay McCarthy]

I agree. I think the important thing with generics is unlike mpair?
the set? predicate only necessarily implies that the methods are
available (which is the source of my original complaint). We need to
design the meaning of predicates just like we design the interface. I
think that if we want mset to be a set then set? cannot imply
immutable? but since that is a valuable property, it is worth
designing a predicate that gives it, if only as a human thing.

Jay

On Wed, Oct 2, 2013 at 2:29 PM, Robby Findler
 wrote:
> That sounds right.
>
> But just in case there is any confusion on the larger point: predicates as
> way we check properties to ensure good properties of our abstractions is one
> of the important things that we have mostly gotten right in Racket.
> Chaperones, separate pair? and mpair? predicates, and presumably lots of
> other stuff are the way they are for this kind of reason.
>
> Robby
>
>
> On Wed, Oct 2, 2013 at 3:21 PM, Jay McCarthy  wrote:
>>
>> Even if we were to remove set-add! from gen:set and not great gen:mset
>> then that would not be a vaild property. Generics are a lower bound on
>> the interface, not an upper bound, so there could be other functions
>> on the data structure that implement mutation. For instance, a gen:set
>> could be made for an external resource that was set-like.
>>
>> I think what you want is something like gen:fset that has no methods,
>> but is used for set authors to tag their set as having this property
>> for the benefit of consumers (which cannot be enforced.) Your library
>> would then consume fsets and not sets.
>>
>> Jay
>>
>>
>> On Wed, Oct 2, 2013 at 2:09 PM, Robby Findler
>>  wrote:
>> > If we do go this way, we should be careful about the subtyping
>> > relationship
>> > since we want a predicate that means "will not be mutated and I can rely
>> > on
>> > that to reason about my library's behavior" and if mutable sets are a
>> > sub-thing of immutable ones, we might lose that (depending on how things
>> > are
>> > set up).
>> >
>> > Robby
>> >
>> >
>> > On Wed, Oct 2, 2013 at 2:57 PM, Jay McCarthy 
>> > wrote:
>> >>
>> >> No. Mutable sets would implement gen:set and then just have a few more
>> >> methods in the gen:mset interface. Structs can implement any number of
>> >> generics.
>> >>
>> >> Jay
>> >>
>> >> On Wed, Oct 2, 2013 at 1:31 PM, J. Ian Johnson 
>> >> wrote:
>> >> > 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
>> >

Re: [racket-dev] Generics updates

[Robby Findler]

That sounds right.

But just in case there is any confusion on the larger point: predicates as
way we check properties to ensure good properties of our abstractions is
one of the important things that we have mostly gotten right in Racket.
Chaperones, separate pair? and mpair? predicates, and presumably lots of
other stuff are the way they are for this kind of reason.

Robby


On Wed, Oct 2, 2013 at 3:21 PM, Jay McCarthy  wrote:

> Even if we were to remove set-add! from gen:set and not great gen:mset
> then that would not be a vaild property. Generics are a lower bound on
> the interface, not an upper bound, so there could be other functions
> on the data structure that implement mutation. For instance, a gen:set
> could be made for an external resource that was set-like.
>
> I think what you want is something like gen:fset that has no methods,
> but is used for set authors to tag their set as having this property
> for the benefit of consumers (which cannot be enforced.) Your library
> would then consume fsets and not sets.
>
> Jay
>
>
> On Wed, Oct 2, 2013 at 2:09 PM, Robby Findler
>  wrote:
> > If we do go this way, we should be careful about the subtyping
> relationship
> > since we want a predicate that means "will not be mutated and I can rely
> on
> > that to reason about my library's behavior" and if mutable sets are a
> > sub-thing of immutable ones, we might lose that (depending on how things
> are
> > set up).
> >
> > Robby
> >
> >
> > On Wed, Oct 2, 2013 at 2:57 PM, Jay McCarthy 
> wrote:
> >>
> >> No. Mutable sets would implement gen:set and then just have a few more
> >> methods in the gen:mset interface. Structs can implement any number of
> >> generics.
> >>
> >> Jay
> >>
> >> On Wed, Oct 2, 2013 at 1:31 PM, J. Ian Johnson 
> wrote:
> >> > 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 

Re: [racket-dev] patch for make-base-eval

[Stephen Chang]

Ok thanks for the explanations. I'll try doing one of the last two suggestions.

On Wed, Oct 2, 2013 at 4:09 PM, Ryan Culpepper  wrote:
> No, the 'racket/pretty' module might be declared even if the symbol isn't
> defined (or "mapped") in the namespace:
>
>   > (define ns (make-base-namespace))
>   > (define repl-ns (current-namespace))
>   > (parameterize ((current-namespace ns))
>   (eval '(require (only-in racket/pretty
>   > (parameterize ((current-namespace ns))
>   (namespace-attach-module repl-ns 'racket/pretty))
>   namespace-attach-module: a different module with the same name is
>   already in the destination namespace
> module name: "/opt/racket-5.3.6/collects/racket/pretty.rkt"
> context...:
>  /opt/racket-5.3.6/collects/racket/private/misc.rkt:87:7
>
> And the symbol can be defined in the namespace even if the module is not
> declared:
>
>   > (define ns (make-base-namespace))
>   > (define repl-ns (current-namespace))
>   > (parameterize ((current-namespace ns))
>   (eval '(define pretty-print-handler #t)))
>   > (parameterize ((current-namespace ns))
>   (namespace-variable-value 'pretty-print-handler))
>   #t
>   ;; but racket/pretty is not declared,
>   ;; and #t is not a good print handler
>
> Ryan
>
>
>
> On 10/02/2013 03:58 PM, Stephen Chang wrote:
>>>
>>> A namespace is a mapping from top-level identifiers to whatever they are,
>>> as
>>> well as a separate mapping from module names to modules (roughly). What
>>> you
>>> care about here is the second mapping, but you're checking the first with
>>> the patch.
>>
>>
>> Thanks for the explanation. That helps a lot. So the danger with my
>> check is when someone has another definition of pretty-print handler
>> but racket/pretty has not been attached?
>>
>> But given the context, ie the dynamic require on the next line, it
>> seems like there's already an assumption about what the identifier I'm
>> checking is, so in this specific situation, isnt my check sufficient?
>>
>>
>>
>>>
>>> Robby
>>>
>>>
>>> On Wed, Oct 2, 2013 at 2:45 PM, Stephen Chang 
>>> wrote:


> Whether that identifier exists in the namespace has nothing to do with
> whether racket/pretty can be attached.


 Can you explain this a little more because it's a little unintuitive to
 me?


>
> One option would be for install-pretty-printer! to just catch and
> discard
> the error. Evaluators for some languages would mysteriously not have
> pretty-printing turned on by default.
>
> Another option would be to attach racket/pretty before requiring the
> initial
> language for the namespace.
>
> Another option is use #:pretty-print? #f when attaching racket/pretty
> would
> fail.
>
> Ryan
>
 _
Racket Developers list:
http://lists.racket-lang.org/dev
>>>
>>>
>>>
>
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Generics updates

[Jay McCarthy]

Even if we were to remove set-add! from gen:set and not great gen:mset
then that would not be a vaild property. Generics are a lower bound on
the interface, not an upper bound, so there could be other functions
on the data structure that implement mutation. For instance, a gen:set
could be made for an external resource that was set-like.

I think what you want is something like gen:fset that has no methods,
but is used for set authors to tag their set as having this property
for the benefit of consumers (which cannot be enforced.) Your library
would then consume fsets and not sets.

Jay


On Wed, Oct 2, 2013 at 2:09 PM, Robby Findler
 wrote:
> If we do go this way, we should be careful about the subtyping relationship
> since we want a predicate that means "will not be mutated and I can rely on
> that to reason about my library's behavior" and if mutable sets are a
> sub-thing of immutable ones, we might lose that (depending on how things are
> set up).
>
> Robby
>
>
> On Wed, Oct 2, 2013 at 2:57 PM, Jay McCarthy  wrote:
>>
>> No. Mutable sets would implement gen:set and then just have a few more
>> methods in the gen:mset interface. Structs can implement any number of
>> generics.
>>
>> Jay
>>
>> On Wed, Oct 2, 2013 at 1:31 PM, J. Ian Johnson  wrote:
>> > 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
>> >> c

Re: [racket-dev] Generics updates

[Robby Findler]

If we do go this way, we should be careful about the subtyping relationship
since we want a predicate that means "will not be mutated and I can rely on
that to reason about my library's behavior" and if mutable sets are a
sub-thing of immutable ones, we might lose that (depending on how things
are set up).

Robby


On Wed, Oct 2, 2013 at 2:57 PM, Jay McCarthy  wrote:

> No. Mutable sets would implement gen:set and then just have a few more
> methods in the gen:mset interface. Structs can implement any number of
> generics.
>
> Jay
>
> On Wed, Oct 2, 2013 at 1:31 PM, J. Ian Johnson  wrote:
> > 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.

Re: [racket-dev] patch for make-base-eval

[Ryan Culpepper]

No, the 'racket/pretty' module might be declared even if the symbol 
isn't defined (or "mapped") in the namespace:


  > (define ns (make-base-namespace))
  > (define repl-ns (current-namespace))
  > (parameterize ((current-namespace ns))
  (eval '(require (only-in racket/pretty
  > (parameterize ((current-namespace ns))
  (namespace-attach-module repl-ns 'racket/pretty))
  namespace-attach-module: a different module with the same name is
  already in the destination namespace
module name: "/opt/racket-5.3.6/collects/racket/pretty.rkt"
context...:
 /opt/racket-5.3.6/collects/racket/private/misc.rkt:87:7

And the symbol can be defined in the namespace even if the module is not 
declared:


  > (define ns (make-base-namespace))
  > (define repl-ns (current-namespace))
  > (parameterize ((current-namespace ns))
  (eval '(define pretty-print-handler #t)))
  > (parameterize ((current-namespace ns))
  (namespace-variable-value 'pretty-print-handler))
  #t
  ;; but racket/pretty is not declared,
  ;; and #t is not a good print handler

Ryan


On 10/02/2013 03:58 PM, Stephen Chang wrote:

A namespace is a mapping from top-level identifiers to whatever they are, as
well as a separate mapping from module names to modules (roughly). What you
care about here is the second mapping, but you're checking the first with
the patch.


Thanks for the explanation. That helps a lot. So the danger with my
check is when someone has another definition of pretty-print handler
but racket/pretty has not been attached?

But given the context, ie the dynamic require on the next line, it
seems like there's already an assumption about what the identifier I'm
checking is, so in this specific situation, isnt my check sufficient?





Robby


On Wed, Oct 2, 2013 at 2:45 PM, Stephen Chang  wrote:



Whether that identifier exists in the namespace has nothing to do with
whether racket/pretty can be attached.


Can you explain this a little more because it's a little unintuitive to
me?




One option would be for install-pretty-printer! to just catch and
discard
the error. Evaluators for some languages would mysteriously not have
pretty-printing turned on by default.

Another option would be to attach racket/pretty before requiring the
initial
language for the namespace.

Another option is use #:pretty-print? #f when attaching racket/pretty
would
fail.

Ryan


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





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

Re: [racket-dev] patch for make-base-eval

[Robby Findler]

Right, exactly.

Which is why Ryan's earlier suggestions are better: You can avoid all this
mess.

Robby


On Wed, Oct 2, 2013 at 2:59 PM, Ryan Culpepper  wrote:

> Yes. Also, it's not enough to check that 'racket/pretty' (or really, the
> name 'racket/pretty' resolves to) isn't declared in the target namespace;
> you must also check any module it (transitively) requires is either
> undeclared or was attached from the same namespace you want to attach
> racket/pretty from.
>
> Ryan
>
>
>
> On 10/02/2013 03:50 PM, Robby Findler wrote:
>
>> A namespace is a mapping from top-level identifiers to whatever they
>> are, as well as a separate mapping from module names to modules
>> (roughly). What you care about here is the second mapping, but you're
>> checking the first with the patch.
>>
>> Robby
>>
>>
>> On Wed, Oct 2, 2013 at 2:45 PM, Stephen Chang > > wrote:
>>
>>  > Whether that identifier exists in the namespace has nothing to do
>> with
>>  > whether racket/pretty can be attached.
>>
>> Can you explain this a little more because it's a little unintuitive
>> to me?
>>
>>
>>  >
>>  > One option would be for install-pretty-printer! to just catch and
>> discard
>>  > the error. Evaluators for some languages would mysteriously not
>> have
>>  > pretty-printing turned on by default.
>>  >
>>  > Another option would be to attach racket/pretty before requiring
>> the initial
>>  > language for the namespace.
>>  >
>>  > Another option is use #:pretty-print? #f when attaching
>> racket/pretty would
>>  > fail.
>>  >
>>  > Ryan
>>  >
>> _
>>Racket Developers list:
>> http://lists.racket-lang.org/**dev 
>>
>>
>>
>
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] patch for make-base-eval

[Ryan Culpepper]

Yes. Also, it's not enough to check that 'racket/pretty' (or really, the 
name 'racket/pretty' resolves to) isn't declared in the target 
namespace; you must also check any module it (transitively) requires is 
either undeclared or was attached from the same namespace you want to 
attach racket/pretty from.


Ryan


On 10/02/2013 03:50 PM, Robby Findler wrote:

A namespace is a mapping from top-level identifiers to whatever they
are, as well as a separate mapping from module names to modules
(roughly). What you care about here is the second mapping, but you're
checking the first with the patch.

Robby


On Wed, Oct 2, 2013 at 2:45 PM, Stephen Chang mailto:stch...@ccs.neu.edu>> wrote:

 > Whether that identifier exists in the namespace has nothing to do
with
 > whether racket/pretty can be attached.

Can you explain this a little more because it's a little unintuitive
to me?


 >
 > One option would be for install-pretty-printer! to just catch and
discard
 > the error. Evaluators for some languages would mysteriously not have
 > pretty-printing turned on by default.
 >
 > Another option would be to attach racket/pretty before requiring
the initial
 > language for the namespace.
 >
 > Another option is use #:pretty-print? #f when attaching
racket/pretty would
 > fail.
 >
 > Ryan
 >
_
   Racket Developers list:
http://lists.racket-lang.org/dev




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

Re: [racket-dev] patch for make-base-eval

[Stephen Chang]

> A namespace is a mapping from top-level identifiers to whatever they are, as
> well as a separate mapping from module names to modules (roughly). What you
> care about here is the second mapping, but you're checking the first with
> the patch.

Thanks for the explanation. That helps a lot. So the danger with my
check is when someone has another definition of pretty-print handler
but racket/pretty has not been attached?

But given the context, ie the dynamic require on the next line, it
seems like there's already an assumption about what the identifier I'm
checking is, so in this specific situation, isnt my check sufficient?



>
> Robby
>
>
> On Wed, Oct 2, 2013 at 2:45 PM, Stephen Chang  wrote:
>>
>> > Whether that identifier exists in the namespace has nothing to do with
>> > whether racket/pretty can be attached.
>>
>> Can you explain this a little more because it's a little unintuitive to
>> me?
>>
>>
>> >
>> > One option would be for install-pretty-printer! to just catch and
>> > discard
>> > the error. Evaluators for some languages would mysteriously not have
>> > pretty-printing turned on by default.
>> >
>> > Another option would be to attach racket/pretty before requiring the
>> > initial
>> > language for the namespace.
>> >
>> > Another option is use #:pretty-print? #f when attaching racket/pretty
>> > would
>> > fail.
>> >
>> > Ryan
>> >
>> _
>>   Racket Developers list:
>>   http://lists.racket-lang.org/dev
>
>
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Generics updates

[Jay McCarthy]

No. Mutable sets would implement gen:set and then just have a few more
methods in the gen:mset interface. Structs can implement any number of
generics.

Jay

On Wed, Oct 2, 2013 at 1:31 PM, J. Ian Johnson  wrote:
> 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



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

Re: [racket-dev] patch for make-base-eval

[Robby Findler]

A namespace is a mapping from top-level identifiers to whatever they are,
as well as a separate mapping from module names to modules (roughly). What
you care about here is the second mapping, but you're checking the first
with the patch.

Robby


On Wed, Oct 2, 2013 at 2:45 PM, Stephen Chang  wrote:

> > Whether that identifier exists in the namespace has nothing to do with
> > whether racket/pretty can be attached.
>
> Can you explain this a little more because it's a little unintuitive to me?
>
>
> >
> > One option would be for install-pretty-printer! to just catch and discard
> > the error. Evaluators for some languages would mysteriously not have
> > pretty-printing turned on by default.
> >
> > Another option would be to attach racket/pretty before requiring the
> initial
> > language for the namespace.
> >
> > Another option is use #:pretty-print? #f when attaching racket/pretty
> would
> > fail.
> >
> > Ryan
> >
> _
>   Racket Developers list:
>   http://lists.racket-lang.org/dev
>
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] patch for make-base-eval

[Stephen Chang]

> Whether that identifier exists in the namespace has nothing to do with
> whether racket/pretty can be attached.

Can you explain this a little more because it's a little unintuitive to me?


>
> One option would be for install-pretty-printer! to just catch and discard
> the error. Evaluators for some languages would mysteriously not have
> pretty-printing turned on by default.
>
> Another option would be to attach racket/pretty before requiring the initial
> language for the namespace.
>
> Another option is use #:pretty-print? #f when attaching racket/pretty would
> fail.
>
> Ryan
>
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] patch for make-base-eval

[Robby Findler]

The last two sound better than the others to me, FWIW.

Robby


On Wed, Oct 2, 2013 at 2:37 PM, Ryan Culpepper  wrote:

> On 10/02/2013 03:19 PM, Stephen Chang wrote:
>
>> Can I push the attached (1-line) patch? I don't have a good grasp of
>> namespaces so I would like someone to review it first.
>>
>> Right now, make-base-eval tries to attach racket/pretty to the
>> namespace regardless of whether it's already there, which sometimes
>> results in an exception (for example if the #lang given to
>> make-base-eval is racket).
>>
>> The patch simply first checks if the desired identifier is already there.
>>
>
> Whether that identifier exists in the namespace has nothing to do with
> whether racket/pretty can be attached.
>
> One option would be for install-pretty-printer! to just catch and discard
> the error. Evaluators for some languages would mysteriously not have
> pretty-printing turned on by default.
>
> Another option would be to attach racket/pretty before requiring the
> initial language for the namespace.
>
> Another option is use #:pretty-print? #f when attaching racket/pretty
> would fail.
>
> Ryan
>
> _
>  Racket Developers list:
>  http://lists.racket-lang.org/**dev 
>
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] patch for make-base-eval

[Ryan Culpepper]

On 10/02/2013 03:19 PM, Stephen Chang wrote:

Can I push the attached (1-line) patch? I don't have a good grasp of
namespaces so I would like someone to review it first.

Right now, make-base-eval tries to attach racket/pretty to the
namespace regardless of whether it's already there, which sometimes
results in an exception (for example if the #lang given to
make-base-eval is racket).

The patch simply first checks if the desired identifier is already there.


Whether that identifier exists in the namespace has nothing to do with 
whether racket/pretty can be attached.


One option would be for install-pretty-printer! to just catch and 
discard the error. Evaluators for some languages would mysteriously not 
have pretty-printing turned on by default.


Another option would be to attach racket/pretty before requiring the 
initial language for the namespace.


Another option is use #:pretty-print? #f when attaching racket/pretty 
would fail.


Ryan

_
 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] Generics updates

[Jay McCarthy]

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-dev] patch for make-base-eval

[Stephen Chang]

Can I push the attached (1-line) patch? I don't have a good grasp of
namespaces so I would like someone to review it first.

Right now, make-base-eval tries to attach racket/pretty to the
namespace regardless of whether it's already there, which sometimes
results in an exception (for example if the #lang given to
make-base-eval is racket).

The patch simply first checks if the desired identifier is already there.


fix-make-base-eval-pretty.patch
Description: Binary data
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] A few packages not in 'main-distribution'

[Sam Tobin-Hochstadt]

Ok.  It appears slightly odd in the pkg catalog list, in which
everything else listed by default is (a) outside of the main
repository and (b) linked to a git repository.  I'm not sure what the
right solution there is.

Sam

On Wed, Oct 2, 2013 at 11:25 AM, Matthew Flatt  wrote:
> The `gui-pkg-manager` omission is intentional, since it's the same as
> DrRacket's "Package Manager..." menu item, and I think it's best to
> keep the number of GUI applications to a minimum (especially for Mac OS
> X users). I have no strong objection if others want to include it,
> though.
>
> At Wed, 2 Oct 2013 10:52:57 -0400, Sam Tobin-Hochstadt wrote:
>> The packages 'gui-pkg-manager' and 'distributed-places' are on the pkg
>> catalog, but not in 'main-distribution'.  I'm pushing a change for the
>> latter, which appears to just be an oversight, but is the same true
>> for the 'gui-pkg-manager'?
>>
>> Sam
>
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] package system, minimal builds and more

[Jay McCarthy]

On Wed, Oct 2, 2013 at 8:39 AM, Sam Tobin-Hochstadt
 wrote:
>> * redownload after fail
>> the package manager seems to download every packet again after a failed
>> install or user interruption. Would it be worth to reuse the once downloaded
>> zips if the checksum is the same (similar to the behavior of apt).
>
> I believe the package manager knows how to do this, but it doesn't
> seem to be doing it here, even though there's checksum information in
> the catalog files. Jay, do you know what's going on here?

I think I need more details.

If you have pkg A installed, then it should only download a small
checksum to see if A needs to be updated. If this is broken, then it
is an error.

If you do NOT have pkg A installed, then it will download the full
file. If that install fails, then 'raco pkg' cleans up after itself
and deletes the things it downloaded. Apt does not do this and saves
everything in a temporary directory that must be manually cleaned. I
did not implement that because it feels wrong to run a command like
'raco pkg clean-old-tmp-files' or something. But it sounds like you
want that?

Jay

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

Re: [racket-dev] A few packages not in 'main-distribution'

[Matthew Flatt]

The `gui-pkg-manager` omission is intentional, since it's the same as
DrRacket's "Package Manager..." menu item, and I think it's best to
keep the number of GUI applications to a minimum (especially for Mac OS
X users). I have no strong objection if others want to include it,
though.

At Wed, 2 Oct 2013 10:52:57 -0400, Sam Tobin-Hochstadt wrote:
> The packages 'gui-pkg-manager' and 'distributed-places' are on the pkg
> catalog, but not in 'main-distribution'.  I'm pushing a change for the
> latter, which appears to just be an oversight, but is the same true
> for the 'gui-pkg-manager'?
> 
> Sam

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

[racket-dev] A few packages not in 'main-distribution'

[Sam Tobin-Hochstadt]

The packages 'gui-pkg-manager' and 'distributed-places' are on the pkg
catalog, but not in 'main-distribution'.  I'm pushing a change for the
latter, which appears to just be an oversight, but is the same true
for the 'gui-pkg-manager'?

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

Re: [racket-dev] package system, minimal builds and more

[Sam Tobin-Hochstadt]

On Tue, Oct 1, 2013 at 9:20 AM, Tobias Hammer  wrote:
> Hi,
>
> i played a bit with the new package system, minimal installs and cross
> compiling. It works pretty good but i have a few problems and
> remarks/questions.
> I start with a fresh yesterdays minimal source
> (min-racket-5.90.0.9-src.tgz), build it (natively for linux) and try to
> install packages.
>
> (Given in no particular order)

First, thanks for the feedback!

> * compiler-lib install fails with the following error
> ./bin/raco pkg install -i compiler-lib
> Resolving "compiler-lib" via
> http://www.eecs.northwestern.edu/plt/snapshots/20130929-6d4ff30/catalog/
> Resolving "compiler-lib" via https://pkg.racket-lang.org
> Downloading checksum for compiler-lib
> Downloading
> http://racket-packages.s3-us-west-2.amazonaws.com/pkgs/b824ed762533834659b5f0ee047deafb101acc74/compiler-lib.zip
> raco pkg install: package conflicts with existing installed
>   package: compiler-lib
>   module path: compiler/option
>
> As its needed by racket-doc and similar it blocks install of a lot of
> packets

The problem here seems to be that the below problem causes it to fall
back to an older version from the central pkg catalog, which doesn't
work because of refactoring between when your snapshot was from, and
when the upload of that zip file to the pkg catalog happened.

Once we actually release the next version, we won't move things around
in ways that cause these compatibility issues.

I manually edited etc/config.rktd to point to the Utah snapshot page,
and then it worked.

> * the snapshot catalog seems to be nonexistent
> If i browse to
> http://www.eecs.northwestern.edu/plt/snapshots/20130929-6d4ff30/catalog/, i
> always get a 404. Is this intended?

I think this is a bug in how the Northwestern snapshots are set up,
because they should go to 'plt.eecs.northwestern.edu/snapshots/...'
instead.  I've cc'ed Robby, who can hopefully fix this.

> * redownload after fail
> the package manager seems to download every packet again after a failed
> install or user interruption. Would it be worth to reuse the once downloaded
> zips if the checksum is the same (similar to the behavior of apt).

I believe the package manager knows how to do this, but it doesn't
seem to be doing it here, even though there's checksum information in
the catalog files. Jay, do you know what's going on here?

> * raco pkg warnings
> On every command i get
> warning: tool "pkg" registered twice: "pkg" and
> #
> warning: tool "setup" registered twice: "setup" and
> #
> warning: tool "link" registered twice: "link" and
> #
>
> /home/hamm_to/tmp/racket/_tmp/racket-5.90.0.9/ is the used installation.

What command did you run to get this error? I haven't been able to replicate it.

> * More verbose require error
> If i require something nonexistent i get an exception like
> (require fdfsdfsdf)
> ; readline-input:4:8: collection not found
> ;   for module path: fdfsdfsdf
> ;   collection: "fdfsdfsdf"
> ;   in collection directories:
> ;/home/hamm_to/.racket/snapshot/collects
> ;/volume/USERSTORE/hamm_to/tmp/racket-qnx/linux-racket-5.90.0.9/collects
> ;/home/hamm_to/.racket/snapshot/collects
> ;/volume/USERSTORE/hamm_to/tmp/racket-qnx/linux-racket-5.90.0.9/collects
> ;... [22 additional linked and package directories]
>
> Is it possible to somehow show these additional 22 entries? Maybe not in the
> error but from raco?

You can see these with `raco pkg show`.  Is that what you're looking for?

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