Re: [racket-dev] syntax/syntax proposal
Yesterday, Ryan Culpepper wrote: The reorganization would discourage people from trying to add contracts to modules in the racket/pre-contracts subcollection. It's apparent from the name, as opposed to being discoverable by running the compiler. Oh you mean actually *move* the files there? That seems like a bad idea since some of these are in their own collection because of other reasons. For example, there's dependencies on pprint and on unstable. It would also encourage people to add contracts to every other library. [...] This is a very minor kind of encouragement -- it applies only to people who edit core code. For most people, the encouragement is already there since from their POV contracts can be added into any code they write. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] syntax/syntax proposal
On Friday, Ryan Culpepper wrote: On 06/15/2012 01:12 PM, Asumu Takikawa wrote: Hi all, Recently I was using the `stx-car` function from `syntax/stx`. At some point, I had called it on a non-syntax pair and the error message came from `car`, which is used inside the implementation of `stx-car`. I thought it would be nice to add contracts in `syntax/stx` for better error messages, but it turns out that the contract library depends on it and so it's impossible to do without introducing cycles. So I would like to propose a `syntax/syntax` library with the following: * provides `syntax/stx` functions with contracts attached (caveat: core libraries like `racket/contract` would still use `syntax/stx`) * for consistency with the rest of the language, `stx-car` and friends would be renamed to use the `syntax-` prefix instead of `stx-`. -1 -1 too, because it's dealing with a dependency spaghetti situation by adding another inter-collection line instead of removing one. I sometimes wonder if we should make a racket/pre-contracts subcollection and just stuff all of racket/contract/base's dependencies in there, then say everything else is allowed (maybe even expected) to use contracts. I don't see how that would help -- you'll still get the same errors. As for the above problem, `syntax/stx' is pretty simple, so maybe the functionality can be done directly in the contracts code. (And that removes a dependency.) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] syntax/syntax proposal
On Jun 21, 2012, at 11:26 AM, Eli Barzilay wrote: I don't see how that would help -- you'll still get the same errors. Ouch. That's again a misunderstanding of contracts. The idea is that contracts specify in interfaces what is expected, not deep inside some code. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] syntax/syntax proposal
A few minutes ago, Matthias Felleisen wrote: On Jun 21, 2012, at 11:26 AM, Eli Barzilay wrote: I don't see how that would help -- you'll still get the same errors. Ouch. That's again a misunderstanding of contracts. The idea is that contracts specify in interfaces what is expected, not deep inside some code. I'm not talking about having contracts -- just about this part: [...] make a racket/pre-contracts subcollection and just stuff all of racket/contract/base's dependencies in there, then say everything else is allowed (maybe even expected) to use contracts. You can already know that, for example, `syntax/stx' is part of that because you'll get a cyclic module dependency error if you try to add contracts to it. (And that error would be the same whether it's listed in a new `racket/pre-contracts' module.) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] syntax/syntax proposal
On 06/21/2012 09:53 AM, Eli Barzilay wrote: A few minutes ago, Matthias Felleisen wrote: On Jun 21, 2012, at 11:26 AM, Eli Barzilay wrote: I don't see how that would help -- you'll still get the same errors. Ouch. That's again a misunderstanding of contracts. The idea is that contracts specify in interfaces what is expected, not deep inside some code. I'm not talking about having contracts -- just about this part: [...] make a racket/pre-contracts subcollection and just stuff all of racket/contract/base's dependencies in there, then say everything else is allowed (maybe even expected) to use contracts. You can already know that, for example, `syntax/stx' is part of that because you'll get a cyclic module dependency error if you try to add contracts to it. (And that error would be the same whether it's listed in a new `racket/pre-contracts' module.) The reorganization would discourage people from trying to add contracts to modules in the racket/pre-contracts subcollection. It's apparent from the name, as opposed to being discoverable by running the compiler. It would also encourage people to add contracts to every other library. Modules like syntax/stx and racket/list currently don't use contracts; they use hand-coded checks instead (or they just don't check their arguments). Is racket/contract/base a heavy dependency that we want to avoid for such libraries? Ryan _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] syntax/syntax proposal
On Jun 21, 2012, at 4:23 PM, Ryan Culpepper wrote: The reorganization would discourage people from trying to add contracts to modules in the racket/pre-contracts subcollection. It's apparent from the name, as opposed to being discoverable by running the compiler. It would also encourage people to add contracts to every other library. Amen. Modules like syntax/stx and racket/list currently don't use contracts; they use hand-coded checks instead (or they just don't check their arguments). Is racket/contract/base a heavy dependency that we want to avoid for such libraries? _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] syntax/syntax proposal
On Fri, Jun 15, 2012 at 3:39 PM, Matthias Felleisen matth...@ccs.neu.edu wrote: I sometimes wonder if we should make a racket/pre-contracts subcollection and just stuff all of racket/contract/base's dependencies in there, then say everything else is allowed (maybe even expected) to use contracts. +1 +2 Me too! -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] syntax/syntax proposal
At Fri, 15 Jun 2012 15:12:05 -0400, Asumu Takikawa wrote: * for consistency with the rest of the language, `stx-car` and friends would be renamed to use the `syntax-` prefix instead of `stx-`. +1 I always get these names wrong. * the name of the library is also consistent with the rest of the language. +1 Vincent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] syntax/syntax proposal
On 2012-06-15 15:12:05 -0400, Asumu Takikawa wrote: I've attached a patch that implements this. Any comments? Just realized after I sent it that I'd change two things in the patch: * `syntax-null?`, `syntax-pair?`, `syntax-list?` would be defined using `procedure-rename` to get better contract error messages. * the `#:rest` contract is wrong, it'd really be `(listof syntax-list?)` And of course there'd be documentation in the final version too. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] syntax/syntax proposal
Can we get syntax-first and syntax-rest while you're at it? (I looked for these just a couple of days ago, and like Vincent, I got the stx- wrong) _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] syntax/syntax proposal
At Fri, 15 Jun 2012 15:09:15 -0600, Ryan Culpepper wrote: The 'stx-*' functions work on values that aren't syntax objects, so renaming them to 'syntax-*' would be misleading. Given the name, I would have thought they only worked on syntax objects. Roughly, stx = syntax | null | (cons syntax stx) I had no idea that was the case. The name certainly does not suggest that. The fact that the metavariable for syntax objects is `stx' also does not help. In which cases would I use an `stx' as opposed to a syntax object? I sometimes wonder if we should make a racket/pre-contracts subcollection and just stuff all of racket/contract/base's dependencies in there, then say everything else is allowed (maybe even expected) to use contracts. +1 Vincent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] syntax/syntax proposal
On Jun 15, 2012, at 5:25 PM, Vincent St-Amour wrote: Roughly, stx = syntax | null | (cons syntax stx) I had no idea that was the case. The name certainly does not suggest that. The fact that the metavariable for syntax objects is `stx' also does not help. In which cases would I use an `stx' as opposed to a syntax object? Sounds like this should be documented and possibly even contracted. I sometimes wonder if we should make a racket/pre-contracts subcollection and just stuff all of racket/contract/base's dependencies in there, then say everything else is allowed (maybe even expected) to use contracts. +1 +2 _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] syntax/syntax proposal
On 2012-06-15 15:09:15 -0600, Ryan Culpepper wrote: The 'stx-*' functions work on values that aren't syntax objects, so renaming them to 'syntax-*' would be misleading. Is that really so misleading though? There is already precedent for functions which take arguments not exactly matching their prefix. `list-ref` works on non-`list?` things, for example. Other examples include `syntax-local-module-exports`, `syntax-local-make-delta-introducer`, `syntax-local-module-required-identifiers`, and so on. 'syntax-list' already exists and means something different from 'stx-list'. This could be `syntax-list-list` instead maybe. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] syntax/syntax proposal
On 2012-06-15 17:39:27 -0400, Matthias Felleisen wrote: Sounds like this should be documented and possibly even contracted. The contracts I wrote in the patch do reflect this via the `stx-pair?` predicate, FYI. By the way, the definition of a syntax pair in the documentation is this: A syntax pair is a pair containing a syntax object as its first element, and either the empty list, a syntax pair, or a syntax object as its second element. I may just be confused, but doesn't this conflict with the documented behavior of the `stx-pair?` predicate? Returns #t if v is either a pair or a syntax object representing a pair (see syntax pair). Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
