No standard matcher, and standardization efficiency
Derick Eddington
including a matcher in the Scheme standard.
I disagree that a matcher should be part of the standard because
attempting to do so will bog-down the people who make the standard and
whatever they come up with is not going to make many people happy and
so they'd just continue to use some other matcher from a "non-
standard" library. Plus, I imagine the debates about how The Standard
Matcher should be will be a huge waste of the standardization
process's time and energy. I've implemented a non-trivial matcher and
reviewed a number of others. There are tons of details people would
never stop arguing over.
What we need, and have with R6RS (flaws and all), is a standard for
portable libraries. Then anybody can make a seriously professional
and portable matcher which might become the de-facto "standard" one.
Really, the only difference is:
(import (rnrs match)) versus (import (acme match))
Because of the nature of matchers, if macros are portable, there's no
reason everybody's code needs to use the same matcher. They all work
with the same standard data types. And if/when you need some matcher
feature that The Standard Matcher doesn't have, you'll still be using
a "non-standard" matcher.
My matcher and the others I've ported (the porting was very easy
because they were R5RS) are fully portable to any R6RS system. You
just import them exactly as simply as you'd import The Standard
Matcher.
I suspect that syntax-case doesn't even need to be part of a standard
with portable hygienic macros which work with separately-compiled
libraries (and whatever other qualities R6RS macros accomplish). If
the standard provided a predicate for syntax objects and the ability
to unwrap syntax objects one layer at a time (and maybe some other
stuff?), I imagine my matcher (and others') could have fully portable
support for destructuring-binding syntax objects. Note that R6RS-
style lexically-scoped hygienic syntax templates don't require syntax-
case, and with-syntax (to support the spiffy sophisticated declarative
pattern variable splicing) does not have to be implemented on top of
syntax-case (I think).
Maybe I'm wrong about syntax-case, but you get my point about not
bogging-down the standard.
--
: Derick
----------------------------------------------------------------
Derick Eddington
wrote:
> I suspect that syntax-case doesn't even need to be part of a standard
> with portable hygienic macros which work with separately-compiled
> libraries
I, of course, meant portable hygienic _procedural_ macros.
--
: Derick
----------------------------------------------------------------
Grant Rettke
wrote:
Are you suggesting a standard? Or more?
namekuseijin
wrote:
> What we need, and have with R6RS (flaws and all), is a standard for
> portable libraries. Then anybody can make a seriously professional
> and portable matcher which might become the de-facto "standard" one.
Yes, and I hope one is ready for inclusion in R7RS, like some boost
libs are getting into C++ upcoming new standard.
> Really, the only difference is:
> (import (rnrs match)) versus (import (acme match))
There's a more subtle but stronger difference I guess: since it's not
a part of the core libs, like let or cond, it's usefulness is not
readily available and many people coming into Scheme are not even
aware of it as an external lib or even what it is all about. Heck,
"do" is pretty useful and yet lots of loops that might benefit from
its conciseness are still manually looping through named lets with
explicit tail calls! Too see how much it's hard to bring new idioms
into old languages...
I'd say pattern matching is not part of Lisp/Scheme culture, it's
something from foreign and hippie languages. That must change.
Scheme must grow. Getting structured datatypes in the form of records
into the language standard some 30 years after Pascal is good, but we
need more. In particular, more from nowadays current practice.
Ok, not by piling feature on top of feature: the core language
remains the same, but at least the standard lib could receive a slight
boost. :)
> Maybe I'm wrong about syntax-case, but you get my point about not
> bogging-down the standard.
Yes, certainly. That way the next RNRS may be just a lot of arguing
over bug fixing R6RS's records and modules. While most people will
still manually unpack list parameters with the half-century-old car,
cdr and company...
Marek Kubica
namekuseijin <nameku...@gmail.com> wrote:
> On May 13, 11:19 am, Derick Eddington <derick.edding...@gmail.com>
> wrote:
> > What we need, and have with R6RS (flaws and all), is a standard for
> > portable libraries. Then anybody can make a seriously professional
> > and portable matcher which might become the de-facto "standard" one.
>
> Yes, and I hope one is ready for inclusion in R7RS, like some boost
> libs are getting into C++ upcoming new standard.
That is IMO quite a good way. If a quasi-standard matcher will emerge
that most people can accept it could be added to the language, but not
before.
regards,
Marek
Aaron W. Hsu
>There's a more subtle but stronger difference I guess: since it's not
>a part of the core libs, like let or cond, it's usefulness is not
>readily available and many people coming into Scheme are not even
>aware of it as an external lib or even what it is all about. Heck,
>"do" is pretty useful and yet lots of loops that might benefit from
>its conciseness are still manually looping through named lets with
>explicit tail calls! Too see how much it's hard to bring new idioms
>into old languages...
>I'd say pattern matching is not part of Lisp/Scheme culture, it's
>something from foreign and hippie languages. That must change.
>Scheme must grow. Getting structured datatypes in the form of records
>into the language standard some 30 years after Pascal is good, but we
>need more. In particular, more from nowadays current practice.
>Ok, not by piling feature on top of feature: the core language
>remains the same, but at least the standard lib could receive a slight
>boost. :)
Right now it is hard to find out about non-standard libraries.
However, if it were easier to find out about other libraries, or
all these libraries were cross-referenced, one might not need a
true standard lib, but might have a very large set of de facto
standard libs that are easily searchable. SRFIs are one example, but
there are others, and...mabye we can unify this. :-)
--
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))) ++++++++++++++
Grant Rettke
> Right now it is hard to find out about non-standard libraries.
> However, if it were easier to find out about other libraries, or
> all these libraries were cross-referenced, one might not need a
> true standard lib, but might have a very large set of de facto
> standard libs that are easily searchable. SRFIs are one example, but
> there are others, and...mabye we can unify this. :-)
I wonder if someone was already working on this... :)
Lynn Winebarger
> There's a more subtle but stronger difference I guess: since it's not
> a part of the core libs, like let or cond, it's usefulness is not
> readily available and many people coming into Scheme are not even
> aware of it as an external lib or even what it is all about. Heck,
> "do" is pretty useful and yet lots of loops that might benefit from
> its conciseness are still manually looping through named lets with
> explicit tail calls! Too see how much it's hard to bring new idioms
> into old languages...
I'm pretty sure "do" as a general language construct predates named
let and tail recursion as language constructs.
And I think the "conciseness" of the do construct is optimization in
the wrong dimension, but unfortunately I can't give a better
characterization of what I mean.
Lynn
namekuseijin
> On May 13, 2:31 pm, namekuseijin <namekusei...@gmail.com> wrote:
> > "do" is pretty useful and yet lots of loops that might benefit from
> > its conciseness are still manually looping through named lets with
> > explicit tail calls! Too see how much it's hard to bring new idioms
> > into old languages...
>
> I'm pretty sure "do" as a general language construct predates named
> let and tail recursion as language constructs.
oh! I thought it was merely a macro around named let in Scheme and
I'm sure Scheme had TCO from day 1. I know Lisp has a few do
constructs that may be older than Scheme itself...
> And I think the "conciseness" of the do construct is optimization in
> the wrong dimension, but unfortunately I can't give a better
> characterization of what I mean.
It's a very under-appreciated construct I guess. It expands on let's
binding list by putting the update expression for each binding right
next to it. And no need for (if endcond (begin endexp ...)) just
(endcond endexp ...)
I enjoy conciseness.
Aaron W. Hsu
Aaron W. Hsu
>On May 13, 10:18=A0pm, Lynn Winebarger <owine...@gmail.com> wrote:
>> On May 13, 2:31=A0pm, namekuseijin <namekusei...@gmail.com> wrote:
>> > "do" is pretty useful and yet lots of loops that might benefit from
>> > its conciseness are still manually looping through named lets with
>> > explicit tail calls! =A0Too see how much it's hard to bring new idioms
>> > into old languages...
>>
>> I'm pretty sure "do" as a general language construct predates named
>> let and tail recursion as language constructs.
>oh! I thought it was merely a macro around named let in Scheme and
>I'm sure Scheme had TCO from day 1. I know Lisp has a few do
>constructs that may be older than Scheme itself...
I was always under the impression that it was done to prove that it
could be done in Scheme, and that you didn't have to use named LETs all
the time.
>> And I think the "conciseness" of the do construct is optimization in
>> the wrong dimension, but unfortunately I can't give a better
>> characterization of what I mean.
>It's a very under-appreciated construct I guess. It expands on let's
>binding list by putting the update expression for each binding right
>next to it. And no need for (if endcond (begin endexp ...)) just
>(endcond endexp ...)
>I enjoy conciseness.
What looping macro do you use? I find DO isn't nearly as nice as
any of them out there, with my personal favorite being foof loop, since
it is easily extended.
namekuseijin
> namekuseijin <namekusei...@gmail.com> writes:
> >It's a very under-appreciated construct I guess. It expands on let's
> >binding list by putting the update expression for each binding right
> >next to it. And no need for (if endcond (begin endexp ...)) just
> >(endcond endexp ...)
> >I enjoy conciseness.
>
> What looping macro do you use?
I have my own idiomatic iterating functions. :)
When the loop is simple, do will, huh, do.
> I find DO isn't nearly as nice as
> any of them out there, with my personal favorite being foof loop, since
> it is easily extended.
I hope it's better than it sounds. foof is kinda stupid. :P
Aaron W. Hsu
>> I find DO isn't nearly as nice as
>> any of them out there, with my personal favorite being foof loop, since
>> it is easily extended.
>I hope it's better than it sounds. foof is kinda stupid. :P
Try it and see:
<http://mumble.net/~campbell/darcs/foof-loop/>
<http://mumble.net/~campbell/tmp/nested-foof-loop.scm>
<http://mumble.net/~campbell/tmp/nested-foof-loop.txt>
Grant Rettke
> What looping macro do you use? I find DO isn't nearly as nice as
> any of them out there, with my personal favorite being foof loop, since
> it is easily extended.
Do you have an R6RS module-ized version of foof loop?
rotty
Grant Rettke
> http://github.com/rotty/spells/blob/3b5af1608ad0778f95105924747bdf3eb...http://ironscheme.codeplex.com/SourceControl/changeset/view/27527#461574
>
> Regards, Rotty
Thank you Rotty!
Aaron W. Hsu
Yes, I do. It was just a quick hack though, and not a proper write.
I needed to quickly test some code on R6RS Schemes and I wrote a
very quick and dirty version for R6RS. If you want, I'll dig them
out and you can have a look.
Grant Rettke
> Yes, I do. It was just a quick hack though, and not a proper write.
> I needed to quickly test some code on R6RS Schemes and I wrote a
> very quick and dirty version for R6RS. If you want, I'll dig them
> out and you can have a look.
For now, no, thank you :).