unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: Ian Price <ianprice90@googlemail.com>
To: Mark H Weaver <mhw@netris.org>
Cc: guile-devel@gnu.org
Subject: Re: My Guile TODO list
Date: Sat, 10 Mar 2012 22:49:24 +0000	[thread overview]
Message-ID: <87k42s8423.fsf@Kagami.home> (raw)
In-Reply-To: <87zkbsur0l.fsf@netris.org> (Mark H. Weaver's message of "Wed, 07 Mar 2012 14:53:30 -0500")


Hi mark,

A lot of the stuff is pretty neat. I'm particularly interested in
changes regarding immutability, being a functional programming nut :)
I also greatly appreciate the work you have already done in improving
guile's numerics.

Like most people, I'll just pick a few to comment on

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

> * Improve the implementations of map, for-each, et al.
List processing is obviously very important, ideally when the native
compiler comes in we'll get some work in to reduce the number of
intermediate data structures built. It's been on my todo list, but I
don't know if/when I'd get around to it. 

> * catch and raise in terms of R7RS/R6RS exceptions/conditions
I'll look forward to that :)

> * Improve the hash function, and allow GOOPS objects et al to
>   declare their own custom hash function.
Andy says that there are better hash functions on master. It doesn't
IIRC cover all cases, but it's a start.

> * Improve the PRNG and its initializer
:)

> * Chunked encoding for web client
I had been putting this off, but I will do it.

> * Parser combinators a.l.a. Haskell
parcomb works fine for most cases. I don't think this is necessary to
implement, unless you want to...

> * Efficient purely-functional data structures,
>   like Chris Okasaki's Edison, for Guile
I've been working on this in my own time, on an as-needed basis. See
https://github.com/ijp/pfds/ . SamTH on #scheme recently pointed me to a
bunch of ones implemented for racket: ralists/fectors/etc. that I will
get around to adding.

> * Monad library?
I have a bunch of these already, mostly mimicking existing haskell
libraries. Generic operators are a bit of a pain, since you can't do a
generic return using GOOPS. This is motivating my experiments with
higher order modules.

> * Improve error messages and debugging
Always welcome.


Thanks for sharing.


-- 
Ian Price

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



  parent reply	other threads:[~2012-03-10 22:49 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-07 19:53 My Guile TODO list Mark H Weaver
2012-03-07 20:20 ` Andy Wingo
2012-03-09 19:01   ` Mark H Weaver
2012-03-07 20:26 ` David Kastrup
2012-03-07 22:31 ` Ludovic Courtès
2012-03-09 19:07   ` Mark H Weaver
2012-03-10 22:13     ` Ludovic Courtès
2012-03-09  8:29 ` Nala Ginrut
2012-03-09 14:53   ` Mark H Weaver
2012-03-10 22:49 ` Ian Price [this message]
2012-03-16 11:14   ` Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87k42s8423.fsf@Kagami.home \
    --to=ianprice90@googlemail.com \
    --cc=guile-devel@gnu.org \
    --cc=mhw@netris.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).