Re: [racket-dev] impersonate-struct with only impersonator properties
At Tue, 19 Jun 2012 23:25:47 -0700, Eric Dobson wrote: > The documentation for impersonate-struct and chaperone-struct differ > in the fact that chaperone-struct explicitly says that only > impersonator properties are not allowed. But the implementation > doesn't allow it for either of them. Either the documentation or the > implementation is wrong. The docs are wrong. I'll fix that... > What is the reasoning behind the implementation? At some level, all Racket values are implemented as structs, but the implementation of impersonator properties relies on a particular representation of structs. By supplying some operation to replace other than an impersonator-property accessor, you provide a witness that the value is represented in a way that `impersonate-struct' can handle (without requiring that, say, `struct?' exposes the representation to everyone). _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Bug in Racket's I/O?
Thanks --- I've pushed a repair. At Wed, 20 Jun 2012 20:25:35 -0400, Tony Garnock-Jones wrote: > Sorry, I should have filed a bug report instead of mailing the list. I'm > filing the report now. > > On 2012-06-20 8:22 PM, Tony Garnock-Jones wrote: > > Hi all, > > > > I think I've found a bug in Racket's I/O. Please interpret the following > > text as relating to the attached tarball with a small example of the > > problem. The problem manifests for me on both platforms I've tried, OS X > > and Linux. > > > > When `sync`ing on `read-bytes-evt` at the same time as on `alarm-evt`, > > it seems that if the `read-bytes-evt` would have come ready but the > > `alarm-evt` is the one actually chosen, the input from > > `read-bytes-evt` gets corrupted. This only seems to happen if a single > > `read-bytes-evt` instance is reused! If a fresh `read-bytes-evt` is > > constructed every time, the input stream remains uncorrupted. > > > > To see this, run `racket buggy-server.rkt 0`, which uses a single > > `read-bytes-evt` instance but does not use any `alarm-evt` > > instances. In another terminal, run `./run-test-osx.sh` (or > > `./run-test-linux.sh`, as appropriate). The program > > `./run-test-osx.sh` should terminate without producing any output. > > > > Now, kill off the instance of `buggy-server.rkt`, and start another, > > this time by running `racket buggy-server.rkt 1`. This instance uses > > both a single `read-bytes-evt` instance and an `alarm-evt` > > instance. Now, running `./run-test-osx.sh` should still produce no > > output, but in fact on most runs, some output (from diffing the input > > against the output of the socket) is produced, meaning that the echoed > > output differed from the input. > > > > Regards, > > Tony > > > > > > > > _ > > Racket Developers list: > > http://lists.racket-lang.org/dev > > > > _ > Racket Developers list: > http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Error message proposal
At Thu, 21 Jun 2012 05:21:38 -0400, Eli Barzilay wrote: > To translate the errors you've written (as would be shown by the > default display handler, when showing all fields too): > > > (+ 1 'a) > +: contract violation > `+' expected a number in its 2nd argument; given 'a > expected: number? > given: 'a > argument position: 2 > other arguments: > 1 > context: > [...] > > (add1 1 2 3) > add1: arity mismatch > `add1' does not expect 3 arguments > expected number of arguments: 1 > given number of arguments: 3 > arguments: > 1 > 2 > 3 > technical note: this is a contract violation for the application > form > context: > [...] I don't like the way these example have the error message twice: once in prose and one in field-and-value form. It's difficult enough to get either one of those right, but it's particularly difficult to construct prose right, which is why the new convention encourages relatively static prose. I've pushed a set of changes that moves the srcloc back to the front, codifies a multi-line prose format for the start of a message, codifies "..." as a suffix for fields that may be too noisy (and that an environment may choose to hide), and adjusts various existing error messages. We can change details like the "..." suffix, of course, but that amount of format/protocol change is about what seems practical and worthwhile to me. Meanwhile, we should look more carefully at the content of specific error messages to see if we can improve either the wording or the information provided in fields. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Comparison functions and the `data' collection
On 6/21/12 6:04 PM, Ryan Culpepper wrote: On 06/21/2012 09:38 AM, Eli Barzilay wrote: More than a week ago, Ryan Culpepper wrote: On 06/11/2012 02:36 PM, Eli Barzilay wrote: Yesterday, Danny Yoo wrote: It's a little unfortunate that there's a slight impedance mismatch between what datum-order provides and what sort expects; the my-less-than function in the example adapts the output of datum-order so it can be used with sort. Thanks for pointing it out (I didn't know about it). When I looked into this, I saw that in addition to `data/order' there is also an issue with `data/heap'. It certainly does look like a problem worth addressing. The thing is that are two common ways to specify comparison functions: (a) three-valued comparison functions returning -1/0/+1, (b) a boolan strictly-smaller-than predicate. The first is common in several mainsteam languages and the second is traditionally common in lisps (which leads to its use in the sort function). The issues are described very thoroughly in srfi-67 -- specifically, see the first two subsections in section 6. I highly recommend reading that for this discussion. They decide to go with option (a), with an explanation for the choice of a three-valued function and for their choice of -1/0/+1 values. I don't remember if I discovered srfi-67 before or after I added data/order. In any case, I disagree with its rationale for -1/0/+1: I dislike the idea of performing arithmetic on orderings. (See below.) OTOH, data/order is used primarily by the ordered dictionary types (data/splay-tree, data/skip-list), so it's probably missing operations and conveniences for tasks like sorting a list. (I take it that they will be added, then...) 2. The `data/order' interface has several problems that I think is best to resolve. - Regadless of the above, it seems like a good idea to extend the interface with a simple boolean predicate. Maybe something like `datum From an order you can get the less-than and equality predicates: (order- Yes, of course this is easy. I can also do that `case' in a tiny λ. But it should be part of the library. On Saturday, Matthias Felleisen wrote: This response leaves us with the impression that we whimsically challenged established conventions in the general and the Lisp-specific PL family. In addition it leaves us with inconsistencies across our libraries, which I am coming to consider more and more as a serious problem. Yes, that was exactly why I raised it. Since it's core-ish functionality, having it behave well wrt expectations is IMO extremely important. Right now we have a sad state of two different incompatibilities there, and I don't see any good explanation except for the "I disagree/dislike" (in contrast to the srfi). Because of such expectations and because of existing code, I'd follow that without thinking about what might the right choice be. (Personally, I now think that the more lenient approach of any numbers, negative, 0, or positive is even better -- and I can also explain and justify why I think that, but that's irrelevant.) Now -- I would be the last one to defend "established tradition" over "getting things right" but at a minimum, the reasoning of why we challenge tradition should be noted. +7 There's an advocate of my position in the SRFI discussion archives. See the following messages by Panu Kalliokoski: http://srfi.schemers.org/srfi-67/mail-archive/msg00021.html http://srfi.schemers.org/srfi-67/mail-archive/msg00023.html http://srfi.schemers.org/srfi-67/mail-archive/msg00025.html Of course, the SRFI still went the other way. I would be happy to add functions to convert between the two conventions. I think {-1,0,1} is the worst of all worlds. I prefer the more lenient approach of allowing any number[*]. This follows the Lisp tradition of returning "more than just the truth", since a comparison can also convey the difference between the arguments; in other words `-' is a comparison function, which is the trick I use to remember how to interpret the result of compare functions in Java, for example. If we really want to break tradition by restricting to "just the truth" (a three-valued function), meaningful symbols is my preference over {-1,0,1}. [*] Well, reals minus infinities and nans. David _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Comparison functions and the `data' collection
On 06/21/2012 09:38 AM, Eli Barzilay wrote: More than a week ago, Ryan Culpepper wrote: On 06/11/2012 02:36 PM, Eli Barzilay wrote: Yesterday, Danny Yoo wrote: It's a little unfortunate that there's a slight impedance mismatch between what datum-order provides and what sort expects; the my-less-than function in the example adapts the output of datum-order so it can be used with sort. Thanks for pointing it out (I didn't know about it). When I looked into this, I saw that in addition to `data/order' there is also an issue with `data/heap'. It certainly does look like a problem worth addressing. The thing is that are two common ways to specify comparison functions: (a) three-valued comparison functions returning -1/0/+1, (b) a boolan strictly-smaller-than predicate. The first is common in several mainsteam languages and the second is traditionally common in lisps (which leads to its use in the sort function). The issues are described very thoroughly in srfi-67 -- specifically, see the first two subsections in section 6. I highly recommend reading that for this discussion. They decide to go with option (a), with an explanation for the choice of a three-valued function and for their choice of -1/0/+1 values. I don't remember if I discovered srfi-67 before or after I added data/order. In any case, I disagree with its rationale for -1/0/+1: I dislike the idea of performing arithmetic on orderings. (See below.) OTOH, data/order is used primarily by the ordered dictionary types (data/splay-tree, data/skip-list), so it's probably missing operations and conveniences for tasks like sorting a list. (I take it that they will be added, then...) 2. The `data/order' interface has several problems that I think is best to resolve. - Regadless of the above, it seems like a good idea to extend the interface with a simple boolean predicate. Maybe something like `datum From an order you can get the less-than and equality predicates: (order- Yes, of course this is easy. I can also do that `case' in a tiny λ. But it should be part of the library. On Saturday, Matthias Felleisen wrote: This response leaves us with the impression that we whimsically challenged established conventions in the general and the Lisp-specific PL family. In addition it leaves us with inconsistencies across our libraries, which I am coming to consider more and more as a serious problem. Yes, that was exactly why I raised it. Since it's core-ish functionality, having it behave well wrt expectations is IMO extremely important. Right now we have a sad state of two different incompatibilities there, and I don't see any good explanation except for the "I disagree/dislike" (in contrast to the srfi). Because of such expectations and because of existing code, I'd follow that without thinking about what might the right choice be. (Personally, I now think that the more lenient approach of any numbers, negative, 0, or positive is even better -- and I can also explain and justify why I think that, but that's irrelevant.) Now -- I would be the last one to defend "established tradition" over "getting things right" but at a minimum, the reasoning of why we challenge tradition should be noted. +7 There's an advocate of my position in the SRFI discussion archives. See the following messages by Panu Kalliokoski: http://srfi.schemers.org/srfi-67/mail-archive/msg00021.html http://srfi.schemers.org/srfi-67/mail-archive/msg00023.html http://srfi.schemers.org/srfi-67/mail-archive/msg00025.html Of course, the SRFI still went the other way. I would be happy to add functions to convert between the two conventions. Ryan _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] weird "module: identifier is already imported" error
Christos, time to file a bug report (with code snippets). -- Matthias On Jun 21, 2012, at 4:41 PM, Ryan Culpepper wrote: > I can reproduce this error in DrRacket (both with and without debuggging > enabled) but not in racket. So maybe DrRacket is doing something odd, or > perhaps there's a bug in module->namespace or something like that. > > Ryan > > > On 06/21/2012 01:52 PM, Christos Dimoulas wrote: >> Hi, >> >> I ran into an error that I can't explain. Do you have any hints about >> what is going on or any suggestions on how to fix it? >> >> In the following code, macros provides alternative forms for require and >> provide, dubbed accept and provide/dispute. They are doing the same job >> as provide and require except that they create a fresh identifier to add >> a little bit of indirection. The first client defines foo and provides >> it with provide/dispute. The other clients just use accept and >> provide/dispute to pass along foo. >> >> When I ran the code I get ''module: identifier is already imported in: >> foo2''. >> >> Thanks. >> >> #lang racket >> >> (module macros racket >> >> (provide accept provide/dispute) >> >> (define-syntax (accept stx) >> (syntax-case stx () >> [(_ spec id) >> (with-syntax ([(new-id) (generate-temporaries #'(id))]) >> #`(begin >> (require (only-in spec [id new-id])) >> (define id new-id)))])) >> >> (define-syntax (provide/dispute stx) >> (syntax-case stx () >> [(_ id) >> (with-syntax ([(new-id) (generate-temporaries #'(id))]) >> #`(begin >> (define new-id id) >> (provide (rename-out [new-id id]]))) >> >> (module client1 racket >> >> (require (submod ".." macros)) >> >> (define (foo x) x) >> >> (provide/dispute foo)) >> >> (module client2 racket >> >> (require (submod ".." macros)) >> >> (accept (submod ".." client1) foo) >> >> (provide/dispute foo)) >> >> (module client3 racket >> >> (require (submod ".." macros)) >> >> (accept (submod ".." client2) foo) >> >> (provide/dispute foo)) >> >> >> _ >> Racket Developers list: >> http://lists.racket-lang.org/dev > _ > Racket Developers list: > http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] 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] weird "module: identifier is already imported" error
I can reproduce this error in DrRacket (both with and without debuggging enabled) but not in racket. So maybe DrRacket is doing something odd, or perhaps there's a bug in module->namespace or something like that. Ryan On 06/21/2012 01:52 PM, Christos Dimoulas wrote: Hi, I ran into an error that I can't explain. Do you have any hints about what is going on or any suggestions on how to fix it? In the following code, macros provides alternative forms for require and provide, dubbed accept and provide/dispute. They are doing the same job as provide and require except that they create a fresh identifier to add a little bit of indirection. The first client defines foo and provides it with provide/dispute. The other clients just use accept and provide/dispute to pass along foo. When I ran the code I get ''module: identifier is already imported in: foo2''. Thanks. #lang racket (module macros racket (provide accept provide/dispute) (define-syntax (accept stx) (syntax-case stx () [(_ spec id) (with-syntax ([(new-id) (generate-temporaries #'(id))]) #`(begin (require (only-in spec [id new-id])) (define id new-id)))])) (define-syntax (provide/dispute stx) (syntax-case stx () [(_ id) (with-syntax ([(new-id) (generate-temporaries #'(id))]) #`(begin (define new-id id) (provide (rename-out [new-id id]]))) (module client1 racket (require (submod ".." macros)) (define (foo x) x) (provide/dispute foo)) (module client2 racket (require (submod ".." macros)) (accept (submod ".." client1) foo) (provide/dispute foo)) (module client3 racket (require (submod ".." macros)) (accept (submod ".." client2) foo) (provide/dispute foo)) _ Racket Developers list: http://lists.racket-lang.org/dev _ 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
[racket-dev] weird "module: identifier is already imported" error
Hi, I ran into an error that I can't explain. Do you have any hints about what is going on or any suggestions on how to fix it? In the following code, macros provides alternative forms for require and provide, dubbed accept and provide/dispute. They are doing the same job as provide and require except that they create a fresh identifier to add a little bit of indirection. The first client defines foo and provides it with provide/dispute. The other clients just use accept and provide/dispute to pass along foo. When I ran the code I get ''module: identifier is already imported in: foo2''. Thanks. #lang racket (module macros racket (provide accept provide/dispute) (define-syntax (accept stx) (syntax-case stx () [(_ spec id) (with-syntax ([(new-id) (generate-temporaries #'(id))]) #`(begin (require (only-in spec [id new-id])) (define id new-id)))])) (define-syntax (provide/dispute stx) (syntax-case stx () [(_ id) (with-syntax ([(new-id) (generate-temporaries #'(id))]) #`(begin (define new-id id) (provide (rename-out [new-id id]]))) (module client1 racket (require (submod ".." macros)) (define (foo x) x) (provide/dispute foo)) (module client2 racket (require (submod ".." macros)) (accept (submod ".." client1) foo) (provide/dispute foo)) (module client3 racket (require (submod ".." macros)) (accept (submod ".." client2) foo) (provide/dispute foo)) _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #24750: master branch updated
Agreed. Deprecate now, remove next+ or next++ release -- Matthias On Jun 21, 2012, at 2:56 PM, Robby Findler wrote: > I think we should give people warnings; we cannot just remove stuff. > > Robby > > On Thu, Jun 21, 2012 at 12:58 PM, Asumu Takikawa wrote: >> On 2012-06-21 13:03:18 -0400, Eli Barzilay wrote: >>> Nice. How about adding a big "deprecated" to the class100 docs, and >>> make a note to remove it in a year? >> >> That trick is neat, but would it be a problem to just remove it now? >> >> Tony had the idea that we could just put it on PLaneT and tell people to >> change their `require`s if they really need it. Or we could put it up on >> github and tell people in the docs to `raco link` it to look like >> mzlib/class100. >> >> Cheers, >> Asumu >> _ >> Racket Developers list: >> http://lists.racket-lang.org/dev > > _ > Racket Developers list: > http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #24750: master branch updated
I think we should give people warnings; we cannot just remove stuff. Robby On Thu, Jun 21, 2012 at 12:58 PM, Asumu Takikawa wrote: > On 2012-06-21 13:03:18 -0400, Eli Barzilay wrote: >> Nice. How about adding a big "deprecated" to the class100 docs, and >> make a note to remove it in a year? > > That trick is neat, but would it be a problem to just remove it now? > > Tony had the idea that we could just put it on PLaneT and tell people to > change their `require`s if they really need it. Or we could put it up on > github and tell people in the docs to `raco link` it to look like > mzlib/class100. > > Cheers, > Asumu > _ > Racket Developers list: > http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #24750: master branch updated
On Thu, Jun 21, 2012 at 1:58 PM, Asumu Takikawa wrote: > On 2012-06-21 13:03:18 -0400, Eli Barzilay wrote: >> Nice. How about adding a big "deprecated" to the class100 docs, and >> make a note to remove it in a year? > > That trick is neat, but would it be a problem to just remove it now? > > Tony had the idea that we could just put it on PLaneT and tell people to > change their `require`s if they really need it. Or we could put it up on > github and tell people in the docs to `raco link` it to look like > mzlib/class100. The latter is a less-invasive change to the code, I would think. -- sam th sa...@ccs.neu.edu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #24750: master branch updated
On 2012-06-21 13:03:18 -0400, Eli Barzilay wrote: > Nice. How about adding a big "deprecated" to the class100 docs, and > make a note to remove it in a year? That trick is neat, but would it be a problem to just remove it now? Tony had the idea that we could just put it on PLaneT and tell people to change their `require`s if they really need it. Or we could put it up on github and tell people in the docs to `raco link` it to look like mzlib/class100. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Redex for abstract machines / analysis prototypes
FWIW, Jonathan Schuster's encoding of NetCore (the Princeton-Cornell theory for routing, last popl) encountered a similar problem. The original paper uses the ChemAM and he encoded it with Redex with "propagated parts of patterns". So in general, models based on the Chem AM would be easier to encode in Redex, so perhaps we should look in the literature how they are typeset. -- Matthias On Jun 19, 2012, at 7:08 PM, J. Ian Johnson wrote: > Machine semantics for real machines (like the JVM or Racket's VM) or > non-standard semantics for an abstract interpretation (like what I end up > getting into) can get up to monstrous numbers of components for each state > that usually don't matter. I and I'm sure many others would appreciate a > reduction relation language that is a little more like UIUC's K. > > Here is a concrete suggestion of what I imagine (some support for patterns on > hashes): > 1) Add a pattern (hash (literal pat) ...) to match hashes up to the specified > keys (hashes with more keys are still accepted). > 2) Add rewrite rules for changing the current state. > -- (next-state (r r) ...) > -- (get r r) > -- (set r r r) > -- (set* r (r r) ...) > Where > (get r_0 r_1) is ,(hash-ref (term r_0) (term r_1) > 'something-that-never-matches) > (set r_0 r_1 r_2) is ,(hash-set (term r_0) (term r_1) (term r_2)) > (set* r_0 (r_k r_v) ...) is the obvious extension of set, but is annoying to > write. > And assuming the LHS is named state, > (next-state (r_k r_v) ...) is (set* state (r_k r_v) ...) > > Not-the-best-example-since-it's-so-minimal: > > (define-language CEK > [e x (e e) lam] > [lam (lambda (x) e)] > [rho (hash)] > [kont mt (ar e rho kont) (fn e rho kont))]) > > (define R > (machine-step CEK > [--> (hash (C x) (E rho)) > (next-state (C lam) (E rho*)) > (where (lam rho*) (get rho x))] > > [--> (hash (C (e_0 e_1)) (E rho) (K kont)) > (next-state (C e_0) (K (ar e_1 rho kont)))] > > [--> (hash (C lam) (E rho) (K (ar e rho_0 kont))) > (next-state (C e) (E rho_0) (K (fn lam rho kont)))] > > [--> (hash (C v) (K (fn (lambda (x) e) rho kont))) > (next-state (C e) (E (set rho x (v rho))) (K kont))])) > > (define (inject e) (term (set* #hash() (C ,e) (E #hash()) (K mt > > Is this reasonably simple to add to Redex? It would be a very welcome > addition. > -Ian > _ > Racket Developers list: > http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] check-syntax hack: patch to show how many uses an identifier has
I'll try to do something along these lines. It shouldn't be hard to make it a tooltip. Robby On Thu, Jun 21, 2012 at 11:03 AM, John Clements wrote: > > On Jun 21, 2012, at 8:58 AM, Matthias Felleisen wrote: > >> >> +a lot; I'd like that > > Robby, what's the nastiness threshold for getting something like this into > the distribution? > > - is it okay to have a menu item with no action? > - is it okay to just say how many arrows--lines, really--radiate from this > point, or would I need to go to the binding identifier and figure out how > many uses the thing has? > > John > >> >> >> On Jun 20, 2012, at 10:48 PM, John Clements wrote: >> >>> When I'm using online check syntax, I often look at the lines leaving an >>> identifier and wonder: is that just one line, or are there two or three? >>> When lines overlap, there's no easy way to tell. This can be important in >>> refactoring decisions, or in debugging (how many uses of this thing are >>> there to check?). >>> >>> Let me show you what I mean: >>> >>> >>> >>> How many uses of 'x' are there? >>> >>> I decided to spend a few minutes digging through the source, and came up >>> with this *EXTREMELY ROUGH* hack which helps me. : >>> >>> oiseau:...plt/collects/drracket/private/syncheck clements> git diff gui.rkt >>> diff --git a/collects/drracket/private/syncheck/gui.rkt >>> b/collects/drracket/private/syncheck/gui.rkt >>> index 5f691bd..e69b9c7 100644 >>> --- a/collects/drracket/private/syncheck/gui.rkt >>> +++ b/collects/drracket/private/syncheck/gui.rkt >>> @@ -1069,6 +1069,11 @@ If the namespace does not, they are colored the >>> unbound color. >>> [var-arrows (filter var-arrow? >>> arrows)] >>> [add-menus (append (map cdr (filter >>> pair? vec-ents)) >>> (filter procedure? >>> vec-ents))]) >>> + (make-object menu-item% >>> + (string-append ">> " (number->string >>> (length arrows)) >>> + " arrows from this >>> identifier") >>> + menu >>> + (λ (item evt) (void))) >>> (unless (null? arrows) >>> (make-object menu-item% >>> (string-constant cs-tack/untack-arrow) >>> >>> >>> Let me just emphasize how rough this hack is: when I use it on a use of an >>> identifier rather than a definition, it just shows the number 1, because >>> that's the number of arrows--that is, the one that goes back to the >>> definition. >>> >>> Keeping its limitations in mind, though, it's really nice to be able to see: >>> >>> >>> >>> >>> Would others find this useful? >>> >>> John >>> >>> >>> _ >>> Racket Developers list: >>> http://lists.racket-lang.org/dev >> > _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #24750: master branch updated
About a month ago, as...@racket-lang.org wrote: > > cfe1711 Asumu Takikawa 2012-05-26 11:10 > : > | Convert all uses of mzlib/class100 to racket/class > : Nice. How about adding a big "deprecated" to the class100 docs, and make a note to remove it in a year? (Eg, add this to the code: (begin-for-syntax (when (> (current-seconds) (date->seconds (date 0 0 0 1 6 2013 0 0 #f 0))) (error "time to remove this code"))) ) -- ((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] [plt] Push #24847: master branch updated
A week ago, as...@racket-lang.org wrote: > > 5d232f3 Asumu Takikawa 2012-06-13 16:32 > : > | racket/control: add aliases and update %/fcontrol > | > | Added alises for call-with-continuation-prompt, > | abort-current-continuation, and call-with-composable-continuation. > | Also allow % and fcontrol to take an optional prompt tag argument. > : > M collects/mzlib/control.rkt | 25 +--- > M collects/scribblings/reference/control-lib.scrbl | 38 > +-- > M collects/tests/racket/control.rktl | 10 + It seems odd to me that a short alias for a builtin is provided from a different library -- unlike `call/cc'. So I think that it's better to have this alias in `racket/base'. (I mentioned this to Asumu, and he said he doesn't mind either eay.) -- ((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] check-syntax hack: patch to show how many uses an identifier has
On Jun 21, 2012, at 8:58 AM, Matthias Felleisen wrote: > > +a lot; I'd like that Robby, what's the nastiness threshold for getting something like this into the distribution? - is it okay to have a menu item with no action? - is it okay to just say how many arrows--lines, really--radiate from this point, or would I need to go to the binding identifier and figure out how many uses the thing has? John > > > On Jun 20, 2012, at 10:48 PM, John Clements wrote: > >> When I'm using online check syntax, I often look at the lines leaving an >> identifier and wonder: is that just one line, or are there two or three? >> When lines overlap, there's no easy way to tell. This can be important in >> refactoring decisions, or in debugging (how many uses of this thing are >> there to check?). >> >> Let me show you what I mean: >> >> >> >> How many uses of 'x' are there? >> >> I decided to spend a few minutes digging through the source, and came up >> with this *EXTREMELY ROUGH* hack which helps me. : >> >> oiseau:...plt/collects/drracket/private/syncheck clements> git diff gui.rkt >> diff --git a/collects/drracket/private/syncheck/gui.rkt >> b/collects/drracket/private/syncheck/gui.rkt >> index 5f691bd..e69b9c7 100644 >> --- a/collects/drracket/private/syncheck/gui.rkt >> +++ b/collects/drracket/private/syncheck/gui.rkt >> @@ -1069,6 +1069,11 @@ If the namespace does not, they are colored the >> unbound color. >> [var-arrows (filter var-arrow? arrows)] >> [add-menus (append (map cdr (filter >> pair? vec-ents)) >> (filter procedure? >> vec-ents))]) >> + (make-object menu-item% >> + (string-append ">> " (number->string >> (length arrows)) >> + " arrows from this >> identifier") >> + menu >> + (λ (item evt) (void))) >> (unless (null? arrows) >>(make-object menu-item% >> (string-constant cs-tack/untack-arrow) >> >> >> Let me just emphasize how rough this hack is: when I use it on a use of an >> identifier rather than a definition, it just shows the number 1, because >> that's the number of arrows--that is, the one that goes back to the >> definition. >> >> Keeping its limitations in mind, though, it's really nice to be able to see: >> >> >> >> >> Would others find this useful? >> >> John >> >> >> _ >> Racket Developers list: >> http://lists.racket-lang.org/dev > smime.p7s Description: S/MIME cryptographic signature _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] sequence syntax for (mlist #t #f …) ?
On Jun 21, 2012, at 1:34 AM, Robby Findler wrote: > I usually in-naturals and zero? to do this. Ah! That's nice. I can use that. > > I see that one example (that I didn't write is in base-render.rkt > >(define/public (render-nested-flow i part ri starting-item?) > (for/list ([b (in-list (nested-flow-blocks i))] > [pos (in-naturals)]) >(render-block b part ri (and starting-item? (zero? pos) > > Robby > > On Thu, Jun 21, 2012 at 3:24 AM, Eli Barzilay wrote: >> An hour and a half ago, John Clements wrote: >>> Reality check before I do something dumb and re-invent the wheel: >>> >>> I often want to write a for loop where the first element is treated >>> specially. In such cases, it would be nice to have a sequence that >>> had a #t and then an infinite number of #f's, so I could write >>> >>> (for ([s my-sequence] [first? ]) …) >> >> What are you using it for? (Out of curiosity, I wonder if there's any >> need for this that doesn't fall under what `add-between' does.) Nothing unusual; I'm writing newlines in between rendered expressions in the stepper. I don't think an add-between would make for more readable code in this case, but it's a related use. John smime.p7s Description: S/MIME cryptographic signature _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] sequence syntax for (mlist #t #f …) ?
On Jun 21, 2012, at 1:24 AM, Eli Barzilay wrote: > An hour and a half ago, John Clements wrote: > > >> Yes, of course I can do it the ugly way: >> [...] >> (define p1 (mcons #f 'bogus)) >> (set-mcdr! p1 p1) >> (define true-then-falses (mcons #t p1)) > > What about > > (shared ([fs (cons #f fs)]) (cons #t fs)) > (cons #t (shared ([fs (cons #f fs)]) fs)) Right! Shared is what I was thinking of. Many thanks. John smime.p7s Description: S/MIME cryptographic signature _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] check-syntax hack: patch to show how many uses an identifier has
+a lot; I'd like that On Jun 20, 2012, at 10:48 PM, John Clements wrote: > When I'm using online check syntax, I often look at the lines leaving an > identifier and wonder: is that just one line, or are there two or three? When > lines overlap, there's no easy way to tell. This can be important in > refactoring decisions, or in debugging (how many uses of this thing are there > to check?). > > Let me show you what I mean: > > > > How many uses of 'x' are there? > > I decided to spend a few minutes digging through the source, and came up with > this *EXTREMELY ROUGH* hack which helps me. : > > oiseau:...plt/collects/drracket/private/syncheck clements> git diff gui.rkt > diff --git a/collects/drracket/private/syncheck/gui.rkt > b/collects/drracket/private/syncheck/gui.rkt > index 5f691bd..e69b9c7 100644 > --- a/collects/drracket/private/syncheck/gui.rkt > +++ b/collects/drracket/private/syncheck/gui.rkt > @@ -1069,6 +1069,11 @@ If the namespace does not, they are colored the > unbound color. >[var-arrows (filter var-arrow? arrows)] >[add-menus (append (map cdr (filter > pair? vec-ents)) > (filter procedure? > vec-ents))]) > + (make-object menu-item% > + (string-append ">> " (number->string > (length arrows)) > + " arrows from this > identifier") > + menu > + (λ (item evt) (void))) > (unless (null? arrows) > (make-object menu-item% > (string-constant cs-tack/untack-arrow) > > > Let me just emphasize how rough this hack is: when I use it on a use of an > identifier rather than a definition, it just shows the number 1, because > that's the number of arrows--that is, the one that goes back to the > definition. > > Keeping its limitations in mind, though, it's really nice to be able to see: > > > > > Would others find this useful? > > John > > > _ > Racket Developers list: > http://lists.racket-lang.org/dev _ 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 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] Comparison functions and the `data' collection
More than a week ago, Ryan Culpepper wrote: > On 06/11/2012 02:36 PM, Eli Barzilay wrote: > > Yesterday, Danny Yoo wrote: > >> > >> It's a little unfortunate that there's a slight impedance mismatch > >> between what datum-order provides and what sort expects; the > >> my-less-than function in the example adapts the output of > >> datum-order so it can be used with sort. > > > > Thanks for pointing it out (I didn't know about it). When I > > looked into this, I saw that in addition to `data/order' there is > > also an issue with `data/heap'. It certainly does look like a > > problem worth addressing. > > > > The thing is that are two common ways to specify comparison functions: > > (a) three-valued comparison functions returning -1/0/+1, (b) a boolan > > strictly-smaller-than predicate. The first is common in several > > mainsteam languages and the second is traditionally common in > > lisps (which leads to its use in the sort function). > > > > The issues are described very thoroughly in srfi-67 -- specifically, > > see the first two subsections in section 6. I highly recommend > > reading that for this discussion. They decide to go with option (a), > > with an explanation for the choice of a three-valued function and for > > their choice of -1/0/+1 values. > > I don't remember if I discovered srfi-67 before or after I added > data/order. In any case, I disagree with its rationale for -1/0/+1: > I dislike the idea of performing arithmetic on orderings. (See below.) > OTOH, data/order is used primarily by the ordered dictionary types > (data/splay-tree, data/skip-list), so it's probably missing operations > and conveniences for tasks like sorting a list. (I take it that they will be added, then...) > > 2. The `data/order' interface has several problems that I think is > > best to resolve. > > > > - Regadless of the above, it seems like a good idea to extend > > the interface with a simple boolean predicate. Maybe > > something like `datum > address the issue that Danny raised above. > > From an order you can get the less-than and equality predicates: > >(order-(order-=? datum-order) Yes, of course this is easy. I can also do that `case' in a tiny λ. But it should be part of the library. On Saturday, Matthias Felleisen wrote: > > This response leaves us with the impression that we whimsically > challenged established conventions in the general and the > Lisp-specific PL family. In addition it leaves us with > inconsistencies across our libraries, which I am coming to consider > more and more as a serious problem. Yes, that was exactly why I raised it. Since it's core-ish functionality, having it behave well wrt expectations is IMO extremely important. Right now we have a sad state of two different incompatibilities there, and I don't see any good explanation except for the "I disagree/dislike" (in contrast to the srfi). Because of such expectations and because of existing code, I'd follow that without thinking about what might the right choice be. (Personally, I now think that the more lenient approach of any numbers, negative, 0, or positive is even better -- and I can also explain and justify why I think that, but that's irrelevant.) > Now -- I would be the last one to defend "established tradition" > over "getting things right" but at a minimum, the reasoning of why > we challenge tradition should be noted. +7 -- ((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] `regexp-replaces'
add1 I also use such a function from time to time, and I'd be happy to have it in the string or regexp libs. Laurent On Thu, Jun 21, 2012 at 1:56 PM, Eli Barzilay wrote: > While scanning code for a minor incompatible in a commit, I ran into > this function which is the ffi collection of all places. (See the > docs for what it does.) Given that this comes up often, maybe it's > time to add this to `racket/string'? > > (Or maybe `racket/private/string' next to the other regexp functions?) > > -- > ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: >http://barzilay.org/ Maze is Life! > _ > Racket Developers list: > http://lists.racket-lang.org/dev > _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Error message proposal
Four hours ago, Robby Findler wrote: > > I think Matthew is concerned with the code that constructs the error > messages and being able to build strings from parts coming from > different places.. I understood this as the continuation of the current style of error messages, not as a technical problem. I don't see any problem with capitals & dots that wouldn't happen with lowercase and semicolons, do you have some example? -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] `regexp-replaces'
While scanning code for a minor incompatible in a commit, I ran into this function which is the ffi collection of all places. (See the docs for what it does.) Given that this comes up often, maybe it's time to add this to `racket/string'? (Or maybe `racket/private/string' next to the other regexp functions?) -- ((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] Error message proposal
On Thu, Jun 21, 2012 at 4:21 AM, Eli Barzilay wrote: > Three hours ago, Matthew Flatt wrote: >> I think you're asking for two changes to the error-message syntax: >> >> * Move srcloc back to the front of error messages. >> >> * Support multi-line messages: the first line is supposed to be >> useful on its own, but extra lines act as a kind of detail field >> that is nicely placed and particularly prominent. > > Yes, but I thought that the second is already there by the fact that > multiple lines are now the norm. IOW, I assumed that it is now fine > to do something like > > (error 'foo "blah blah\n blah: blah\n") > > >> As long as the extra lines are indented by one space to make them >> easily parseable, those changes sound fine to me. > > Yes (except I use two spaces in texts too...), and since we're parsing > texts, there's a problem with the line having a colon in it. > > There's a bunch of options for that, like an empty line, or forcing > all fields to have their values on the next line and doubly-indented. > > (I'd much rather prefer to have the structure in the data, but I > remember the problems with that. Maybe have a wrapper for primitive > exceptions that does the parsing? OTOH, the nice thing about strings > is that it's easily compatibil with existing multi-line error > messages.) > > So given that it's one paragraph -- I think that the easiest solution > is one line, and have the error display handler do the text wrapping. > > >> Your example message contains a sentence with capitalization and an >> ending period. As nice as it looks in the example, that kind of text >> composes badly, so I'd prefer to stick with lowercase and (as needed) >> semi-colons. > > I was thinking in the direction of catering for the longish > explanations that Ryan was suggesting, and the suggestions in the > linking error messages, etc. Semicolons would probably also > discourage longer messages. Finally, if that text is shown in a popup > or shown separately in xrepl, it would look odd. > > Anyway, I'm thinking that the main thing should be a separation > between the information (= the text) and the rendering. So how about > this: leave capitals+dots and do the obvious regexp-replacing > (together with the wrapping, given the above) in the default display > handler? I think Matthew is concerned with the code that constructs the error messages and being able to build strings from parts coming from different places.. >> I'm also happy to allow the initial name in an error messages to be >> sometimes an entity that is complained about, instead of always the >> complaining entity. (That's not in the message below, except by >> indirection.) > > I'm not following that last comment. > > >> Meanwhile, I think you're asking for some changes to existing error >> messages, such as adapting some existing messages that can be >> usefully broken into first and second lines. I have certain specific >> hanges in mind; probably we'll have to take them one-by-one at some >> point. > > OK. (I'll be very happy to do whatever.) > > >> Finally, I think you're asking for a change to DrRacket: >> >> * Don't show any fields beyond the first line until the user clicks >> somewhere. >> >> That doesn't sound practical to me. When I call a function with the >> wrong number of arguments, for example, I don't want to have to click >> to find out how many arguments are expected. > > That "beyond the first line" was a little extreme -- I'm thinking > about having the long-second-line thing showing all of the really > necessary details, and then the fields showing complete details. > > >> I think it will work better to have a field convention or syntax to >> indicate whether a field should be hidden by default. How about >> using "..." at the end of a field name to indicate that it could be >> hidden by default? [...] > > To translate the errors you've written (as would be shown by the > default display handler, when showing all fields too): > > > (+ 1 'a) > +: contract violation > `+' expected a number in its 2nd argument; given 'a > expected: number? > given: 'a > argument position: 2 > other arguments: > 1 > context: > [...] > > (add1 1 2 3) > add1: arity mismatch > `add1' does not expect 3 arguments > expected number of arguments: 1 > given number of arguments: 3 > arguments: > 1 > 2 > 3 > technical note: this is a contract violation for the application > form > context: > [...] > > But if you want some markup, then another thing to consider is some > way to allow customizing these things -- for example, maybe some error > has two fields that are the same only one is more detailed (eg, a > short path in one, and absolute one in the other). Or maybe you want > to see some particular bit that most people don't. > > (These are not issues that are specific to the overall suggestion > though.) > > -- > ((lambda (x) (x x)) (lambda (x) (x x
Re: [racket-dev] Error message proposal
Three hours ago, Matthew Flatt wrote: > I think you're asking for two changes to the error-message syntax: > > * Move srcloc back to the front of error messages. > > * Support multi-line messages: the first line is supposed to be >useful on its own, but extra lines act as a kind of detail field >that is nicely placed and particularly prominent. Yes, but I thought that the second is already there by the fact that multiple lines are now the norm. IOW, I assumed that it is now fine to do something like (error 'foo "blah blah\n blah: blah\n") > As long as the extra lines are indented by one space to make them > easily parseable, those changes sound fine to me. Yes (except I use two spaces in texts too...), and since we're parsing texts, there's a problem with the line having a colon in it. There's a bunch of options for that, like an empty line, or forcing all fields to have their values on the next line and doubly-indented. (I'd much rather prefer to have the structure in the data, but I remember the problems with that. Maybe have a wrapper for primitive exceptions that does the parsing? OTOH, the nice thing about strings is that it's easily compatibil with existing multi-line error messages.) So given that it's one paragraph -- I think that the easiest solution is one line, and have the error display handler do the text wrapping. > Your example message contains a sentence with capitalization and an > ending period. As nice as it looks in the example, that kind of text > composes badly, so I'd prefer to stick with lowercase and (as needed) > semi-colons. I was thinking in the direction of catering for the longish explanations that Ryan was suggesting, and the suggestions in the linking error messages, etc. Semicolons would probably also discourage longer messages. Finally, if that text is shown in a popup or shown separately in xrepl, it would look odd. Anyway, I'm thinking that the main thing should be a separation between the information (= the text) and the rendering. So how about this: leave capitals+dots and do the obvious regexp-replacing (together with the wrapping, given the above) in the default display handler? > I'm also happy to allow the initial name in an error messages to be > sometimes an entity that is complained about, instead of always the > complaining entity. (That's not in the message below, except by > indirection.) I'm not following that last comment. > Meanwhile, I think you're asking for some changes to existing error > messages, such as adapting some existing messages that can be > usefully broken into first and second lines. I have certain specific > hanges in mind; probably we'll have to take them one-by-one at some > point. OK. (I'll be very happy to do whatever.) > Finally, I think you're asking for a change to DrRacket: > > * Don't show any fields beyond the first line until the user clicks >somewhere. > > That doesn't sound practical to me. When I call a function with the > wrong number of arguments, for example, I don't want to have to click > to find out how many arguments are expected. That "beyond the first line" was a little extreme -- I'm thinking about having the long-second-line thing showing all of the really necessary details, and then the fields showing complete details. > I think it will work better to have a field convention or syntax to > indicate whether a field should be hidden by default. How about > using "..." at the end of a field name to indicate that it could be > hidden by default? [...] To translate the errors you've written (as would be shown by the default display handler, when showing all fields too): > (+ 1 'a) +: contract violation `+' expected a number in its 2nd argument; given 'a expected: number? given: 'a argument position: 2 other arguments: 1 context: [...] > (add1 1 2 3) add1: arity mismatch `add1' does not expect 3 arguments expected number of arguments: 1 given number of arguments: 3 arguments: 1 2 3 technical note: this is a contract violation for the application form context: [...] But if you want some markup, then another thing to consider is some way to allow customizing these things -- for example, maybe some error has two fields that are the same only one is more detailed (eg, a short path in one, and absolute one in the other). Or maybe you want to see some particular bit that most people don't. (These are not issues that are specific to the overall suggestion though.) -- ((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] sequence syntax for (mlist #t #f …) ?
A few minutes ago, Robby Findler wrote: > I usually in-naturals and zero? to do this. (Ah, I forgot to include this, with the observation that worrying about bignums is not relevant...) > I see that one example (that I didn't write is in base-render.rkt > > (define/public (render-nested-flow i part ri starting-item?) > (for/list ([b (in-list (nested-flow-blocks i))] > [pos (in-naturals)]) > (render-block b part ri (and starting-item? (zero? pos) (Looks like it's only passed around in that file and only used to render tables in html/latex. Not a typical smallish example...) -- ((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] sequence syntax for (mlist #t #f …) ?
I usually in-naturals and zero? to do this. I see that one example (that I didn't write is in base-render.rkt (define/public (render-nested-flow i part ri starting-item?) (for/list ([b (in-list (nested-flow-blocks i))] [pos (in-naturals)]) (render-block b part ri (and starting-item? (zero? pos) Robby On Thu, Jun 21, 2012 at 3:24 AM, Eli Barzilay wrote: > An hour and a half ago, John Clements wrote: >> Reality check before I do something dumb and re-invent the wheel: >> >> I often want to write a for loop where the first element is treated >> specially. In such cases, it would be nice to have a sequence that >> had a #t and then an infinite number of #f's, so I could write >> >> (for ([s my-sequence] [first? ]) …) > > What are you using it for? (Out of curiosity, I wonder if there's any > need for this that doesn't fall under what `add-between' does.) > > >> I'd be sort of okay with writing >> >> (mcons #t #0=(mcons #f #0#)) > > I don't think that I've seen any implementation that would be fine > with that -- you'd want '(#t . #0=(#f . #0#)), which is not allowed > either, but this still works: > > (read (open-input-string "(#t . #0=(#f . #0#))")) > > >> Yes, of course I can do it the ugly way: >> [...] >> (define p1 (mcons #f 'bogus)) >> (set-mcdr! p1 p1) >> (define true-then-falses (mcons #t p1)) > > What about > > (shared ([fs (cons #f fs)]) (cons #t fs)) > (cons #t (shared ([fs (cons #f fs)]) fs)) > > (or in lazy: > > (letrec ([fs (cons #t (cons #f (cdr fs)))]) fs) > > ) > > And if you want to use a for loop with that, you can do this: > > (in-sequences (in-value #t) (in-cycle (in-value #f))) > > -- > ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: > http://barzilay.org/ Maze is Life! > > _ > Racket Developers list: > http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] sequence syntax for (mlist #t #f …) ?
An hour and a half ago, John Clements wrote: > Reality check before I do something dumb and re-invent the wheel: > > I often want to write a for loop where the first element is treated > specially. In such cases, it would be nice to have a sequence that > had a #t and then an infinite number of #f's, so I could write > > (for ([s my-sequence] [first? ]) …) What are you using it for? (Out of curiosity, I wonder if there's any need for this that doesn't fall under what `add-between' does.) > I'd be sort of okay with writing > > (mcons #t #0=(mcons #f #0#)) I don't think that I've seen any implementation that would be fine with that -- you'd want '(#t . #0=(#f . #0#)), which is not allowed either, but this still works: (read (open-input-string "(#t . #0=(#f . #0#))")) > Yes, of course I can do it the ugly way: > [...] > (define p1 (mcons #f 'bogus)) > (set-mcdr! p1 p1) > (define true-then-falses (mcons #t p1)) What about (shared ([fs (cons #f fs)]) (cons #t fs)) (cons #t (shared ([fs (cons #f fs)]) fs)) (or in lazy: (letrec ([fs (cons #t (cons #f (cdr fs)))]) fs) ) And if you want to use a for loop with that, you can do this: (in-sequences (in-value #t) (in-cycle (in-value #f))) -- ((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