[racket-dev] nested requires for (module+ test ..)
I am programming in a situation where I'd really like to see nested (module+ test ..) required and run, assuming the surrounding modules are run. Would this be reasonable to expect? -- Matthias _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Proposal for a "no-argument"
May be the discussion goes beyond my understanding, in which case sorry for my noise. Where I need a value distinct from all other values (such as a no-value), I prepare an empty struct type and export one single instance of this struct together with its predicate (and nothing else) Jos _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Proposal for a "no-argument"
At Mon, 2 Jul 2012 12:14:02 -0400, Asumu Takikawa wrote: > The gensym thing is used in parts of the GUI code for initialization > arguments, e.g.: > > (class* mred% (area<%>) >(init mk-wx get-wx-pan get-outer-wx-pan mismatches prnt > [min-width no-val] > [min-height no-val] > [stretchable-width no-val] > [stretchable-height no-val]) >...) > > Where `no-val` has been defined with a gensym. So it'd be nice to have > the distinguished `no-argument` for these cases too. In those cases, `no-val' is just an internal implementation technique, and not intended as a part of the API. In the case of `min-height' and `min-width', I think it would be better to allow `#f' as an argument, since the documented default value is not really accessible. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Proposal for a "no-argument"
I'm not enthusiastic about this proposal. As you say at the start, it seems like a rare case. My main objection is that it's too rare to merit a change to the main `lambda' form and other parts of our infrastructure, such as documentation tools. As a weaker objection, I don't agree with the suggestion that naive users can somehow ignore the `no-argument' value. I think it would show up prominently in documentation, contracts, and types. Weaker still, in terms of how well I can defend it: I'm suspicious of "no-value" values in general. Granted, we already have `#f', #, and #, but I'm not really happy about that (and I keep thinking about ways to get rid of #). At Sun, 1 Jul 2012 09:27:00 -0400, Eli Barzilay wrote: > There rare cases where it is useful to have a value that means that no > argument was passed to a function. In many of these cases there is a > plain value that is used as that mark, with the most idiomatic one > being #f, but sometimes others are used. IMO, while such uses of #f > are idiomatic, they're a hack where an argument's domain is extended > only to mark "no argument". > > A more robust way to do that, which has become idiomatic in Racket is > to use (gensym). (And as a sidenote, in other implementations there > are various similar eq-based hacks.) IMO, this is an attempt to > improve on the #f case by guaranteeing a unique value, but at its core > it's still a similar hack. > > Recently, I have extended the `add-between' function in a way that ran > against this problem at the interface level, where two keyword > arguments default to such a gensymed value to detect when no argument > is passed. Natually, this "leaked" into the documentation in the form > of using `' to avoid specifying the default value and instead > talking about what happens when no argument is given for the keywords > in question. > > After a short discussion that I had with Matthew, the new version uses > a new keyword that holds the unique no-value value, to simplify > things: > > (define (foo x #:nothing [nothing (gensym)] [y nothing]) > (printf "y is ~s\n" (if (eq? y nothing) 'omitted y))) > > The idea is that this does not depend on some specific unique value, > since one can be given. For "end-users" of the function, there is no > need to know about this. It's useful only for wrapper functions which > want to mirror the same behavior, and call `foo' in a way that makes > their own input passed to it, including not passing it when its own > input is missing. In this case, you'd do something like this: > > (define (bar #:nothing [nothing (gensym)] [x nothing]) > (foo 10 x #:nothing nothing)) > > This works, but I dislike this solution for several reasons: > > 1. Instead of finding a solution for the `gensym' problem, this >approach embraces it as the proper way to do such things. > > 2. But more than that, it also exposes it in the interface of such >functions, which means that "simple end users" need to read about >it too. There is no easy way to somehow say "you souldn't worry >about this unless you're writing a function that ...", and if you >look at the current docs for `add-between' you'd probably wonder >when that #:nothing is useful. > > 3. There is also a half-story in this documentation -- even though the >docs look like the above function definition, you obviously would >want to define a single global gensymmed value and use it, to avoid >redundant allocation. By the way the docs read, the above does >look like the way to do these things, and I can see how a quick >reading would make people believe that it's fine to write: > > (define (foo) >(define (bar [x (gensym)]) > ...) >... call bar many times ...) > > I considered a bunch of alternatives to this, and the one closest to > looking reasonable is to use the # value: it makes some > sense because it is a value that is already used in some "no value" > cases. However, it is probably a bad idea to use it for something > different. In fact, that's how many languages end up with false, > null, undefined, etc etc. > > (As a side note, a different approach would be to use a per-argument > boolean flag that specifies if the corresponding argument. Since this > started with a documentation point of view, I'm assuming that it won't > be a good solution since it doesn't solve that problem -- a function > that uses it similarly to `add-between' would still need to avoid > specifying the default.) > > Instead, I suggest using a new "special" value, one that is used only > for this purpose. The big difference from all of these special values > is that I'm proposing a value that is used only for this. To > "discourage" using it for other reasons, there would be no binding for > it. Instead, there would be a fake one, say `no-argument', which is > used only as a syntax in a default expression and only there the real > no-argument gets
Re: [racket-dev] Proposal for a "no-argument"
On 2012-07-01 09:27:00 -0400, Eli Barzilay wrote: > A more robust way to do that, which has become idiomatic in Racket is > to use (gensym). (And as a sidenote, in other implementations there > are various similar eq-based hacks.) IMO, this is an attempt to > improve on the #f case by guaranteeing a unique value, but at its core > it's still a similar hack. The gensym thing is used in parts of the GUI code for initialization arguments, e.g.: (class* mred% (area<%>) (init mk-wx get-wx-pan get-outer-wx-pan mismatches prnt [min-width no-val] [min-height no-val] [stretchable-width no-val] [stretchable-height no-val]) ...) Where `no-val` has been defined with a gensym. So it'd be nice to have the distinguished `no-argument` for these cases too. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Sublinear functions of superfloat numbers
Yeap. I totally misunderstood until I re-read the code. On Jul 2, 2012, at 11:57 AM, Vincent St-Amour wrote: > At Sun, 1 Jul 2012 20:10:30 -0400, > Matthias Felleisen wrote: >> I had misunderstood. I thought you had suggested 'reduction of >> strength' (say going from square to * or double to +), which is a >> generally useful compiler optimization. What you suggest is some form of >> conditional version of this. > > Argument reduction extends the domain of functions to work on arguments > that they can't handle directly (e.g. because they're too big to be > represented as floats). It's not an optimization. > > Vincent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Sublinear functions of superfloat numbers
At Sun, 1 Jul 2012 20:10:30 -0400, Matthias Felleisen wrote: > I had misunderstood. I thought you had suggested 'reduction of > strength' (say going from square to * or double to +), which is a > generally useful compiler optimization. What you suggest is some form of > conditional version of this. Argument reduction extends the domain of functions to work on arguments that they can't handle directly (e.g. because they're too big to be represented as floats). It's not an optimization. Vincent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Proposal for a "no-argument"
I really like this. Vincent At Sun, 1 Jul 2012 09:27:00 -0400, Eli Barzilay wrote: > > There rare cases where it is useful to have a value that means that no > argument was passed to a function. In many of these cases there is a > plain value that is used as that mark, with the most idiomatic one > being #f, but sometimes others are used. IMO, while such uses of #f > are idiomatic, they're a hack where an argument's domain is extended > only to mark "no argument". > > A more robust way to do that, which has become idiomatic in Racket is > to use (gensym). (And as a sidenote, in other implementations there > are various similar eq-based hacks.) IMO, this is an attempt to > improve on the #f case by guaranteeing a unique value, but at its core > it's still a similar hack. > > Recently, I have extended the `add-between' function in a way that ran > against this problem at the interface level, where two keyword > arguments default to such a gensymed value to detect when no argument > is passed. Natually, this "leaked" into the documentation in the form > of using `' to avoid specifying the default value and instead > talking about what happens when no argument is given for the keywords > in question. > > After a short discussion that I had with Matthew, the new version uses > a new keyword that holds the unique no-value value, to simplify > things: > > (define (foo x #:nothing [nothing (gensym)] [y nothing]) > (printf "y is ~s\n" (if (eq? y nothing) 'omitted y))) > > The idea is that this does not depend on some specific unique value, > since one can be given. For "end-users" of the function, there is no > need to know about this. It's useful only for wrapper functions which > want to mirror the same behavior, and call `foo' in a way that makes > their own input passed to it, including not passing it when its own > input is missing. In this case, you'd do something like this: > > (define (bar #:nothing [nothing (gensym)] [x nothing]) > (foo 10 x #:nothing nothing)) > > This works, but I dislike this solution for several reasons: > > 1. Instead of finding a solution for the `gensym' problem, this >approach embraces it as the proper way to do such things. > > 2. But more than that, it also exposes it in the interface of such >functions, which means that "simple end users" need to read about >it too. There is no easy way to somehow say "you souldn't worry >about this unless you're writing a function that ...", and if you >look at the current docs for `add-between' you'd probably wonder >when that #:nothing is useful. > > 3. There is also a half-story in this documentation -- even though the >docs look like the above function definition, you obviously would >want to define a single global gensymmed value and use it, to avoid >redundant allocation. By the way the docs read, the above does >look like the way to do these things, and I can see how a quick >reading would make people believe that it's fine to write: > > (define (foo) >(define (bar [x (gensym)]) > ...) >... call bar many times ...) > > I considered a bunch of alternatives to this, and the one closest to > looking reasonable is to use the # value: it makes some > sense because it is a value that is already used in some "no value" > cases. However, it is probably a bad idea to use it for something > different. In fact, that's how many languages end up with false, > null, undefined, etc etc. > > (As a side note, a different approach would be to use a per-argument > boolean flag that specifies if the corresponding argument. Since this > started with a documentation point of view, I'm assuming that it won't > be a good solution since it doesn't solve that problem -- a function > that uses it similarly to `add-between' would still need to avoid > specifying the default.) > > Instead, I suggest using a new "special" value, one that is used only > for this purpose. The big difference from all of these special values > is that I'm proposing a value that is used only for this. To > "discourage" using it for other reasons, there would be no binding for > it. Instead, there would be a fake one, say `no-argument', which is > used only as a syntax in a default expression and only there the real > no-argument gets used -- so the value is actually hidden and > `no-argument' is a syntactic marker that is otherwise an error to use, > like `else' and `=>'. (I'm no even suggesting making it a syntax > parameter that has a value in default expressions, because you > shouldn't be able to write (λ ([x (list no-argument)]) ...).) The > only real binding that gets added is something that identifies that > value, or even more convenient, something like `given?' that checks > whether its input is *not* that value. > > To demonstrate how this looks like, assume that the kernel has only a > three-argument `kernel-hash-ref', and you want to implement
Re: [racket-dev] Trouble with state, submodules, and module-begin
Is it possible there is another channel that TR could use to communicate these types? That is, could it not expand (: f Integer) (define f 5) into something that bound 'f' to a macro that knows its type? I guess it already does that, so something doesn't work about that here, but I'm not seeing what it is. Robby On Mon, Jul 2, 2012 at 8:07 AM, Matthew Flatt wrote: > Thoughts so far: > > I think you need a new communication channel to get information from > the expansion of an enclosing module to the expansion of its submodule. > > Expansion-time state is the right kind of channel, but I think it's > important to start every submodule's expansion in a fresh store, at > least usually. Otherwise, many syntactic extensions won't work > correctly in a submodule. > > To give the programmer more control, we could add a > `local-expand-submodule' function that is like `local-expand', but (1) > it works only for `module' and `module*' forms in a 'module context, > and (2) it accepts module paths to attach from the current expansion > context to the submodule's expansion context. > > Using this addition, when expanding a `(module* name #f )' > submodule, Typed Racket could attach a compile-time module that houses > the "in a typed context" flag --- the same one that Typed Racket's > `#%module-begin' sets. Does it sound like that would work? > > I worry that `local-expand-submodule' might be used to break a > syntactic form by attaching a module that isn't intended to be attached > to multiple expansion stores. I think a macro that abuses > `local-expand-submodule' could only harm itself or some other module > that trusts the macro, but it's difficult to be sure. > > At Mon, 25 Jun 2012 16:47:36 -0600, Matthew Flatt wrote: >> At Mon, 25 Jun 2012 17:50:27 -0400, Sam Tobin-Hochstadt wrote: >> > The problem (I >> > think) is that the implicit `require` of `(submod "..")` happens >> > *before* the expansion of `#%module-begin` inside the submodule. >> >> That's the same for a top-level module M whose initial language is some >> other module L, right? The require of `L' happens before the >> `#%module-begin' expansion in `M'... and it can't be any other way, >> because `#%module-begin' comes from `L'. >> >> > The >> > key bit of code is the residual snippet left in the outer module: >> > >> > (begin-for-syntax >> > (when (unbox is-typed?) >> > (set-box! type-env 1))) >> > >> > Currently, in TR, the code in the begin-for-syntax is unconditional, >> > and therefore it gets re-run in the store used for expanding the inner >> > submodule. However, if I add the `when`, then the `set-box!` doesn't >> > happen, and the expansion of `m` fails. I'd like to be able to add >> > this conditional, so I'd like to change the order of effects slightly >> > here. >> >> I see what you mean, but I don't think it makes sense to change the >> order of things in the way that you're suggesting. I don't have any >> immediate ideas, but I'll think about it more. >> >> >> _ >> 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] Trouble with state, submodules, and module-begin
Thoughts so far: I think you need a new communication channel to get information from the expansion of an enclosing module to the expansion of its submodule. Expansion-time state is the right kind of channel, but I think it's important to start every submodule's expansion in a fresh store, at least usually. Otherwise, many syntactic extensions won't work correctly in a submodule. To give the programmer more control, we could add a `local-expand-submodule' function that is like `local-expand', but (1) it works only for `module' and `module*' forms in a 'module context, and (2) it accepts module paths to attach from the current expansion context to the submodule's expansion context. Using this addition, when expanding a `(module* name #f )' submodule, Typed Racket could attach a compile-time module that houses the "in a typed context" flag --- the same one that Typed Racket's `#%module-begin' sets. Does it sound like that would work? I worry that `local-expand-submodule' might be used to break a syntactic form by attaching a module that isn't intended to be attached to multiple expansion stores. I think a macro that abuses `local-expand-submodule' could only harm itself or some other module that trusts the macro, but it's difficult to be sure. At Mon, 25 Jun 2012 16:47:36 -0600, Matthew Flatt wrote: > At Mon, 25 Jun 2012 17:50:27 -0400, Sam Tobin-Hochstadt wrote: > > The problem (I > > think) is that the implicit `require` of `(submod "..")` happens > > *before* the expansion of `#%module-begin` inside the submodule. > > That's the same for a top-level module M whose initial language is some > other module L, right? The require of `L' happens before the > `#%module-begin' expansion in `M'... and it can't be any other way, > because `#%module-begin' comes from `L'. > > > The > > key bit of code is the residual snippet left in the outer module: > > > > (begin-for-syntax > > (when (unbox is-typed?) > >(set-box! type-env 1))) > > > > Currently, in TR, the code in the begin-for-syntax is unconditional, > > and therefore it gets re-run in the store used for expanding the inner > > submodule. However, if I add the `when`, then the `set-box!` doesn't > > happen, and the expansion of `m` fails. I'd like to be able to add > > this conditional, so I'd like to change the order of effects slightly > > here. > > I see what you mean, but I don't think it makes sense to change the > order of things in the way that you're suggesting. I don't have any > immediate ideas, but I'll think about it more. > > > _ > Racket Developers list: > http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Sublinear functions of superfloat numbers
Is the following a fair summary? The idea is to divide the real axis in three parts. x < y < z Here x is a real (double), y is a slightly larger than +max.0, and z is a very large. Now sqrt(x) is just a real (double). Let y be an exact integer only slightly larger than +max.0. Even though y is larger than +max.0 the true sqrt of y is actually smaller than +max.0 and thus representable as a float. It is therefore possible to extend the standard sqrt function to numbers slightly above +max.0. For very large numbers z where sqrt(x) is larger than +max.0 return +inf.0 unless z happens to be a perfect square. The sqrt function is a sublinear function. This extension is also possible for other members of this class such as the logarithms. How to extend the function depend on the function. The other example, the periodic trigonometric functions is slighly different. Here the problem is that the argument must be reduced before the actual computation can take place. The reduction is simple in principle - just subtract the period repeatedly until the argumet is so small the standard function works However the period irrational, so in order to avoid loss of precision, one must compute the period with an appropriate number of decimals compared to the argument before the reduction can take place. /Jens Axel _ Racket Developers list: http://lists.racket-lang.org/dev
