Your favourite SRFIs?
aschemer
I'd like to add SRFI code completion to LambdaBeans, so that when you
type,
say, "xcons" you get detailed information about the "xcons" defined in
srfi-1.
The fact is that there're lots of SRFI's out there, and HTML formats
among them
vary wildly, so I'd like to focus on the most popular/preferred/used
SRFIs
first and gradually enhance autocompletion.
I'd appreciate if you reply to this message with those SRFI's you like
most/use
more frequently so that I can add completion support for LambdaBeans.
Thanks in advance,
Antonio
rotty
http://synthcode.com/emacs/). It contains completion info for quite a
few SRFIs, all in the form of S-Expressions, so pulling it into
LambdaBeans should be easy.
HTH, Rotty
aschemer
Thanks!
The fact is that I'd like to add some more documentation to the
completion window (with a small excerpt of the SRFI documents, and
possibly a link to srfi.org), so I assume I'll have to work it myself
a little bit.
I think SRFI-1 *and* scheme-complete is a good start.
Thanks again,
Antonio
On 11 mayo, 15:03, rotty <a.rottm...@gmx.at> wrote:
> On May 11, 11:46 am, aschemer <vie...@gmail.com> wrote:
>
> > Hi all,
>
> > I'd like to add SRFI code completion to LambdaBeans, so that when you
> > type,
> > say, "xcons" you get detailed information about the "xcons" defined in
> > srfi-1.
>
> > The fact is that there're lots of SRFI's out there, and HTML formats
> > among them
> > vary wildly, so I'd like to focus on the most popular/preferred/used
> > SRFIs
> > first and gradually enhance autocompletion.
>
> > I'd appreciate if you reply to this message with those SRFI's you like
> > most/use
> > more frequently so that I can add completion support for LambdaBeans.
>
> You should probably have a look at scheme-complete (linked fromhttp://synthcode.com/emacs/). It contains completion info for quite a
rotty
>
> The fact is that I'd like to add some more documentation to the
> completion window (with a small excerpt of the SRFI documents, and
> possibly a link to srfi.org), so I assume I'll have to work it myself
> a little bit.
>
> I think SRFI-1 *and* scheme-complete is a good start.
>
which
links to the various SRFIs that come with PLT; perhaps you could grab
some
stuff from there as well.
Regards, Rotty
Grant Rettke
> I'd appreciate if you reply to this message with those SRFI's you like
> most/use more frequently so that I can add completion support for LambdaBeans.
1 lists
6 basic-string-ports
13 strings
26 cut
28 basic-format-strings
42 eager-comprehensions
namekuseijin
I'd add:
2: and-let*
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...
Phil Bewig
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.
Grant Rettke
> It's so simple to write a pattern-matching macro that you don't need a SRFI.
Ease of implementation doesn't mean it wouldn't be a good SRFI does
it?
It would be nice to have a standard match.
Ramana
> On 11 maio, 12:59, Grant Rettke <gret...@gmail.com> wrote:
>
> > On May 11, 4:46 am, aschemer <vie...@gmail.com> wrote:
>
> > > I'd appreciate if you reply to this message with those SRFI's you like
> > > most/use more frequently so that I can add completion support for LambdaBeans.
>
> > 1 lists
> > 6 basic-string-ports
> > 13 strings
> > 26 cut
> > 28 basic-format-strings
> > 42 eager-comprehensions
>
> I'd add:
> 2: and-let*
I would also add
27: random-bits
sometimes random bits are very useful.
namekuseijin
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.
Marco Antoniotti
wrote:
> Phil Bewig wrote:
> > On May 11, 1:28 pm, namekuseijin <namekusei...@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
> > 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
Phil Bewig
wrote:
> Phil Bewig wrote:
> > On May 11, 1:28 pm, namekuseijin <namekusei...@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
> > 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?
daniel....@excite.com
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.
Pascal J. Bourguignon
Yes of course. All implementations provide a RC file.
--
__Pascal Bourguignon__
Grant Rettke
> 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?
A match SRFI would make that reliable standard available for everyone.
I suppose if people wanted it there would be one.
namekuseijin
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.
namekuseijin
> On May 11, 8:31 pm, namekuseijin <namekuseijin.nos...@gmail.com>
> > 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.
>
> 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.
namekuseijin
> 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.
Aaron W. Hsu
>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 <arc...@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))) ++++++++++++++
namekuseijin
> 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... ^_^
Derick Eddington
> Phil Bewig <pbe...@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
----------------------------------------------------------------
Grant Rettke
To answer your question, I don't do this.
Everything I use is either in an SRFI or a module that I load when I
need it.
Aaron W. Hsu
>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
>On May 12, 3:31=A0pm, Aaron W. Hsu <arcf...@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.
namekuseijin
> namekuseijin <namekusei...@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)...
Grant Rettke
> 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.
namekuseijin
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
Grant Rettke
> 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.
Aaron W. Hsu
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.
Michele Simionato
> 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.
Derick Eddington
wrote:
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
----------------------------------------------------------------
Phil Bewig
wrote:
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.
namekuseijin
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
namekuseijin
errata: *remove* the if in the conversion. :)
George Neuner
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
Aaron W. Hsu
>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.
Grant Rettke
> 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.
namekuseijin
> namekuseijin <nameku...@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
Aaron W. Hsu
>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
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.