Re: Wide strings
On Tue 27 Jan 2009 06:52, Mike Gran spk...@yahoo.com writes:
I said
(Though, such a scheme would force scm_take_locale_string to become
scm_take_iso88591_string.)
which is incorrect. Under the proposed scheme, scm_take_locale_string
would only be able to use that storage directly if it happened to be
ASCII or 8859-1.
Perhaps as part of this, we should add
scm_{from,take}_{ascii,iso88591,ucs32}_string. This would help greatly
when you know the format of data that you're writing to object code or
in C, but you don't know the locale of the user.
Andy
ps. Good luck! Having this problem looked at, with an eye to solutions,
makes me very happy :-))
--
http://wingolog.org/
Re: r6rs libraries
Hi Julian, On Mon 26 Jan 2009 01:27, Julian Graham jool...@gmail.com writes: Maybe some more advanced Schemers than I can shed some light on the following: Well, that's not me, but I'll join you in fumbling for a solution :-) The levels system is simply a numerical way of encapsulating this information, but the proper order of evaluation can also be inferred by inspecting the import- and export-specs of the libraries being loaded I think you're right, yes. I think that the approach that you describe has been called Implicit phasing by Ghuloum and Dybvig. They have a paper about it, Implicit phasing in R6RS libraries -- but I haven't been able to find it freely on the web. ACM fail. * R6RS says that a library's imports need to be visited/instantiated at the time the bindings they export are referenced. Why? As above, why can't they be visited/instantiated at the time the imports for the importing library are processed? I could not find the quote that you referred to here -- I think what I can tell (from 7.2): If any of a library’s definitions are referenced at phase 0 in the expanded form of a program, then an instance of the referenced library is created for phase 0 before the program’s definitions and expressions are evaluated. This rule applies transitively: if the expanded form of one library references at phase 0 an identifier from another library, then before the referencing library is instantiated at phase n, the referenced library must be instantiated at phase n. When an identifier is referenced at any phase n greater than 0, in contrast, then the defining library is instantiated at phase n at some unspecified time before the reference is evaluated. Similarly, when a macro keyword is referenced at phase n during the expansion of a library, then the defining library is visited at phase n at some unspecified time before the reference is evaluated. So what this says to me is that: (1) At phase 0, libraries that you need to run a /program/ are instantiated before the program is run. (2) At phase n 0, we do not specify when libraries are imported. Is there any noticeable difference to the user? Dunno, to me it sounds like a concession, that side effects from loading libraries occur before side effects from running a program; but that for meta-levels things are left unspecified. Or do you guys read R6RS 7.2 to mean that the side-effects of top-level expressions absolutely need to happen at a time determined by the import level? No. So, for some of your other questions here's section 7.5 of the rationale: 7.5. Instantiation and initialization Opinions vary on how libraries should be instantiated and initialized during the expansion and execution of library bodies, whether library instances should be distinguished across phases, and whether levels should be declared so that they constrain identifier uses to particular phases. As I read this, it means that at least PLT wanted the separate instantiation model, and Chez wanted single-instantiation, implicit phasing. This report therefore leaves considerable latitude to implementations, while attempting to provide enough guarantees to make portable libraries feasible. So from 7.2 of R6RS itself: An implementation may distinguish instances/visits of a library for different phases or to use an instance/visit at any phase as an instance/visit at any other phase. Which is to say, we allow single instantiation -- as Guile modules are. An implementation may further expand each library form with distinct visits of libraries in any phase and/or instances of libraries in phases above 0. Which is to say, we also allow the PLT model, explicitly. An implementation may create instances/visits of more libraries at more phases than required to satisfy references. This is an odd one. I suppose what it means is that if you need a macro from library A to expand library B, but you don't need library A at runtime, the spec allows library A to be /instantiated/ at runtime. When an identifier appears as an expression in a phase that is inconsistent with the identifier’s level, then an implementation may raise an exception either at expand time or run time, or it may allow the reference. So, furthermore, it seems that not only may library A be instantiated at runtime, /it may be in library B's import list as well/. This is what happens with Guile's current module semantics. Thus, a library whose meaning depends on whether the instances of a library are distinguished or shared across phases or library expansions may be unportable. Indeed, indeed. I understand that the authors of the reference implementation re-created a lot of machinery
pushed to master: extensibility to (ice-9 session)
Hi, I pushed the following patch to master. Is it OK to push to 1.8 as well? That way I could drop some modules from guile-lib, and make guile-lib depend on guile = 1.8.x. (Perhaps we can set up a list for patches that get pushed to Guile ?) Andy commit 4f7a0504aac215832e99290e31c9944795c5d206 Author: Andy Wingo wi...@pobox.com Date: Tue Jan 27 13:43:07 2009 +0100 merge in from guile-lib: add some extensibility to `help' * ice-9/session.scm (add-value-help-handler!) (remove-value-help-handler!, add-name-help-handler!) (remove-name-help-handler!): New public interfaces, to allow some basic extensibility of the help interface. Merged in from guile-lib's (scheme session). diff --git a/ice-9/session.scm b/ice-9/session.scm index 1c9f480..6971a78 100644 --- a/ice-9/session.scm +++ b/ice-9/session.scm @@ -20,12 +20,61 @@ :use-module (ice-9 documentation) :use-module (ice-9 regex) :use-module (ice-9 rdelim) - :export (help apropos apropos-internal apropos-fold - apropos-fold-accessible apropos-fold-exported apropos-fold-all - source arity system-module)) + :export (help + add-value-help-handler! remove-value-help-handler! + add-name-help-handler! remove-name-help-handler! + apropos apropos-internal apropos-fold apropos-fold-accessible + apropos-fold-exported apropos-fold-all source arity + system-module module-commentary)) +(define *value-help-handlers* '()) + +(define (add-value-help-handler! proc) + Adds a handler for performing `help' on a value. + +`proc' will be called as (PROC NAME VALUE). `proc' should return #t to +indicate that it has performed help, a string to override the default +object documentation, or #f to try the other handlers, potentially +falling back on the normal behavior for `help'. + (set! *value-help-handlers* (cons proc *value-help-handlers*))) + +(define (remove-value-help-handler! proc) + Removes a handler for performing `help' on a value. + +See the documentation for `add-value-help-handler' for more +information. + (set! *value-help-handlers* (delete! proc *value-help-handlers*))) + +(define (try-value-help name value) + (or-map (lambda (proc) (proc name value)) *value-help-handlers*)) + + +(define *name-help-handlers* '()) + +(define (add-name-help-handler! proc) + Adds a handler for performing `help' on a name. + +`proc' will be called with the unevaluated name as its argument. That is +to say, when the user calls `(help FOO)', the name is FOO, exactly as +the user types it. + +The return value of `proc' is as specified in +`add-value-help-handler!'. + (set! *name-help-handlers* (cons proc *name-help-handlers*))) + +(define (remove-name-help-handler! proc) + Removes a handler for performing `help' on a name. + +See the documentation for `add-name-help-handler' for more +information. + (set! *name-help-handlers* (delete! proc *name-help-handlers*))) + +(define (try-name-help name) + (or-map (lambda (proc) (proc name)) *name-help-handlers*)) + + ;;; Documentation ;;; (define help @@ -45,6 +94,10 @@ You don't seem to have regular expressions installed.\n)) type x (cond +;; User-specified +((try-name-help name) + = (lambda (x) (if (not (eq? x #t)) (display x + ;; SYMBOL ((symbol? name) (help-doc name @@ -60,10 +113,12 @@ You don't seem to have regular expressions installed.\n)) ((and (list? name) (= (length name) 2) (eq? (car name) 'unquote)) - (cond ((object-documentation - (local-eval (cadr name) env)) -= write-line) - (else (not-found 'documentation (cadr name) + (let ((value (local-eval (cadr name) env))) + (cond ((try-value-help (cadr name) value) + = noop) + ((object-documentation value) + = write-line) + (else (not-found 'documentation (cadr name)) ;; (quote SYMBOL) ((and (list? name) @@ -109,7 +164,8 @@ You don't seem to have regular expressions installed.\n)) (let ((entries (apropos-fold (lambda (module name object data) (cons (list module name -(object-documentation object) +(or (try-value-help name object) + (object-documentation object)) (cond ((closure? object) a procedure)
Re: Wide strings
Hi! Mike Gran spk...@yahoo.com writes: Gnulib works for me. Bruno is the maintainer of those funcs, so I'm sure they work great. Good! So really the first questions to answer are the encoding question and whether the R6RS string API is the goal. SRFI-1[34] (i.e., status quo in terms of supported APIs) seems like a reasonable milestone. For the former, I rather like the idea that internally a string will internally be encoded either as 4-byte chars of UTF-32 or 1-byte chars of ISO-8859-1. Since the first 256 chars of UTF-32 are ISO-8859-1, it makes it trivial for string-ref/set to work with codepoints. Good to know. That would give us O(1) ref/set!, and with Latin-1 special-cased, we'd have memory saving when interpreting Latin-1 code, which is good. (Though, such a scheme would force scm_take_locale_string to become scm_take_iso88591_string.) I think it would not *become* scm_take_iso88591_string, but scm_take_iso88591_string (and others, as Andy suggested) would *complement* it. Thanks, Ludo'.
Re: pushed to master: extensibility to (ice-9 session)
Hello, Andy Wingo wi...@pobox.com writes: I pushed the following patch to master. Is it OK to push to 1.8 as well? That way I could drop some modules from guile-lib, and make guile-lib depend on guile = 1.8.x. Looks OK to me. (Too bad this module isn't documented BTW.) Do you have example use cases? (Perhaps we can set up a list for patches that get pushed to Guile ?) Yes! A few remarks: +(define *value-help-handlers* '()) The convention within Guile is rather `%'-prefixed names for globals, as in `%load-path'. + (let ((value (local-eval (cadr name) env))) + (cond ((try-value-help (cadr name) value) + = noop) + ((object-documentation value) + = write-line) + (else (not-found 'documentation (cadr name)) Shouldn't `object-documentation' as a default value helper, as in: (define %value-help-handlers `(,(lambda (n v) (object-documentation v Thanks, Ludo'.
Re: guile unit test framework license
On 01/27/09 10:07:16, Andy Wingo wrote: Hi John, I was going over the licenses in Guile-lib, and realized we didn't really have a declamation of copyright or license to your goops-unit code. Your original message was here: http://article.gmane.org/gmane.lisp.guile.user/1728 Can you please reply to this message, copying guile-devel so this will be in the records, declaring that either: * Your code from that message is in the public domain; or * Your code from that message is under the LGPL version 2 or later. Other declamations are possible of course, but these would be the most useful to Guile :-) Cheers, Andy -- http://wingolog.org/ Glad to. *ahem* The goops-unit code posted by me, and archived at the location referenced by the above link (http://article.gmane.org/gmane.lisp.guile.user/1728) is hereby released under the LGPL version 2 or later. -John -- John Maxwell (j...@toad.net) Usenet: wisdom in homeopathic doses. -Paul Martin
Re: pushed to master: extensibility to (ice-9 session)
l...@gnu.org (Ludovic Courtès) writes: +(define *value-help-handlers* '()) The convention within Guile is rather `%'-prefixed names for globals, as in `%load-path'. I'm not sure about that. I interpret `%' as something to do with the system (e.g. when I was proposing %get-stack-depth). I would agree with the patch that *name* is the convention - if anything is - for global variables. Regards, Neil
Re: pushed to master: extensibility to (ice-9 session)
Andy Wingo wi...@pobox.com writes: Hi, I pushed the following patch to master. Is it OK to push to 1.8 as well? That way I could drop some modules from guile-lib, and make guile-lib depend on guile = 1.8.x. I have no objection to that. (Perhaps we can set up a list for patches that get pushed to Guile ?) Not sure I understand... Anything like guile-sources, which we already have? :use-module (ice-9 rdelim) - :export (help apropos apropos-internal apropos-fold -apropos-fold-accessible apropos-fold-exported apropos-fold-all -source arity system-module)) + :export (help + add-value-help-handler! remove-value-help-handler! + add-name-help-handler! remove-name-help-handler! + apropos apropos-internal apropos-fold apropos-fold-accessible + apropos-fold-exported apropos-fold-all source arity + system-module module-commentary)) Also say something in the commit about exporting module-commentary ? +`proc' will be called as (PROC NAME VALUE). `proc' should return #t to +indicate that it has performed help, a string to override the default +object documentation, or #f to try the other handlers, potentially +falling back on the normal behavior for `help'. +The return value of `proc' is as specified in +`add-value-help-handler!'. I'd prefer to repeat what it said in add-value-help-handler!, so that this doc stands alone. (It would be quite ironic if a procedure for extending the `help' system doesn't have completely useful `help' itself.) + (set! *name-help-handlers* (cons proc *name-help-handlers*))) + +(define (remove-name-help-handler! proc) + Removes a handler for performing `help' on a name. + +See the documentation for `add-name-help-handler' for more +information. What is the point of that last sentence? I suspect nothing, so recommend removing it. (And same for remove-value-help-handler!) - (cond ((object-documentation - (local-eval (cadr name) env)) -= write-line) - (else (not-found 'documentation (cadr name) + (let ((value (local-eval (cadr name) env))) + (cond ((try-value-help (cadr name) value) + = noop) + ((object-documentation value) + = write-line) + (else (not-found 'documentation (cadr name)) Why noop here? Won't that discard the documentation? Regards, Neil
Re: pushed to master: extensibility to (ice-9 session)
Hi Neil, Neil Jerram n...@ossau.uklinux.net writes: l...@gnu.org (Ludovic Courtès) writes: The convention within Guile is rather `%'-prefixed names for globals, as in `%load-path'. I'm not sure about that. I interpret `%' as something to do with the system (e.g. when I was proposing %get-stack-depth). Hmm, good point. I would agree with the patch that *name* is the convention - if anything is - for global variables. Fine by me, then! Ludo'.
guile-1.8.6: libguile/inline.h nitpick
Hi all, Minor nit about the libguile/inline.h header: I typically compile with g++ ... -Wundef -Werror, which catches uses of undefined preprocessor tokens: /usr/local/include/libguile/inline.h:57:31: __APPLE_CC__ is not defined In file included from /usr/local/include/libguile.h:114, /usr/local/include/libguile/inline.h:57:31: __APPLE_CC__ is not defined __APPLE_CC__ is only defined for Apple, which is causing my compiles to fail (didn't used to fail with older guile.) Can we change line 57 from: # if (defined __GNUC__) (!(__APPLE_CC__ 5400 __STDC_VERSION__ = 199901L to something like: # if (defined __GNUC__) (!((defined __APPLE_CC__) __APPLE_CC__ 5400 __STDC_VERSION__ = 199901L which checks for __APPLE_CC__ defined before using it? Thanks. Fang David Fang http://www.csl.cornell.edu/~fang/ http://www.achronix.com/
Re: pushed to master: extensibility to (ice-9 session)
Neil Jerram n...@ossau.uklinux.net writes: l...@gnu.org (Ludovic Courtès) writes: +(define *value-help-handlers* '()) The convention within Guile is rather `%'-prefixed names for globals, as in `%load-path'. I'm not sure about that. I interpret `%' as something to do with the system (e.g. when I was proposing %get-stack-depth). I would agree with the patch that *name* is the convention - if anything is - for global variables. *FOO* to me implies that it is a fluid (as the *FOO* tradition comes from Common Lisp where it is used to mark dynamically scoped variables). Unadorned `value-help-handlers' seems more in line with Scheme style for a global lexical variable. -- No, there's nothing here about X, so be quiet.
