Re: [Chicken-users] egg documentation

[Ozzi]

> The whole point of the note on the wiki was that we need _one_ documentation
> system.  The current system sucks, because you keep switching interfaces.
> Say you're looking for some documentation, so you search using the wiki
> system.  However, the docs you're looking for happen to be written in eggdoc
> or the legacy HTML documentation.  Besides not being able to search these
> docs, when you visit them, you go to another site and you lose the
> navigational tools you get in the wiki.

Fair enough. I agree that one method would be best.

> Visually it's also confusing, because the three docs look different.  This
> last point might sound trivial, but I'm sure when a potential new user is
> browsing for a new scheme implementation, he's might get scared away just
> because he has no idea why some docs are on this site, some on that and why
> they look and act differently.  I know Chicken is a "hacker's scheme", but
> there's no point in alienating people.

This I agree with 100%. I still haven't figured out why Chicken seems to be 
spread across three different sites.

http://galinha.ucpel.tche.br
http://chicken.wiki.br
http://www.call-with-current-continuation.org/

> Why do you want to make a distinction?

The idea I was trying to get at was something like a "standard library" for 
Chicken. When I go to the "Eggs Unlimited" page right now, there are lots and 
lots of eggs, which is great, except there's no easy way to tell what's 
standard-issue Scheming and what's more exotic stuff.

It would be great if there were a set of eggs that were considered to be a 
standard part of Chicken, to help people who haven't been writing Scheme code 
for years get oriented. Python and Ruby have lots of standard functionality 
built in, but with Chicken you have to hunt down each egg you need. I think a 
standard library of sorts would help.

I also believe it would help to focus development. If a consensus could be 
reached as to what kind of functionality should be included in a reasonably 
complete standard library for a useful language, then we could easily go about 
implementing that functionality. A standard library would provide a smaller 
target than the current wide-open universe of eggs.

So these are my ideas, and I'll admit they probably don't have much to do with 
documentation per se, but that's just what happened to convince me to write them 
down.