Re: [racket-dev] And/or as procedures when not in application position
On Mon, Dec 10, 2012 at 11:05 PM, Matthias Felleisen wrote: > > If you can make syntax identifier thingies like and behave as in a > short-cutting way when they are used in a context such as andmap, I have no > objections. You would need a different list operation -- you can't express `andmap` in terms of `foldr` no matter what you do with `and` (but you surely know that). Sam _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] And/or as procedures when not in application position
If you can make syntax identifier thingies like and behave as in a short-cutting way when they are used in a context such as andmap, I have no objections. By coincidence, I talked to Vincent an idea like that today but not and and andmap. On Dec 10, 2012, at 8:53 PM, Sam Tobin-Hochstadt wrote: > On Mon, Dec 10, 2012 at 7:07 PM, Matthias Felleisen > wrote: >> >> Using and and or as higher-order functions, say for (fold (combine f and) #t >> l) has performance implications. It is quite different from (andmap f l). > > In one sense, this is obviously true, since `andmap` is > short-circuiting. But with a sightly different implementation of > `andmap`, I think (based on looking at the decompiled output) that > these would generate basically identical code. So the extra > higher-orderness shouldn't be a performance problem here. > > Sam smime.p7s Description: S/MIME cryptographic signature _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] And/or as procedures when not in application position
On Mon, Dec 10, 2012 at 7:07 PM, Matthias Felleisen wrote: > > Using and and or as higher-order functions, say for (fold (combine f and) #t > l) has performance implications. It is quite different from (andmap f l). In one sense, this is obviously true, since `andmap` is short-circuiting. But with a sightly different implementation of `andmap`, I think (based on looking at the decompiled output) that these would generate basically identical code. So the extra higher-orderness shouldn't be a performance problem here. Sam _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] And/or as procedures when not in application position
Using and and or as higher-order functions, say for (fold (combine f and) #t l) has performance implications. It is quite different from (andmap f l). We have thought about this for the student languages on and off. And in the end I have always come to the conclusion that students must find out about such differences and must know about them. We might as well throw them in with the first course. On Dec 10, 2012, at 6:16 PM, J. Ian Johnson wrote: > I just made a pull request for making and/or expand to functions that perform > and/or following a discussion with stamourv and asumu. Vincent believes these > additions should also be made to the student languages, but I thought I'd > start a discussion about this before doing that work. > What are people's thoughts on this? > -Ian > _ > 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] And/or as procedures when not in application position
I don't like this idea for Racket. The macros "and" and "or" do not behave
like functions any more than "if" does. This isn't Haskell, our functions
are eager while our conditional forms are short-circuiting. If we want
first-order values that perform conjunction and disjunction, but eagerly,
we should give them separate names. Otherwise we're going to get some very
confusing programs. For instance, if you treat "and" / "or" as functions,
various program transformations that seem sensible no longer hold. For
instance,
(and #true 'result (error "oh no"))
is not the same as
(let {[f and]} (f #true 'result (error "oh no")))
...if "and" produces a short-circuiting form in the former case and an
eager function in the latter.
I do agree that functions performing boolean conjunction/disjunction are
useful. We could call these things andf / orf, and/proc / or/proc, conj /
disj, or any number of other paired names that aren't already taken for
conditional special forms.
Carl Eastlund
On Mon, Dec 10, 2012 at 6:16 PM, J. Ian Johnson wrote:
> I just made a pull request for making and/or expand to functions that
> perform and/or following a discussion with stamourv and asumu. Vincent
> believes these additions should also be made to the student languages, but
> I thought I'd start a discussion about this before doing that work.
> What are people's thoughts on this?
> -Ian
> _
> Racket Developers list:
> http://lists.racket-lang.org/dev
>
>
_
Racket Developers list:
http://lists.racket-lang.org/dev
[racket-dev] And/or as procedures when not in application position
I just made a pull request for making and/or expand to functions that perform and/or following a discussion with stamourv and asumu. Vincent believes these additions should also be made to the student languages, but I thought I'd start a discussion about this before doing that work. What are people's thoughts on this? -Ian _ Racket Developers list: http://lists.racket-lang.org/dev
