Re: My Guile TODO list
Hi Ian, Ian Price skribis: > 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. Adding more functional data structures into Guile core is definitely a worthy goal IMO, so we should draw from your work! Thanks, Ludo’.
Re: My Guile TODO list
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 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"
Re: My Guile TODO list
Hi, Mark H Weaver skribis: > l...@gnu.org (Ludovic Courtès) writes: >> Mark H Weaver skribis: [...] >>> * FFI overhaul >>>* Native code generation where possible, else generated C code >> >> For ‘pointer->procedure’, we could use GNU lightning to generate subrs, >> which would save us from the need to go through ‘foreign-call’. > > If someone wants to work on this, I'd be glad, but personally I'm not > interested in integrating GNU lightning. This TODO list item assumed > that we'd first have our own native compiler, even though I forgot to > put "native compiler" on the list. Oh, OK. I was too short-term-minded, I guess. :-) >> This would make things equivalent to hand-written subrs in terms of >> performance. I’m not sure it’s crucial, though. > > A faster FFI would enable us to use it for many more things, including > for frequently-called procedures where performance is crucial (such as > GMP or libunistring) Indeed. Thanks, Ludo’.
Re: My Guile TODO list
Hi Ludovic, l...@gnu.org (Ludovic Courtès) writes: > Mark H Weaver skribis: > >> I occasionally talk about my large Guile TODO list, and sometimes people >> say that I should put it somewhere public. Okay, here it is (not >> including my ticked messages in Gnus). It includes some items that are >> probably controversial, especially near the end, > > Obviously I stopped reading here and hit C-M->. :-) LOL :) > I’ll just pick one item: > >> * FFI overhaul >>* Native code generation where possible, else generated C code > > For ‘pointer->procedure’, we could use GNU lightning to generate subrs, > which would save us from the need to go through ‘foreign-call’. If someone wants to work on this, I'd be glad, but personally I'm not interested in integrating GNU lightning. This TODO list item assumed that we'd first have our own native compiler, even though I forgot to put "native compiler" on the list. > This would make things equivalent to hand-written subrs in terms of > performance. I’m not sure it’s crucial, though. A faster FFI would enable us to use it for many more things, including for frequently-called procedures where performance is crucial (such as GMP or libunistring), but I think it can wait until we have our own native compiler. Thanks, Mark
Re: My Guile TODO list
Hi Andy, Andy Wingo writes: > On Wed 07 Mar 2012 20:53, Mark H Weaver writes: > >> I occasionally talk about my large Guile TODO list, and sometimes people >> say that I should put it somewhere public. Okay, here it is (not >> including my ticked messages in Gnus). It includes some items that are >> probably controversial, especially near the end, and I'd rather not get >> stuck in huge threads about those ideas right now, so please just take >> this for what it is: a place where I record tentative ideas so they >> won't be forgotten. Honestly, I'll be lucky if I find time to do a >> small fraction of this stuff :) > > IMO it's a really great list for Guile itself. There were very few > things that I would comment on, but they are all small points, and > anyway, there's no need to nitpick such a generosity as this list :) > > If I were to add one point from my side, it would be native compilation. > I think it's what we need to take Guile to the next level of > expressiveness, speed, and good memory use. I think we should probably > tackle the register VM first, though, along with using ELF as the format > for bytecompiled Scheme, allowing static, shareable access to > constants. That would also produce more compact code, as debugging data > would move to a separate section. I agree. "Native compilation" is such an obvious goal that I forgot to put it on the list, but I think about it almost every day. Some of the items near the end of my TODO list implicitly assume that native compilation will be implemented first. Thanks, Mark
Re: My Guile TODO list
Nala Ginrut writes: > well, I think the real worth of this TODO list is, I don't bother to > think what can I do for Guile. I can steal some of them and go for it > before you done it. ;-) Please do! Unless others help with this list, there is little hope that it can all be done. I see you are already started with Sweet Expressions; good! :) Mark
Re: My Guile TODO list
well, I think the real worth of this TODO list is, I don't bother to think
what can I do for Guile. I can steal some of them and go for it before you
done it. ;-)
On Thu, Mar 8, 2012 at 3:53 AM, Mark H Weaver wrote:
> Hello all,
>
> I occasionally talk about my large Guile TODO list, and sometimes people
> say that I should put it somewhere public. Okay, here it is (not
> including my ticked messages in Gnus). It includes some items that are
> probably controversial, especially near the end, and I'd rather not get
> stuck in huge threads about those ideas right now, so please just take
> this for what it is: a place where I record tentative ideas so they
> won't be forgotten. Honestly, I'll be lucky if I find time to do a
> small fraction of this stuff :)
>
>Best,
> Mark
>
>
> Guile TODO
> ==
>
> * Refactor pending numerics patches (Improved rationals et al)
> (This will help Neils Möller with his minigmp project.)
>
> * Get rid of all of those 'resolve-module' and 'resolve-interface' calls
> in hot procedures of (language elisp runtime)! (master)
>
> * Optimize important elisp primitives (master)
>
> * VM instruction to lisp canonicalize (#f or '() => #nil) ?
>
> * How to modularize libunicode?
>
> * Fix the warning system
>
> * Add call/ec to stable-2.0
>
> * Make call/ec as fast as possible in master (VM instruction?)
>
> * Allow the ,d REPL command to work for syntactic keywords
>
> * Improve (ice-9 match) documentation.
>
> * [SUBMITTED] Faster gensym: postpone giving it a name until requested.
>
> * Optimize exact-integer-sqrt: use floating-point for integers less than
> 2^53 (I learned that this is reliable from Shiro Kawai of Gauche)
> (Related idea: use floating-point for some larger subset of the
> rationals. When is it safe to trust the result?)
>
> * Improve the implementations of map, for-each, et al.
>
> * How to modularize the numerics code?
> * How to implement the numerics operation dispatchers?
> Best answer: Use GOOPS + FFI for GMP/MPFR/MPC; if not fast, fix it.
> Practical answer: ?
>
> * Look into this:
> UNRESOLVED: r6rs-arithmetic-fixnums.test: fx+/carry: simple
> UNRESOLVED: r6rs-arithmetic-fixnums.test: fx-/carry: simple
> UNRESOLVED: r6rs-arithmetic-fixnums.test: fx*/carry: simple
>
> * R7RS compliance
> * optional ellipsis specifier for syntax-rules et al
> * 'syntax-error'
> * define-values
> * let-values and let*-values (without loading SRFI-11)
> * include-ci
> * bytevectors in core R7RS
> * lazy and eager (without loading SRFI-45)
> * |...| symbol notation, and \xXX within symbols
> * support #\escape and "\escape"
> * support \x in string literals
> * allow whitespace between \ and newline in string literals
> * #!fold-case and #!no-fold-case
> * #true and #false
> * datum labels for circular and shared substructures
> * nan? and finite? now accept complex numbers
> (should probably change inf? and infinite? as well)
> * exact-integer?
> * R7RS exceptions
> * make sure define-record-type is R7RS compliant
> * optional third parameter to 'member' and 'assoc'
> * define-library
> * digit-value
> * char-foldcase
> * string-ni=? et al
> * vector->string and string->vector
> * vector-copy supports optional (start end fill) args
> * vector-fill! supports optional (start end) args
> * bytevector-copy! with 3 args
> * bytevector-copy-partial{,!}
> * write bytevectors with #u8 (and elements in hex) by default?
> * {map,for-each} stops when shortest list runs out
> * string-{map,for-each} accepts multiple strings
> * vector-{map,for-each}
> * make sure {map,vector-map,string-map} are multi-return safe
> * {scheme-report,null}-environment for R7RS
> * 'environment'
> * 'port-open?'
> * R7RS binary ports and bytevector ports
> * {textual,binary}-port?
> * open-binary-{input,output}-file
> * open-{input,output}-bytevector
> * get-output-bytevector
> * {read,peek,write}-u8, u8-ready?
> * read-bytevector{,!}
> * write-bytevector
> * write-partial-bytevector
> * read-line
> * write-simple
> * flush-output-port
> * load with optional 'environment specifier' as second argument
> * get-environment-variable{,s}
> * current-{second,jiffy}, jiffies-per-second
> * R7RS feature identifiers: r7rs, exact-closed, ratios, exact-complex,
> ieee-float, full-unicode, windows, posix, unix, darwin, linux, bsd,
> freebsd, solaris, i386, x86-64, ppc, sparc, jvm, clr, llvm, ilp32,
> lp64, ilp64, big-endian, little-endian, guile, guile-2, guile-2.0
>
> * catch and raise in terms of R7RS/R6RS exceptions/conditions
>
> * compile-time dependency tracking for .go files
>
> * Good implementation of empty case-lambdas
>
> * Track down bytevector test failures reported by Hans Aberg
>
> * Add test cases:
>string mutation test case (segfaults on earlier versions)
>attempt to mutate empty range of immutable string
>narrow subs
Re: My Guile TODO list
Hi Mark! Mark H Weaver skribis: > I occasionally talk about my large Guile TODO list, and sometimes people > say that I should put it somewhere public. Okay, here it is (not > including my ticked messages in Gnus). It includes some items that are > probably controversial, especially near the end, Obviously I stopped reading here and hit C-M->. :-) I’ll just pick one item: > * FFI overhaul >* Native code generation where possible, else generated C code For ‘pointer->procedure’, we could use GNU lightning to generate subrs, which would save us from the need to go through ‘foreign-call’. This would make things equivalent to hand-written subrs in terms of performance. I’m not sure it’s crucial, though. Thanks, Ludo’.
Re: My Guile TODO list
Mark H Weaver writes: > Hello all, > > I occasionally talk about my large Guile TODO list, and sometimes people > say that I should put it somewhere public. Okay, here it is (not > including my ticked messages in Gnus). Were you planning to do anything on the seventh day? -- David Kastrup
Re: My Guile TODO list
On Wed 07 Mar 2012 20:53, Mark H Weaver writes: > I occasionally talk about my large Guile TODO list, and sometimes people > say that I should put it somewhere public. Okay, here it is (not > including my ticked messages in Gnus). It includes some items that are > probably controversial, especially near the end, and I'd rather not get > stuck in huge threads about those ideas right now, so please just take > this for what it is: a place where I record tentative ideas so they > won't be forgotten. Honestly, I'll be lucky if I find time to do a > small fraction of this stuff :) IMO it's a really great list for Guile itself. There were very few things that I would comment on, but they are all small points, and anyway, there's no need to nitpick such a generosity as this list :) If I were to add one point from my side, it would be native compilation. I think it's what we need to take Guile to the next level of expressiveness, speed, and good memory use. I think we should probably tackle the register VM first, though, along with using ELF as the format for bytecompiled Scheme, allowing static, shareable access to constants. That would also produce more compact code, as debugging data would move to a separate section. Anyway, thanks for sharing :-) Andy -- http://wingolog.org/
My Guile TODO list
Hello all,
I occasionally talk about my large Guile TODO list, and sometimes people
say that I should put it somewhere public. Okay, here it is (not
including my ticked messages in Gnus). It includes some items that are
probably controversial, especially near the end, and I'd rather not get
stuck in huge threads about those ideas right now, so please just take
this for what it is: a place where I record tentative ideas so they
won't be forgotten. Honestly, I'll be lucky if I find time to do a
small fraction of this stuff :)
Best,
Mark
Guile TODO
==
* Refactor pending numerics patches (Improved rationals et al)
(This will help Neils Möller with his minigmp project.)
* Get rid of all of those 'resolve-module' and 'resolve-interface' calls
in hot procedures of (language elisp runtime)! (master)
* Optimize important elisp primitives (master)
* VM instruction to lisp canonicalize (#f or '() => #nil) ?
* How to modularize libunicode?
* Fix the warning system
* Add call/ec to stable-2.0
* Make call/ec as fast as possible in master (VM instruction?)
* Allow the ,d REPL command to work for syntactic keywords
* Improve (ice-9 match) documentation.
* [SUBMITTED] Faster gensym: postpone giving it a name until requested.
* Optimize exact-integer-sqrt: use floating-point for integers less than
2^53 (I learned that this is reliable from Shiro Kawai of Gauche)
(Related idea: use floating-point for some larger subset of the
rationals. When is it safe to trust the result?)
* Improve the implementations of map, for-each, et al.
* How to modularize the numerics code?
* How to implement the numerics operation dispatchers?
Best answer: Use GOOPS + FFI for GMP/MPFR/MPC; if not fast, fix it.
Practical answer: ?
* Look into this:
UNRESOLVED: r6rs-arithmetic-fixnums.test: fx+/carry: simple
UNRESOLVED: r6rs-arithmetic-fixnums.test: fx-/carry: simple
UNRESOLVED: r6rs-arithmetic-fixnums.test: fx*/carry: simple
* R7RS compliance
* optional ellipsis specifier for syntax-rules et al
* 'syntax-error'
* define-values
* let-values and let*-values (without loading SRFI-11)
* include-ci
* bytevectors in core R7RS
* lazy and eager (without loading SRFI-45)
* |...| symbol notation, and \xXX within symbols
* support #\escape and "\escape"
* support \x in string literals
* allow whitespace between \ and newline in string literals
* #!fold-case and #!no-fold-case
* #true and #false
* datum labels for circular and shared substructures
* nan? and finite? now accept complex numbers
(should probably change inf? and infinite? as well)
* exact-integer?
* R7RS exceptions
* make sure define-record-type is R7RS compliant
* optional third parameter to 'member' and 'assoc'
* define-library
* digit-value
* char-foldcase
* string-ni=? et al
* vector->string and string->vector
* vector-copy supports optional (start end fill) args
* vector-fill! supports optional (start end) args
* bytevector-copy! with 3 args
* bytevector-copy-partial{,!}
* write bytevectors with #u8 (and elements in hex) by default?
* {map,for-each} stops when shortest list runs out
* string-{map,for-each} accepts multiple strings
* vector-{map,for-each}
* make sure {map,vector-map,string-map} are multi-return safe
* {scheme-report,null}-environment for R7RS
* 'environment'
* 'port-open?'
* R7RS binary ports and bytevector ports
* {textual,binary}-port?
* open-binary-{input,output}-file
* open-{input,output}-bytevector
* get-output-bytevector
* {read,peek,write}-u8, u8-ready?
* read-bytevector{,!}
* write-bytevector
* write-partial-bytevector
* read-line
* write-simple
* flush-output-port
* load with optional 'environment specifier' as second argument
* get-environment-variable{,s}
* current-{second,jiffy}, jiffies-per-second
* R7RS feature identifiers: r7rs, exact-closed, ratios, exact-complex,
ieee-float, full-unicode, windows, posix, unix, darwin, linux, bsd,
freebsd, solaris, i386, x86-64, ppc, sparc, jvm, clr, llvm, ilp32,
lp64, ilp64, big-endian, little-endian, guile, guile-2, guile-2.0
* catch and raise in terms of R7RS/R6RS exceptions/conditions
* compile-time dependency tracking for .go files
* Good implementation of empty case-lambdas
* Track down bytevector test failures reported by Hans Aberg
* Add test cases:
string mutation test case (segfaults on earlier versions)
attempt to mutate empty range of immutable string
narrow substring of wide string should be narrow
empty substring should not hold reference to original stringbuf
newly allocated empty strings share a common null stringbuf
make sure multiple copies of the empty string are distinct
from C
from Scheme
* Improve the hash function, and allow GOOPS objects et al to
declare their own custom hash function.
* Improve th
