Phil Bewig wrote:
> On May 11, 1:28 pm, namekuseijin <············@gmail.com> wrote:
>> I wish there was a match SRFI, like:
>>
>> http://docs.plt-scheme.org/reference/match.html
>>
>> You guys know Lisp/Scheme need parameter destructuring akin to that of
>> ML/Haskell. It's an incredibly handy feature! heck! all languages
>> should have match... having it as a common interface across
>> implementations should be a goal towards a modernized Scheme/Lisp.
>> But that's just IMO...
>
> It's so simple to write a pattern-matching macro that you don't need a
> SRFI. See my posting to comp.lang.scheme on April 22, 2008, or look
> at my blog at http://programmingpraxis.wordpress.com/standard-prelude/#pattern-matching,
> for a simple but highly useful pattern-matching macro, portable to any
> Scheme system with syntax-case.
That's nice. I'd still advocate for having it in a standard, preferably
in a RNRS. I don't want to have to collect and load my personal
patches to what's missing in Lisp/Scheme for it to be my perfect
language everytime a want to program.
Parameter destructuring has been a staple in functional programming
languages for some 20 years by now. Lisp/Scheme ought to evolve by
enforcing new idioms rather than leaving it to optional libraries or
personal wheels-from-scratch.
On May 12, 3:31 am, namekuseijin <···················@gmail.com>
wrote:
> Phil Bewig wrote:
> > On May 11, 1:28 pm, namekuseijin <············@gmail.com> wrote:
> >> I wish there was a match SRFI, like:
>
> >>http://docs.plt-scheme.org/reference/match.html
>
> >> You guys know Lisp/Scheme need parameter destructuring akin to that of
> >> ML/Haskell. It's an incredibly handy feature! heck! all languages
> >> should have match... having it as a common interface across
> >> implementations should be a goal towards a modernized Scheme/Lisp.
> >> But that's just IMO...
>
> > It's so simple to write a pattern-matching macro that you don't need a
> > SRFI. See my posting to comp.lang.scheme on April 22, 2008, or look
> > at my blog athttp://programmingpraxis.wordpress.com/standard-prelude/#pattern-matc...,
> > for a simple but highly useful pattern-matching macro, portable to any
> > Scheme system with syntax-case.
>
> That's nice. I'd still advocate for having it in a standard, preferably
> in a RNRS. I don't want to have to collect and load my personal
> patches to what's missing in Lisp/Scheme for it to be my perfect
> language everytime a want to program.
>
> Parameter destructuring has been a staple in functional programming
> languages for some 20 years by now. Lisp/Scheme ought to evolve by
> enforcing new idioms rather than leaving it to optional libraries or
> personal wheels-from-scratch.
That would be a very good thing.
Yet, in the meanwhile, people *could* help out with the development of
libraries that point in that direction... On the CL side there is -
shameless plug - CL-UNIFICATION. There aplenty of warts and bugs to
be swatted in it....
Cheers
--
Marco
ELS 2009 www.european-lisp-symposium.org
On May 12, 5:00 am, Marco Antoniotti <·······@gmail.com> wrote:
> On May 12, 3:31 am, namekuseijin <···················@gmail.com>
> wrote:
>
>
>
>
>
> > Phil Bewig wrote:
> > > On May 11, 1:28 pm, namekuseijin <············@gmail.com> wrote:
> > >> I wish there was a match SRFI, like:
>
> > >>http://docs.plt-scheme.org/reference/match.html
>
> > >> You guys know Lisp/Scheme need parameter destructuring akin to that of
> > >> ML/Haskell. It's an incredibly handy feature! heck! all languages
> > >> should have match... having it as a common interface across
> > >> implementations should be a goal towards a modernized Scheme/Lisp.
> > >> But that's just IMO...
>
> > > It's so simple to write a pattern-matching macro that you don't need a
> > > SRFI. See my posting to comp.lang.scheme on April 22, 2008, or look
> > > at my blog athttp://programmingpraxis.wordpress.com/standard-prelude/#pattern-matc...,
> > > for a simple but highly useful pattern-matching macro, portable to any
> > > Scheme system with syntax-case.
>
> > That's nice. I'd still advocate for having it in a standard, preferably
> > in a RNRS. I don't want to have to collect and load my personal
> > patches to what's missing in Lisp/Scheme for it to be my perfect
> > language everytime a want to program.
>
> > Parameter destructuring has been a staple in functional programming
> > languages for some 20 years by now. Lisp/Scheme ought to evolve by
> > enforcing new idioms rather than leaving it to optional libraries or
> > personal wheels-from-scratch.
>
> That would be a very good thing.
>
> Yet, in the meanwhile, people *could* help out with the development of
> libraries that point in that direction... On the CL side there is -
> shameless plug - CL-UNIFICATION. There aplenty of warts and bugs to
> be swatted in it....
Yes, I'm aware of that and it's indeed very good. :)
Hopefully a future CL standard may incorporate libs like that, kinda
like some boost libs are being incorporated into the standard C++ lib
for the upcoming next iteration of the language standard.
On May 12, 3:31 am, namekuseijin <···················@gmail.com>
wrote:
> Phil Bewig wrote:
> > On May 11, 1:28 pm, namekuseijin <············@gmail.com> wrote:
> >> I wish there was a match SRFI, like:
>
> >>http://docs.plt-scheme.org/reference/match.html
>
> >> You guys know Lisp/Scheme need parameter destructuring akin to that of
> >> ML/Haskell. It's an incredibly handy feature! heck! all languages
> >> should have match... having it as a common interface across
> >> implementations should be a goal towards a modernized Scheme/Lisp.
> >> But that's just IMO...
>
> > It's so simple to write a pattern-matching macro that you don't need a
> > SRFI. See my posting to comp.lang.scheme on April 22, 2008, or look
> > at my blog athttp://programmingpraxis.wordpress.com/standard-prelude/#pattern-matc...,
> > for a simple but highly useful pattern-matching macro, portable to any
> > Scheme system with syntax-case.
>
> That's nice. I'd still advocate for having it in a standard, preferably
> in a RNRS. I don't want to have to collect and load my personal
> patches to what's missing in Lisp/Scheme for it to be my perfect
> language everytime a want to program.
>
> Parameter destructuring has been a staple in functional programming
> languages for some 20 years by now. Lisp/Scheme ought to evolve by
> enforcing new idioms rather than leaving it to optional libraries or
> personal wheels-from-scratch.
Apart from my previous comment, there is another one that I'd like to
make. There is no "enforcing" in the Lisp communities (nobody forced
the Scheme folks - flame bait here! :) - to get in RNRS what was
already in CLtL1 in 1989). Given that attitude, there is no hope of
"enforcing" anything. This does not mean that things should not be
made "standard". I just want seamless extensions. I do not want to
have DEFUN suddendly "enforce" pattern matching. That would be too
much.
This is why I nag you to be more propositive about libraries.
Moreover, there is always a CDR or a SRFI waiting to be written.
Cheers
--
Marco
ELS 2009 www.european-lisp-symposium.org
On May 11, 8:31 pm, namekuseijin <···················@gmail.com>
wrote:
> Phil Bewig wrote:
> > On May 11, 1:28 pm, namekuseijin <············@gmail.com> wrote:
> >> I wish there was a match SRFI, like:
>
> >>http://docs.plt-scheme.org/reference/match.html
>
> >> You guys know Lisp/Scheme need parameter destructuring akin to that of
> >> ML/Haskell. It's an incredibly handy feature! heck! all languages
> >> should have match... having it as a common interface across
> >> implementations should be a goal towards a modernized Scheme/Lisp.
> >> But that's just IMO...
>
> > It's so simple to write a pattern-matching macro that you don't need a
> > SRFI. See my posting to comp.lang.scheme on April 22, 2008, or look
> > at my blog athttp://programmingpraxis.wordpress.com/standard-prelude/#pattern-matc...,
> > for a simple but highly useful pattern-matching macro, portable to any
> > Scheme system with syntax-case.
>
> That's nice. I'd still advocate for having it in a standard, preferably
> in a RNRS. I don't want to have to collect and load my personal
> patches to what's missing in Lisp/Scheme for it to be my perfect
> language everytime a want to program.
>
> Parameter destructuring has been a staple in functional programming
> languages for some 20 years by now. Lisp/Scheme ought to evolve by
> enforcing new idioms rather than leaving it to optional libraries or
> personal wheels-from-scratch.
I have a standard prelude that loads automatically every time I load
my Scheme interpreter. It's been so long since I've done it that I
have forgotten how -- I think there is a .schemerc file in my home
directory, which loads prelude.ss. Code like a pattern-matcher goes
in prelude.ss, and is always available. Doesn't everyone else do the
same thing?
One thing I don't like about Haskell's parameter pattern matching:
Haskell defines a strict order for checking the patterns.
While this is nice for programmers wishing to resolve ambiguities, it
imposes a cost on the execution model.
On May 12, 11:37 am, ··············@excite.com wrote:
> One thing I don't like about Haskell's parameter pattern matching:
> Haskell defines a strict order for checking the patterns.
CL-Unify and PLT's match are much more powerful and flexible. You may
even have regexes as pattern.
On May 12, 10:26 am, Phil Bewig <······@gmail.com> wrote:
> On May 11, 8:31 pm, namekuseijin <···················@gmail.com>
> > That's nice. I'd still advocate for having it in a standard, preferably
> > in a RNRS. I don't want to have to collect and load my personal
> > patches to what's missing in Lisp/Scheme for it to be my perfect
> > language everytime a want to program.
>
> I have a standard prelude that loads automatically every time I load
> my Scheme interpreter. It's been so long since I've done it that I
> have forgotten how -- I think there is a .schemerc file in my home
> directory, which loads prelude.ss. Code like a pattern-matcher goes
> in prelude.ss, and is always available. Doesn't everyone else do the
> same thing?
I used to have pretty huge and hackish emacsrc before ditching all
that insanity in favor of DrScheme.
Phil Bewig <······@gmail.com> writes:
> On May 11, 8:31�pm, namekuseijin <···················@gmail.com>
> wrote:
>> Parameter destructuring has been a staple in functional programming
>> languages for some 20 years by now. �Lisp/Scheme ought to evolve by
>> enforcing new idioms rather than leaving it to optional libraries or
>> personal wheels-from-scratch.
>
> I have a standard prelude that loads automatically every time I load
> my Scheme interpreter. It's been so long since I've done it that I
> have forgotten how -- I think there is a .schemerc file in my home
> directory, which loads prelude.ss. Code like a pattern-matcher goes
> in prelude.ss, and is always available. Doesn't everyone else do the
> same thing?
Yes of course. All implementations provide a RC file.
--
__Pascal Bourguignon__
Phil Bewig <······@gmail.com> writes:
>I have a standard prelude that loads automatically every time I load
>my Scheme interpreter. It's been so long since I've done it that I
>have forgotten how -- I think there is a .schemerc file in my home
>directory, which loads prelude.ss. Code like a pattern-matcher goes
>in prelude.ss, and is always available. Doesn't everyone else do the
>same thing?
Actually, not all of us. ;-) I for example, haven't ever used MATCH
for any real work that I did with Scheme. Maybe I always forget it
is there. I actually don't setup any prelude, and instead, have a
host of libraries that I have at the ready, and I drop those in when
I need them, but only when I do need them.
--
Aaron W. Hsu <·······@sacrideo.us> | <http://www.sacrideo.us>
"Government is the great fiction, through which everybody endeavors to
live at the expense of everybody else." -- Frederic Bastiat
+++++++++++++++ ((lambda (x) (x x)) (lambda (x) (x x))) ++++++++++++++
On May 12, 7:31 pm, Aaron W. Hsu <·······@sacrideo.us> wrote:
> Actually, not all of us. ;-) I for example, haven't ever used MATCH
> for any real work that I did with Scheme. Maybe I always forget it
> is there.
Perhaps you forget about it because it's not "let" or "do" or
"cond". ;)
If it was part of the syntax of "define", I'm sure it'd be remembered
quite fondly... ^_^
namekuseijin <············@gmail.com> writes:
>Perhaps you forget about it because it's not "let" or "do" or
>"cond". ;)
I forget about COND features, too, and I can never remember how DO
works, exactly, without thinking about it. On the other hand, things
I use all the time, like foof loop, I don't forget so easily.
--
Aaron W. Hsu <·······@sacrideo.us> | <http://www.sacrideo.us>
"Government is the great fiction, through which everybody endeavors to
live at the expense of everybody else." -- Frederic Bastiat
+++++++++++++++ ((lambda (x) (x x)) (lambda (x) (x x))) ++++++++++++++
On May 13, 8:04 pm, Aaron W. Hsu <·······@sacrideo.us> wrote:
> namekuseijin <············@gmail.com> writes:
> >Perhaps you forget about it because it's not "let" or "do" or
> >"cond". ;)
>
> I forget about COND features, too, and I can never remember how DO
> works, exactly, without thinking about it. On the other hand, things
> I use all the time, like foof loop, I don't forget so easily.
I quickly taught myself do by reworking a named let into it and seeing
if it worked out. Never to forget it anymore nor use verbose named
lets except where strictly necessary (several stop conditions, for
instance)...
On May 13, 8:47 pm, namekuseijin <············@gmail.com> wrote:
> I quickly taught myself do by reworking a named let into it and seeing
> if it worked out. Never to forget it anymore nor use verbose named
> lets except where strictly necessary (several stop conditions, for
> instance)...
I recall this topic came up on the PLT discussion list.
It seems that 'do', while part of the standard, is not idiomatic
Scheme.
No reason not to use it, though.
On May 14, 7:26 am, Grant Rettke <·······@gmail.com> wrote:
> On May 13, 8:47 pm, namekuseijin <············@gmail.com> wrote:
>
> > I quickly taught myself do by reworking a named let into it and seeing
> > if it worked out. Never to forget it anymore nor use verbose named
> > lets except where strictly necessary (several stop conditions, for
> > instance)...
>
> I recall this topic came up on the PLT discussion list.
>
> It seems that 'do', while part of the standard, is not idiomatic
> Scheme.
Is it not idiomatic because it's not that much used or is it not that
much used because it's not that much idiomatic? ;)
((lambda (idiomatic used) (idiomatic used)) (lambda (used) used))
:P
On May 14, 12:31 pm, namekuseijin <············@gmail.com> wrote:
> Is it not idiomatic because it's not that much used or is it not that
> much used because it's not that much idiomatic? ;)
I am not sure :).
These days I am guessing that SRFI-42 takes care of most cases where
do would normally have been a good fit.
Grant Rettke <·······@gmail.com> writes:
>On May 14, 12:31=A0pm, namekuseijin <············@gmail.com> wrote:
>> Is it not idiomatic because it's not that much used or is it not that
>> much used because it's not that much idiomatic? ;)
>I am not sure :).
>These days I am guessing that SRFI-42 takes care of most cases where
>do would normally have been a good fit.
I don't use DO because it only works in a certain subset of problems,
and so I prefer something more generic that I have to learn once and
can use in most of my cases.
--
Aaron W. Hsu <·······@sacrideo.us> | <http://www.sacrideo.us>
"Government is the great fiction, through which everybody endeavors to
live at the expense of everybody else." -- Frederic Bastiat
+++++++++++++++ ((lambda (x) (x x)) (lambda (x) (x x))) ++++++++++++++
On May 15, 2:17 am, Aaron W. Hsu <·······@sacrideo.us> wrote:
> I don't use DO because it only works in a certain subset of problems,
> and so I prefer something more generic that I have to learn once and
> can use in most of my cases.
Same here. Also, I find named let much easier to read.
On May 14, 8:26 pm, Michele Simionato <·················@gmail.com>
wrote:
> On May 15, 2:17 am, Aaron W. Hsu <·······@sacrideo.us> wrote:
>
> > I don't use DO because it only works in a certain subset of problems,
> > and so I prefer something more generic that I have to learn once and
> > can use in most of my cases.
>
> Same here. Also, I find named let much easier to read.
I love named let. I flex it for things do could never do. When you
think of it as a recursive procedure, which it is, and the problem
you're using it for as something to be solved recursively, it makes
more sense. I like it instead of initially making and calling a
procedure manually for situations where control always immediately
enters it and it reads better for the start to be a let, and because I
also like learning one powerful thing (recursive procedures) instead
of remembering the uniquenesses of something like Foof Loop or SRFI
42. I've not been motivated to use something else because named let
is simple, fairly concise, and gives me full control to make custom
solutions, without worrying there's some underlying aspect I forgot to
account for. I do use do occasionally for very simple things (which
is all I can visually tolerate it for) when I feel like adding some
variety.
--
: Derick
----------------------------------------------------------------
On May 15, 1:59 am, Derick Eddington <················@gmail.com>
wrote:
> On May 14, 8:26 pm, Michele Simionato <·················@gmail.com>
> wrote:
>
> > On May 15, 2:17 am, Aaron W. Hsu <·······@sacrideo.us> wrote:
>
> > > I don't use DO because it only works in a certain subset of problems,
> > > and so I prefer something more generic that I have to learn once and
> > > can use in most of my cases.
>
> > Same here. Also, I find named let much easier to read.
>
> I love named let. I flex it for things do could never do. When you
> think of it as a recursive procedure, which it is, and the problem
> you're using it for as something to be solved recursively, it makes
> more sense. I like it instead of initially making and calling a
> procedure manually for situations where control always immediately
> enters it and it reads better for the start to be a let, and because I
> also like learning one powerful thing (recursive procedures) instead
> of remembering the uniquenesses of something like Foof Loop or SRFI
> 42. I've not been motivated to use something else because named let
> is simple, fairly concise, and gives me full control to make custom
> solutions, without worrying there's some underlying aspect I forgot to
> account for. I do use do occasionally for very simple things (which
> is all I can visually tolerate it for) when I feel like adding some
> variety.
>
> --
> : Derick
> ----------------------------------------------------------------
Although it's not absolute, I tend to use named-let for functional
code and reserve the use of do for those cases where mutations
involved. That makes it easier to read code, because if I see a ! in
a named-let I know I probably have something wrong in my thinking
about the code.
Phil Bewig escreveu:
> On May 15, 1:59 am, Derick Eddington <················@gmail.com>
> wrote:
>> On May 14, 8:26 pm, Michele Simionato <·················@gmail.com>
>> wrote:
>>
>>> On May 15, 2:17 am, Aaron W. Hsu <·······@sacrideo.us> wrote:
>>>> I don't use DO because it only works in a certain subset of problems,
>>>> and so I prefer something more generic that I have to learn once and
>>>> can use in most of my cases.
>>> Same here. Also, I find named let much easier to read.
>> I love named let. I flex it for things do could never do. When you
>> think of it as a recursive procedure, which it is, and the problem
>> you're using it for as something to be solved recursively, it makes
>> more sense. I like it instead of initially making and calling a
>> procedure manually for situations where control always immediately
>> enters it and it reads better for the start to be a let, and because I
>> also like learning one powerful thing (recursive procedures) instead
>> of remembering the uniquenesses of something like Foof Loop or SRFI
>> 42. I've not been motivated to use something else because named let
>> is simple, fairly concise, and gives me full control to make custom
>> solutions, without worrying there's some underlying aspect I forgot to
>> account for. I do use do occasionally for very simple things (which
>> is all I can visually tolerate it for) when I feel like adding some
>> variety.
>>
>> --
>> : Derick
>> ----------------------------------------------------------------
>
> Although it's not absolute, I tend to use named-let for functional
> code and reserve the use of do for those cases where mutations
> involved. That makes it easier to read code, because if I see a ! in
> a named-let I know I probably have something wrong in my thinking
> about the code.
I see you guys don't really like do, though it is absolutely not an
imperative construct at all. It's a simplified named let for
situations when a single final condition is intended.
For instance, here's purely functional fibbonaci in named let:
(define (fib x)
(let go ((i 2)
(fib1 1)
(fib0 1))
(if (> i x) fib1
(go (+ 1 i) (+ fib1 fib0) fib1))))
and here's purely functional fibbonaci in do:
(define (fib x)
(do ((i 2 (+ 1 i))
(fib1 1 (+ fib1 fib0))
(fib0 1 fib1))
((> i x) fib1)))
You just edit the original like this: move the updates to the
parameters in the tail call to go together with their bindings, just
after their initial values, replace "let go" with "do" and remove the
whole single tail call and put an *if* just before the stop
condition. That's all.
Much simpler and more practical, this accounts for about 80% of simple
loops out there. If you want side-effects, you may trigger them at
each iteration by putting all of them just before the last ). No need
for begin either. Very concise. I was not a fan either, but it grew
on me...
--
a game sig: http://tinyurl.com/d3rxz9
On May 15, 3:09 pm, namekuseijin <············@gmail.com> wrote:
> Phil Bewig escreveu:
>
>
>
>
>
> > On May 15, 1:59 am, Derick Eddington <················@gmail.com>
> > wrote:
> >> On May 14, 8:26 pm, Michele Simionato <·················@gmail.com>
> >> wrote:
>
> >>> On May 15, 2:17 am, Aaron W. Hsu <·······@sacrideo.us> wrote:
> >>>> I don't use DO because it only works in a certain subset of problems,
> >>>> and so I prefer something more generic that I have to learn once and
> >>>> can use in most of my cases.
> >>> Same here. Also, I find named let much easier to read.
> >> I love named let. I flex it for things do could never do. When you
> >> think of it as a recursive procedure, which it is, and the problem
> >> you're using it for as something to be solved recursively, it makes
> >> more sense. I like it instead of initially making and calling a
> >> procedure manually for situations where control always immediately
> >> enters it and it reads better for the start to be a let, and because I
> >> also like learning one powerful thing (recursive procedures) instead
> >> of remembering the uniquenesses of something like Foof Loop or SRFI
> >> 42. I've not been motivated to use something else because named let
> >> is simple, fairly concise, and gives me full control to make custom
> >> solutions, without worrying there's some underlying aspect I forgot to
> >> account for. I do use do occasionally for very simple things (which
> >> is all I can visually tolerate it for) when I feel like adding some
> >> variety.
>
> >> --
> >> : Derick
> >> ----------------------------------------------------------------
>
> > Although it's not absolute, I tend to use named-let for functional
> > code and reserve the use of do for those cases where mutations
> > involved. That makes it easier to read code, because if I see a ! in
> > a named-let I know I probably have something wrong in my thinking
> > about the code.
>
> I see you guys don't really like do, though it is absolutely not an
> imperative construct at all. It's a simplified named let for
> situations when a single final condition is intended.
>
> For instance, here's purely functional fibbonaci in named let:
>
> (define (fib x)
> (let go ((i 2)
> (fib1 1)
> (fib0 1))
> (if (> i x) fib1
> (go (+ 1 i) (+ fib1 fib0) fib1))))
>
> and here's purely functional fibbonaci in do:
>
> (define (fib x)
> (do ((i 2 (+ 1 i))
> (fib1 1 (+ fib1 fib0))
> (fib0 1 fib1))
> ((> i x) fib1)))
>
> You just edit the original like this: move the updates to the
> parameters in the tail call to go together with their bindings, just
> after their initial values, replace "let go" with "do" and remove the
> whole single tail call and put an *if* just before the stop
> condition. That's all.
>
> Much simpler and more practical, this accounts for about 80% of simple
> loops out there. If you want side-effects, you may trigger them at
> each iteration by putting all of them just before the last ). No need
> for begin either. Very concise. I was not a fan either, but it grew
> on me...
errata: *remove* the if in the conversion. :)
namekuseijin <············@gmail.com> writes:
>I see you guys don't really like do, though it is absolutely not an
>imperative construct at all. It's a simplified named let for
>situations when a single final condition is intended.
I do not like DO simply because I think it is too limited. By that,
I mean that the set of problems for which is clearly and simply
works is not worth the time taken to put it into fast access mental
memory.
>For instance, here's purely functional fibbonaci in named let:
>(define (fib x)
> (let go ((i 2)
> (fib1 1)
> (fib0 1))
> (if (> i x) fib1
> (go (+ 1 i) (+ fib1 fib0) fib1))))
>and here's purely functional fibbonaci in do:
>(define (fib x)
> (do ((i 2 (+ 1 i))
> (fib1 1 (+ fib1 fib0))
> (fib0 1 fib1))
> ((> i x) fib1)))
And here's the same in nested foof loop:
(define fib
(lambda (n)
(loop ([for i (up-from 1 (to n))]
[for res (summing (initial 1) old)]
[with old 1 res])
=> res)))
I like this better than DO.
--
Aaron W. Hsu <·······@sacrideo.us> | <http://www.sacrideo.us>
"Government is the great fiction, through which everybody endeavors to
live at the expense of everybody else." -- Frederic Bastiat
+++++++++++++++ ((lambda (x) (x x)) (lambda (x) (x x))) ++++++++++++++
From: namekuseijin
Subject: Re: standard parameter matching (was Re: Your favourite SRFIs?)
Date:
Message-ID: <guknkh$4on$1@adenine.netfront.net>
Aaron W. Hsu escreveu:
> namekuseijin <············@gmail.com> writes:
>> I see you guys don't really like do, though it is absolutely not an
>> imperative construct at all. It's a simplified named let for
>> situations when a single final condition is intended.
>
> I do not like DO simply because I think it is too limited. By that,
> I mean that the set of problems for which is clearly and simply
> works is not worth the time taken to put it into fast access mental
> memory.
It's not more mental work than getting on with a similarly simple named
let. And it's also shorter. :)
>> For instance, here's purely functional fibbonaci in named let:
>
>> (define (fib x)
>> (let go ((i 2)
>> (fib1 1)
>> (fib0 1))
>> (if (> i x) fib1
>> (go (+ 1 i) (+ fib1 fib0) fib1))))
>
>> and here's purely functional fibbonaci in do:
>
>> (define (fib x)
>> (do ((i 2 (+ 1 i))
>> (fib1 1 (+ fib1 fib0))
>> (fib0 1 fib1))
>> ((> i x) fib1)))
>
> And here's the same in nested foof loop:
>
> (define fib
> (lambda (n)
> (loop ([for i (up-from 1 (to n))]
> [for res (summing (initial 1) old)]
> [with old 1 res])
> => res)))
>
> I like this better than DO.
It's not as simple nor as concise. Besides, it requires knowledge of a
mini-language akin to that of CL's loop. In other words, it seems to
require far more mental work than do. :)
And I still don't like the name. How about floop? :P
--
a game sig: http://tinyurl.com/d3rxz9
namekuseijin <············@gmail.com> writes:
>Aaron W. Hsu escreveu:
>> namekuseijin <············@gmail.com> writes:
>>> I see you guys don't really like do, though it is absolutely not an
>>> imperative construct at all. It's a simplified named let for
>>> situations when a single final condition is intended.
>>
>> I do not like DO simply because I think it is too limited. By that,
>> I mean that the set of problems for which is clearly and simply
>> works is not worth the time taken to put it into fast access mental
>> memory.
>It's not more mental work than getting on with a similarly simple named
>let. And it's also shorter. :)
>>> For instance, here's purely functional fibbonaci in named let:
>>
>>> (define (fib x)
>>> (let go ((i 2)
>>> (fib1 1)
>>> (fib0 1))
>>> (if (> i x) fib1
>>> (go (+ 1 i) (+ fib1 fib0) fib1))))
>>
>>> and here's purely functional fibbonaci in do:
>>
>>> (define (fib x)
>>> (do ((i 2 (+ 1 i))
>>> (fib1 1 (+ fib1 fib0))
>>> (fib0 1 fib1))
>>> ((> i x) fib1)))
>>
>> And here's the same in nested foof loop:
>>
>> (define fib
>> (lambda (n)
>> (loop ([for i (up-from 1 (to n))]
>> [for res (summing (initial 1) old)]
>> [with old 1 res])
>> => res)))
>>
>> I like this better than DO.
>It's not as simple nor as concise. Besides, it requires knowledge of a
>mini-language akin to that of CL's loop. In other words, it seems to
>require far more mental work than do. :)
It may not be as concise, but I did the above just to illustrate
some of the other features. You can do everything that DO can do
with the keywords WITH and UNTIL. On the other hand, you can do
much more than that, and the use of keywords in places where it
makes sense to use them makes the code easier to read, IMO.
It really is as simple if you don't want to take it beyond DO. In
the above case, I do.
However, where it pays off is when you want to use the same structure
and syntax for handling the kinds of loops for which DO is not elegant,
and one might be tempted to go back to a Named LET. For these,
foof loop works nicely because it has a lot of built in iterators
and accumulators (and has a nested looping a la comprehensions built
on top of it as well), so it usually works out of the box. If you want
even more, you can easily write your own iterators, and the syntax
is easy to use, still.
In other words, foof loop scales to more tasks more easily than DO
does, so it is worth learning, as opposed to DO, which I feel doesn't
scale well enough to make it worth learning well.
Foof loop subsumes things like SRFI 42 as well as DO and Named LETs,
which makes it very general.
>And I still don't like the name. How about floop? :P
It's named after the IRC nickname of the person who inspired the
author to write it.
--
Aaron W. Hsu <·······@sacrideo.us> | <http://www.sacrideo.us>
"Government is the great fiction, through which everybody endeavors to
live at the expense of everybody else." -- Frederic Bastiat
+++++++++++++++ ((lambda (x) (x x)) (lambda (x) (x x))) ++++++++++++++
On Fri, 15 May 2009 06:20:46 -0700 (PDT), Phil Bewig
<······@gmail.com> wrote:
>On May 15, 1:59�am, Derick Eddington <················@gmail.com>
>wrote:
>> On May 14, 8:26 pm, Michele Simionato <·················@gmail.com>
>> wrote:
>>
>> > On May 15, 2:17 am, Aaron W. Hsu <·······@sacrideo.us> wrote:
>>
>> > > I don't use DO because it only works in a certain subset of problems,
>> > > and so I prefer something more generic that I have to learn once and
>> > > can use in most of my cases.
>>
>> > Same here. Also, I find named let much easier to read.
>>
>> I love named let. �I flex it for things do could never do. �When you
>> think of it as a recursive procedure, which it is, and the problem
>> you're using it for as something to be solved recursively, it makes
>> more sense. �I like it instead of initially making and calling a
>> procedure manually for situations where control always immediately
>> enters it and it reads better for the start to be a let, and because I
>> also like learning one powerful thing (recursive procedures) instead
>> of remembering the uniquenesses of something like Foof Loop or SRFI
>> 42. �I've not been motivated to use something else because named let
>> is simple, fairly concise, and gives me full control to make custom
>> solutions, without worrying there's some underlying aspect I forgot to
>> account for. �I do use do occasionally for very simple things (which
>> is all I can visually tolerate it for) when I feel like adding some
>> variety.
>>
>> --
>> : Derick
>> ----------------------------------------------------------------
>
>Although it's not absolute, I tend to use named-let for functional
>code and reserve the use of do for those cases where mutations
>involved. That makes it easier to read code, because if I see a ! in
>a named-let I know I probably have something wrong in my thinking
>about the code.
All of this just personal preference. DO is a very general mechanism
capable of almost anything (maybe anything) that named-let can do ...
it expands into a named-let on the two Schemes I use. The difference
is syntax: because DO has to be used as defined, it can quickly become
cumbersome if you try to use it for a complex recursive procedure like
a tree traversal. It's not that DO can't do it, it's that code using
named-let is typically clearer and less complicated.
That said, I would never try to use DO for a complex recursion -
because I wouldn't wish it on another programmer to figure it out
later. I use DO when what I want is semantically a loop because
that's what it's meant for.
YMMV
George
On May 15, 1:59 am, Derick Eddington <················@gmail.com>
wrote:
> I also like learning one powerful thing (recursive procedures) instead
> of remembering the uniquenesses of something like Foof Loop or SRFI 42.
I love named let, too, but SRFI 42 is great for doing things like
porting over highly-mutative code that is too ugly and confusing to be
written using named lets, at least on the first pass.
People seem to like list comprehensions; and they get warm fuzzies
when they find that Scheme has them, it is a good selling point.
Grant Rettke <·······@gmail.com> writes:
>I love named let, too, but SRFI 42 is great for doing things like
>porting over highly-mutative code that is too ugly and confusing to be
>written using named lets, at least on the first pass.
>People seem to like list comprehensions; and they get warm fuzzies
>when they find that Scheme has them, it is a good selling point.
That's true, but I'm not sure SRFI 42 is the best one out there.
On the other hand, at least it is something that people are using
and makes the code a little more readable over a Named LET when dealing
with comprehensions. It's better than nothing.
--
Aaron W. Hsu <·······@sacrideo.us> | <http://www.sacrideo.us>
"Government is the great fiction, through which everybody endeavors to
live at the expense of everybody else." -- Frederic Bastiat
+++++++++++++++ ((lambda (x) (x x)) (lambda (x) (x x))) ++++++++++++++
On May 12, 3:31 pm, Aaron W. Hsu <·······@sacrideo.us> wrote:
> Phil Bewig <······@gmail.com> writes:
> >I have a standard prelude that loads automatically every time I load
> >my Scheme interpreter. It's been so long since I've done it that I
> >have forgotten how -- I think there is a .schemerc file in my home
> >directory, which loads prelude.ss. Code like a pattern-matcher goes
> >in prelude.ss, and is always available. Doesn't everyone else do the
> >same thing?
> I actually don't setup any prelude, and instead, have a
> host of libraries that I have at the ready, and I drop those in when
> I need them, but only when I do need them.
Me too. IMHO, a prelude blob of all sorts of things which loads into
a global namespace sounds like a nightmare. My Emacs configuration is
quite small and is still thoughtfully organized into separate files
and I fear ever growing it.
--
: Derick
----------------------------------------------------------------
Derick Eddington <················@gmail.com> writes:
>On May 12, 3:31=A0pm, Aaron W. Hsu <·······@sacrideo.us> wrote:
>> I actually don't setup any prelude, and instead, have a
>> host of libraries that I have at the ready, and I drop those in when
>> I need them, but only when I do need them.
>Me too. IMHO, a prelude blob of all sorts of things which loads into
>a global namespace sounds like a nightmare.
I don't like it because if I ever distribute code, it requires that I
distribute the whole prelude file. I prefer to separate my code into
little libraries that fit more neatly into distributing code.
--
Aaron W. Hsu <·······@sacrideo.us> | <http://www.sacrideo.us>
"Government is the great fiction, through which everybody endeavors to
live at the expense of everybody else." -- Frederic Bastiat
+++++++++++++++ ((lambda (x) (x x)) (lambda (x) (x x))) ++++++++++++++