Re: Tangerine Edition penultimate report: how I voted, how you're voting

g practice. R7RS-large is the same - but much more so. -- --Per Bothner p...@bothner.com http://per.bothner.com/

Re: inexact->exact in 1.7.1

.2 fixes this Why do you think there is a bug? -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/ ___ Guile-user mailing list Guile-user@gnu.org http://lists.gnu.org/mailman/listinfo/guile-user

Re: emacs+guile

he "actually usable" stage, and there is probably some "bit-rotting". However, I have started doing some *very* interesting GUI programming with Kawa, which looks like it will also benefit JEmacs. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/ ___

Re: emacs+guile

support multiple threads (or futures) and have bindings be inherited from a parent thread to a child thread. See http://www.gnu.org/software/kawa/Parameter-objects.html -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/ ___ Guile-use

Re: values->list elements

uery's FLOWR expressions) or "blocks" (bodies in Scheme). In Kawa XQuery sequence and Scheme multiple values are implemented the same way. Articles where I explore / ramble on this idea: http://www.gnu.org/software/kawa/q2/ http://per.bothner.com/papers/LispXML04/index.ht

Re: values->list elements

Jon Wilson wrote: This can be found here: http://www.dreamsongs.com/NewFiles/HOPL2-Uncut.pdf > I'm not sure what HOPL stands for, though. History of Programming Languages, IIRC. -- --Per Bothner [EMAIL PROTECTED] http://per.bot

Re: minimalist guile

Jon Wilson wrote: In fact, IIRC, Common Lisp was the first language in which OOP was ever implemented. OOP predates Common Lisp by quite a bit. The first object-oriented programming *language* is generally considered to be Simula67. -- --Per Bothner [EMAIL PROTECTED] http

Re: Reverting eqv? behavior for signed zeros and nans to 1.6 semantics

> | From: Marius Vollmer <[EMAIL PROTECTED]> > | Specifically, 'eqv?' would be changed to return '#t' when comparing > | negative and positive zero: > | > | (eqv? 0.0 -0.0) => #t I missed the explanation for why this might be desirable. I don't think it is the Right Thing. Arguments from

Re: srfi 64 vs guile.

uot;) FAIL # of expected passes 2 # of unexpected failures 1 Oops. My fault. Please try the attached patch. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/ Index: testing.scm === --- testing.scm (revision 5381

Re: How could this be implemented?

e ... This is the hard part: what does "that we can see" mean? You might fix this interesting: http://per.bothner.com/software/#Q and specifically: http://per.bothner.com/software/Q/Qshell.html http://home.pacbell.net/bothner/Qman.html#SEC64 -- --Per Bothner [EMAIL PROTECT

Re: How could this be implemented?

Jon Wilson wrote: Per Bothner wrote: You really have to treat ls as a macro, which is resolved at compile-time. Otherwise, it becomes near-impossible to compile name-lookup efficiently. And if you can't compile it, it's a toy. Bash script is not compiled, but it is quite useful.

Re: Loading modules.

Yes, I admit I haven't done much testing of srfi-64 on Guile. If you send me patches, I'll have the reference implementation updated. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/ ___ Guile-user mailing lis

Re: SRFI-64 implementation for Guile 2.0

implementations, even when using cond-expand, though not on Kawa. One option is for the Guile port to contain the define-module in a separate file, which does an include on (a suitably enhanced) version of the portable implementation. (I assume Guild has include or something similar.) -- --Per

Re: SRFI-64 implementation for Guile 2.0

7 expected-value: 7 Test begin: source-file: "/dev/stdin" source-line: 7 source-form: (test-eqv 8 (vector-ref v 2)) Test end: result-kind: fail actual-value: 7 expected-value: 8 Group end: vec-test # of expected passes 3 # of unexpected failures 1 Also the FAIL printed to stderr lists the file and line number: |kawa:7|# (test-eqv 8 (vector-ref v 2)) /dev/stdin:7: FAIL -- --Per Bothner p...@bothner.com http://per.bothner.com/

Re: SRFI-64 implementation for Guile 2.0

ore function y because of z". And what is the problem with the "style"? A module issue? I made a few snall fixes in 2007 to testing.scm which I guess I forgot to get uploaded to srfi,schemers,org. I've attached it. -- --Per Bothner p...@bothner.com http

Re: SRFI-64 implementation for Guile 2.0

p://sourceware.org/viewvc/kawa/trunk/gnu/kawa/slib/testing.scm?view=co It may be easier to create a patch if you check out the Kawa sources - see this link for instructions http://www.gnu.org/software/kawa/Getting-Kawa.html -- --Per Bothner p...@bothner.com http://per.bothner.com/