Re: [racket-dev] syntax/syntax proposal
Yesterday, Ryan Culpepper wrote: The reorganization would discourage people from trying to add contracts to modules in the racket/pre-contracts subcollection. It's apparent from the name, as opposed to being discoverable by running the compiler. Oh you mean actually *move* the files there? That seems like a bad idea since some of these are in their own collection because of other reasons. For example, there's dependencies on pprint and on unstable. It would also encourage people to add contracts to every other library. [...] This is a very minor kind of encouragement -- it applies only to people who edit core code. For most people, the encouragement is already there since from their POV contracts can be added into any code they write. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Comparison functions and the `data' collection
Yesterday, David Van Horn wrote:
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.
That's some of the reason that it's my preference. But when I
considered the different choices, I went further: it's not *just* the
use of `-' which makes it a natural choice -- it's the fact that very
often when you're dealing with comparators there's a meaning for the
distance between two inputs. For example, when you're dealing with
just positive/0/negative results, you can very easily create
combinations of comparison functions from existing ones by summing
them, or even by throwing multipliers for int input comparators so you
get preferences. (Concrete case: if the doc lookup functionality uses
sorting, then it's much easier to combine different inputs with
different weights when you have just numbers, in contrast to juggling
symbolic results.)
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}.
I don't think that they're completely useless -- you still get some of
the benefits of dealing with numbers, like negating the results.
But in any case, my point was that we currently have a choice that is
used in practically no other place, which makes it a bad one.
--
((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
Yesterday, Matthew Flatt wrote: 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. OK. I hope that the static aspect is going to be strong enough that it becomes practical to build tools that use it. Ideally, the information is going to be at such a reliable level that the prose could be constructed automatically from the fields. In other words, I think that for the fields, accuracy should be stressed over readability. (There is one point where I see this as being a problem: when you display values, accuracy means that ~e should be the same as ~s, whereas readability makes it ~.s. But this could be delayed for a possible future extension where the actual values are kept instead of their rendering.) 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. How about stressing it as a possibly temporary thing that can change in the future for some more structural approach? (BTW, another point about using more structure is related to something that Neil pointed: in some cases it might be expensive to compute the information that is shown in an error, but it might be used in code that catches the error and discards that work. This could be addressed by using thunks (or promises) for field values.) 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. +1. -- ((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'
Yesterday, Laurent wrote: 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. I'll assume that without other replies, there are no objections to adding it? Also, at least as a start, I'm thinking of a function that looks just like the one from the ffi: (regexp-replaces str (list (list regexp replacement) ...)) Anything else that this should do? -- ((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'
On Fri, Jun 22, 2012 at 5:36 PM, Eli Barzilay e...@barzilay.org wrote: Yesterday, Laurent wrote: 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. I'll assume that without other replies, there are no objections to adding it? Also, at least as a start, I'm thinking of a function that looks just like the one from the ffi: (regexp-replaces str (list (list regexp replacement) ...)) Anything else that this should do? Maybe we could consider dictionaries for the replacement lists? Laurent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] `regexp-replaces'
Just now, Laurent wrote: Maybe we could consider dictionaries for the replacement lists? No, because the keys are regexp patterns, so there's no point in using dictionaries. -- ((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] `racket/regexp'
Adding a `regexp-replaces' leads to the question of where to add it: `racket/string' makes sense more than `racket/private/string' since it's really not something that should be considered core. But to make it correspond to `regexp-replace*' it should deal with both strings and bytes, so `racket/string' is not a good place for it. Maybe there should be a new `racket/regexp'? In addition to the new function, some functions from `racket/private/string' could move there too. -- ((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
An hour ago, Eli Barzilay wrote: 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. First encounter with a new(er) error message: | link: module mismatch; | possibly, bytecode file needs re-compile because dependencies changed |importing module: /home/eli/src/plt/collects/mzlib/runtime-path.rkt |exporting module: /home/eli/src/plt/collects/racket/private/string.rkt |exporting phase level: 0 |internal explanation: variable not provided (directly or indirectly and at the expected position) | in: regexp-split | context...: |/home/eli/src/plt/collects/mzlib/runtime-path.rkt: [running body] |standard-module-name-resolver |/home/eli/src/plt/collects/racket/unit.rkt: [traversing imports] |/home/eli/src/plt/collects/racket/main.rkt: [traversing imports] |/home/eli/src/plt/collects/racket/init.rkt: [traversing imports] | /home/eli/.racketrc:3:0: #%top-interaction: unbound identifier; | also, no #%app syntax transformer is bound | at: #%top-interaction | in: (#%top-interaction require xrepl) * the first batch of fields are indented by three spaces instead of two spaces in the following two fields. * the second explanation line is indented by two spaces in the first error and by one space in the next. * Sidenote: seeing two errors like that makes me prefer a two-space indentation for these things to make it more clear. * Another sidenote: having the first line end with a ; makes the semicolons on the next line be a better choice, should this be the common way to do these error messages? Perhaps the existence of a ; on the first line should say that the next line is the further explanation thing which would make it optional? (Specifically making many existing uses of `error' compatible.) -- ((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
