[ANN] guile-csv 0.0.1 released!

[ANN] guile-csv 0.0.1 released!

[Nala Ginrut]

hi folks!
Here is a CSV reader based on Andy's csv-reader.
And it's ready for guildhall.

https://github.com/NalaGinrut/guile-csv

----------code-----------------
(use-modules (csv))
(define my-csv-reader (make-csv-reader #:\,))
(call-with-input-file "file.csv" my-csv-reader)
----------end------------------

You may specify the delimiter to generate a reader.

PS: I'll call ijp to add it into the repo.

Re: [ANN] guile-csv 0.0.1 released!

[Mark H Weaver]

Nala Ginrut <nalaginrut@gmail.com> writes:
> Here is a CSV reader based on Andy's csv-reader.
> And it's ready for guildhall.
[...]
> PS: I'll call ijp to add it into the repo.

I haven't yet looked carefully at this code or its API, so this is no
judgement on you, but in general, I don't think we should follow the
model of "Hey, here's the first release of a library I just hacked up.
Please add it to Guildhall now."  That's how we ended up with an ice-9
directory that's full of bitrotted implementations of half-baked APIs.

I'd much rather follow the example of Shiro Kawai, who is very cautious
to experiment with new APIs at length before adding them to Gauche, and
the result is IMO a beautiful and consistent set of APIs.

Maybe we can find a good compromise position between these two extremes.

What do other people think?

      Mark

Re: [ANN] guile-csv 0.0.1 released!

[Ludovic Courtès]

Mark H Weaver <mhw@netris.org> skribis:

> I haven't yet looked carefully at this code or its API, so this is no
> judgement on you, but in general, I don't think we should follow the
> model of "Hey, here's the first release of a library I just hacked up.
> Please add it to Guildhall now."  That's how we ended up with an ice-9
> directory that's full of bitrotted implementations of half-baked APIs.
>
> I'd much rather follow the example of Shiro Kawai, who is very cautious
> to experiment with new APIs at length before adding them to Gauche, and
> the result is IMO a beautiful and consistent set of APIs.
>
> Maybe we can find a good compromise position between these two extremes.
>
> What do other people think?

Well, there can be several repositories.  Once there’s one at gnu.org,
it could have a lightweight review process, and host reasonably mature
code (the barrier to entry should be lower than that of Guile proper
IMO, but not too demanding.)

People are free to setup additional repositories with their own
policies.

Ludo’.

Re: [ANN] guile-csv 0.0.1 released!

[Noah Lavine]

[-- Attachment #1: Type: text/plain, Size: 1628 bytes --]

This has been said before, but I think the most important thing is for
people who are new to Guile to be able to see a list of "mature,
well-maintained" libraries (whatever that means), and tell the difference
between those and poorly-maintained or bitrotted libraries.

It would also be nice to have a place to store unmaintained code, because
people can still use it, but they should be clearly separate.

Noah



On Fri, Feb 8, 2013 at 11:26 AM, Ludovic Courtès <ludo@gnu.org> wrote:

> Mark H Weaver <mhw@netris.org> skribis:
>
> > I haven't yet looked carefully at this code or its API, so this is no
> > judgement on you, but in general, I don't think we should follow the
> > model of "Hey, here's the first release of a library I just hacked up.
> > Please add it to Guildhall now."  That's how we ended up with an ice-9
> > directory that's full of bitrotted implementations of half-baked APIs.
> >
> > I'd much rather follow the example of Shiro Kawai, who is very cautious
> > to experiment with new APIs at length before adding them to Gauche, and
> > the result is IMO a beautiful and consistent set of APIs.
> >
> > Maybe we can find a good compromise position between these two extremes.
> >
> > What do other people think?
>
> Well, there can be several repositories.  Once there’s one at gnu.org,
> it could have a lightweight review process, and host reasonably mature
> code (the barrier to entry should be lower than that of Guile proper
> IMO, but not too demanding.)
>
> People are free to setup additional repositories with their own
> policies.
>
> Ludo’.
>
>
>

[-- Attachment #2: Type: text/html, Size: 2245 bytes --]

Re: [ANN] guile-csv 0.0.1 released!

[Aleix Conchillo Flaqué]

On Fri, Feb 8, 2013 at 8:13 AM, Mark H Weaver <mhw@netris.org> wrote:
>
> I haven't yet looked carefully at this code or its API, so this is no
> judgement on you, but in general, I don't think we should follow the
> model of "Hey, here's the first release of a library I just hacked up.
> Please add it to Guildhall now."  That's how we ended up with an ice-9
> directory that's full of bitrotted implementations of half-baked APIs.
>
> I'd much rather follow the example of Shiro Kawai, who is very cautious
> to experiment with new APIs at length before adding them to Gauche, and
> the result is IMO a beautiful and consistent set of APIs.
>
> Maybe we can find a good compromise position between these two extremes.
>
> What do other people think?
>

I see this from the other side.

I am pretty new to Guile and I don't have much experience designing
Guile APIs, tending to two actually (which is close to zero).

But what I see is a lack of libraries that new users can use. So, in
my case, I just thought "hey, I want to get there but before I would
need  a library for such and such" and I started to write them. I am
pretty sure that people with more experience would have written a
different API.

However, I agree that newbies should put special attention to detail,
even more actually, to try to learn and do the best as they can. There
should be no excuses there.

But if there are no libraries, even if not perfectly designed, it's
going to be hard for others to use Guile. It's a vicious circle.

And if more people use Guile, they will eventually re-design some of
the old (bad designed) APIs when they gain more experience with it. I
guess this happens in other languages too. But, at least, there was
something where to start.

Aleix

Re: [ANN] guile-csv 0.0.1 released!

[Nala Ginrut]

On Fri, 2013-02-08 at 11:13 -0500, Mark H Weaver wrote:
> Nala Ginrut <nalaginrut@gmail.com> writes:
> > Here is a CSV reader based on Andy's csv-reader.
> > And it's ready for guildhall.
> [...]
> > PS: I'll call ijp to add it into the repo.
> 
> I haven't yet looked carefully at this code or its API, so this is no
> judgement on you, but in general, I don't think we should follow the
> model of "Hey, here's the first release of a library I just hacked up.
> Please add it to Guildhall now."  That's how we ended up with an ice-9
> directory that's full of bitrotted implementations of half-baked APIs.
> 
> I'd much rather follow the example of Shiro Kawai, who is very cautious
> to experiment with new APIs at length before adding them to Gauche, and
> the result is IMO a beautiful and consistent set of APIs.
> 
> Maybe we can find a good compromise position between these two extremes.
> 

What you concern about is the package evaluate policy, which has been
raised for a time:
http://lists.gnu.org/archive/html/guile-devel/2013-01/msg00047.html

IMO, it's improper to evaluate every packages very strictly. It's not
benefit for folks to contribute, neither for the guys who would say "I
just want to use the package simply, I don't care the quality since I'm
writing a quick prototype".
And what I've suggested is to classify the packages submitted: 
quality/freedom/maintainability/experimental or even toy

Maybe I'm too hurry to send 'package adding' request, I can build my own
repo rather than an official one. But seems it's good for raising
package evaluate policy topic again.

Anyway, thanks for reply ;-)

> What do other people think?
> 
>       Mark

Re: [ANN] guile-csv 0.0.1 released!

[Nala Ginrut]

On Fri, 2013-02-08 at 08:59 -0800, Aleix Conchillo Flaqué wrote:
> On Fri, Feb 8, 2013 at 8:13 AM, Mark H Weaver <mhw@netris.org> wrote:
> >
> > I haven't yet looked carefully at this code or its API, so this is no
> > judgement on you, but in general, I don't think we should follow the
> > model of "Hey, here's the first release of a library I just hacked up.
> > Please add it to Guildhall now."  That's how we ended up with an ice-9
> > directory that's full of bitrotted implementations of half-baked APIs.
> >
> > I'd much rather follow the example of Shiro Kawai, who is very cautious
> > to experiment with new APIs at length before adding them to Gauche, and
> > the result is IMO a beautiful and consistent set of APIs.
> >
> > Maybe we can find a good compromise position between these two extremes.
> >
> > What do other people think?
> >
> 
> I see this from the other side.
> 
> I am pretty new to Guile and I don't have much experience designing
> Guile APIs, tending to two actually (which is close to zero).
> 
> But what I see is a lack of libraries that new users can use. So, in
> my case, I just thought "hey, I want to get there but before I would
> need  a library for such and such" and I started to write them. I am
> pretty sure that people with more experience would have written a
> different API.
> 
> However, I agree that newbies should put special attention to detail,
> even more actually, to try to learn and do the best as they can. There
> should be no excuses there.
> 
> But if there are no libraries, even if not perfectly designed, it's
> going to be hard for others to use Guile. It's a vicious circle.
> 
> And if more people use Guile, they will eventually re-design some of
> the old (bad designed) APIs when they gain more experience with it. I
> guess this happens in other languages too. But, at least, there was
> something where to start.
> 

I have to choose Aleix's side this time. 
The fact is, if we don't put guile-json into the repo ASAP, "there'd be
at least two more new guile-json be written in the next year", actually
I just stop my guile-json when I see json in guildhall.
Every packages are not perfect, even if it's maintained 20 years. But if
we add the new packages without very strictly evaluate, people could
contribute based on a given start.

The bad situation could occur, if someone can't find json/csv module in
a short time, and it's not very hard to implement, they will reinvent
wheels. Or if it's very hard to implement, hey, why bother to use Guile,
let's choose Python/Ruby. Guile is interesting, but users need something
practical.

Too cautious about adding the half-baked packages would make the
language itself always be a half-baked one. In the long term, a package
will approximate to perfect if many users really need it. 

But Mark's idea is rational, so IMO the better solution is to classify
the packages, and if the submitter need to put their packages into
official quality repo, they'll face a very strictly evaluating
discussion.

What you guys think?
Thanks!

> Aleix

Re: [ANN] guile-csv 0.0.1 released!

[Ian Price]

Mark H Weaver <mhw@netris.org> writes:

> Nala Ginrut <nalaginrut@gmail.com> writes:
>> Here is a CSV reader based on Andy's csv-reader.
>> And it's ready for guildhall.
> [...]
>> PS: I'll call ijp to add it into the repo.
>
> I haven't yet looked carefully at this code or its API, so this is no
> judgement on you, but in general, I don't think we should follow the
> model of "Hey, here's the first release of a library I just hacked up.
> Please add it to Guildhall now."  That's how we ended up with an ice-9
> directory that's full of bitrotted implementations of half-baked APIs.

So, you're concerned about Guile obtaining a bad rep from what is in the
Guildhall? A fair point, since I'm stewarding my own repo, I should
really get that blame, but it is likely that it would fall on Guile.

Over time, when we get the "official one" set up, we could certainly set
up a vetting process or something for there, but as Ludovic says, there
is no reason there can't be multiple ones. One scummier than the other :P

To take elisp as an example, there are three common repositories:
ELPA[0], Marmalade[1] and Melpa[2]. ELPA is the official gnu one, it
requires copyright assignment (as far as I know), and is in some sense
the strictest. Marmalade is the community one, where people generally
would submit packages. Melpa builds packages from repos, and has
predictable consequences :)

A similar setup could work for Guile. Whether or now we require
copyright assignment, you could have a "ELPA" corresponding to invited
packages, and a "ijp's $0.99 bit store".

Actually, I've been thinking about this issue in a slightly different
context, and have previously suggested on irc the idea of a
"guile-batteries" meta-package,[3] (along the lines of the Haskell
Platform[4]), where we would have a large collection of "generally useful"
software packages crypto/networking/whatever that would have a "one
command install". This would require it's own vetting to make sure it
was including libraries not liable to break. In theory, it could then
just match up as a convenience for the vetted repo.

Now, having said all that, I think these concerns are a little
premature. The Guildhall situation is little different from what we have
now, where a well-meaning Guiler posts an announcement to here, or
guile-user. We don't vet them, and we've certainly had bad APIs posted
here before <names withheld for obvious reasons>.

I'm an optimist though: if we can find them, we can fix them, and it
seems to work okay in other languages.

0. http://elpa.gnu.org/
1. http://marmalade-repo.org/
2. http://melpa.milkbox.net/
3. What guile-lib could have been (could still be), but guile-lib also
   gives me that ice-9 vibe.
4. http://www.haskell.org/platform/
-- 
Ian Price -- shift-reset.com

"Programming is like pinball. The reward for doing it well is
the opportunity to do it again" - from "The Wizardy Compiled"