date:20120621

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? true-then-always-falses]) …)

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

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 e...@barzilay.org 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? true-then-always-falses]) …)

 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 …) ?

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] 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] Error message proposal

On Thu, Jun 21, 2012 at 4:21 AM, Eli Barzilay e...@barzilay.org 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))) Eli Barzilay:
http://barzilay.org/ Maze is Life!
_
Racket Developers

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

Re: [racket-dev] `regexp-replaces'

2012-06-21 Thread Laurent

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 e...@barzilay.org 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] 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] 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?' and possibly others.  This would
address the issue that Danny raised above.
 
  From an order you can get the less-than and equality predicates:
 
(order-? datum-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 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] sequence syntax for (mlist #t #f …) ?

2012-06-21 Thread John Clements


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

2012-06-21 Thread John Clements


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:
 
 Screen Shot 2012-06-20 at 7.44.52 PM.png
 
 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:
 
 Screen Shot 2012-06-20 at 7.46.24 PM.png
 
 
 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] [plt] Push #24847: master branch updated

A week ago, as...@racket-lang.org wrote:
 
 5d232f3 Asumu Takikawa as...@racket-lang.org 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

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
cleme...@brinckerhoff.org 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:

 Screen Shot 2012-06-20 at 7.44.52 PM.png

 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:

 Screen Shot 2012-06-20 at 7.46.24 PM.png


 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] 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] [plt] Push #24750: master branch updated

2012-06-21 Thread Asumu Takikawa

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] [plt] Push #24750: master branch updated

2012-06-21 Thread Sam Tobin-Hochstadt

On Thu, Jun 21, 2012 at 1:58 PM, Asumu Takikawa as...@ccs.neu.edu 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

I think we should give people warnings; we cannot just remove stuff.

Robby

On Thu, Jun 21, 2012 at 12:58 PM, Asumu Takikawa as...@ccs.neu.edu 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


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 as...@ccs.neu.edu 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

[racket-dev] weird module: identifier is already imported error

2012-06-21 Thread Christos Dimoulas


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] syntax/syntax proposal

2012-06-21 Thread Ryan Culpepper


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] weird module: identifier is already imported error

2012-06-21 Thread Ryan Culpepper

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