* Infix syntax @ 2002-10-03 11:26 Daniel Skarda 2002-10-05 8:55 ` Neil Jerram 0 siblings, 1 reply; 31+ messages in thread From: Daniel Skarda @ 2002-10-03 11:26 UTC (permalink / raw) Hello, I suppose, that all Guile users on this list are used to special lisp syntax and are happy with it as I am. Though sometimes it is somewhat awkward to convert mathematical expressions to prefix syntax. I revived my module infix.scm, which enrich Guile syntax with expressions. The module was part of cursed gettext patch. While ago I rewrote the module and removed dependencies on poor gettext patch. To take an advantage of infix syntax, (use-module (ice-9 infix)) and call (activate-infix). For infix grammar activation I chose read-hash-extend and square brackets: #[1 + 2 * 3] => 7 Have a nice day, 0. ;--- ice-9/infix.scm ------------------------------------------------ (define-module (ice-9 infix) :use-module (ice-9 optargs)) ; This module adds to Guile simple parser of infix (C-like) ; expressions. Parser is quite simple - you have to keep in mind that ; all operators are scheme symbols - you should write spaces around ; them to separate them from numbers and other symbols (variables, ; "function" names etc). ; ; '[', ']' and ',' act as separators - these are exceptions handled ; by infix parser. ; ; Also note that parser handles C-like expressions, not statements! ; Semicolon ';' start comments ; Examples: ; ; #[ 1 + 2 * 3 ] ; -=> 7 ; ; #[ (1 + 2) * 3 ] ; -=> 9 ; ; #[ cos (PI) ] ; -=> -1 ; ; #[2 ^ 3 ^ 4] ; -=> 2417851639229258349412352 ; ; #[(2 ^ 3) ^ 4 ] ; -=> 4096 ; ; #[6 / 3 / 2] ; -=> 1 ; ; #[6 / (3 / 2)] ; -=> 4 ; ; #[sin(1) ^ 2 + cos(1) * cos(1)] ; -=> 1 ; ; #[ string-length("foo") ] ; -=> 3 ; ; #[ modulo(5, 3) ] ; -=> 2 ; ; (vector-ref a 12) ; -=> 12 ; ; #[ a[12]^(a[12] - 10) ] ; ; #[a[12] < 13 && ! (25 * 0 > 1)] ; -=> #t ; ;--- utils ... -------------------------------------------------------- (define (remove-if-not pred? l) (do ((l l (cdr l)) (r '() (if (pred? (car l)) (cons (car l) r) r))) ((null? l) (reverse! r)))) (define (sloppy-min . lst) (let ((nlst (remove-if-not number? lst))) (and (pair? nlst) (apply min nlst)))) ;--- Simple tokenizer ... --------------------------------------------- (define (make-read-tokenizer port) (define (get-token) (let ((ch (read-char port))) (cond ((eof-object? ch) the-eof-object) ((char-whitespace? ch) (get-token)) ((memq ch '(#\( #\) #\[ #\] #\,)) ch) ((eq? ch #\;) (%read-line) (get-token)) (else (unread-char ch port) (let ((sym (read port))) (if (symbol? sym) (let ((str (symbol->string sym))) (cond ((sloppy-min (string-index str #\,) (string-index str #\[) (string-index str #\])) => (lambda (idx) (let ((sub (substring str 0 idx))) (unread-string (substring str idx) port) (or (string->number sub) (string->symbol sub))))) (else sym))) sym)))))) get-token) ;---- utils ... ------------------------------------------------------- (define (char-rparen? x) (eq? x #\))) (define (char-rbracket? x) (eq? x #\])) (define-public (helper-nth o n) (cond ((vector? o) (vector-ref o n)) ((pair? o) (list-ref o n)) ((string? o) (string-ref o n)) (else (error "Do not know how to handle [] operator")))) ;---- definitions ... ------------------------------------------------- (define infix-ops (make-vector 11)) (define infix-func (make-vector 11)) (define infix-right (make-vector 11)) (define* (add-infix-operator name priority #:key right func) (hashq-set! infix-ops name priority) (if right (hashq-set! infix-right name #t)) (if func (hashq-set! infix-func name func))) (define prefix-ops (make-vector 11)) (define prefix-func (make-vector 11)) (define* (add-prefix-operator name priority #:key func) (hashq-set! prefix-ops name priority) (if func (hashq-set! prefix-func name func))) (define (get-infix-priority op) (hashq-ref infix-ops op)) (define (get-infix-func op) (hashq-ref infix-func op op)) (define (infix-right-assoc? op) (hashq-ref infix-right op)) (define (get-prefix-priority op) (hashq-ref prefix-ops op)) (define (get-prefix-func op) (hashq-ref prefix-func op op)) ;--- stack/op utils --------------------------------------------------- (define op-priority car) (define op-func cadr) (define op-nof cddr) (define push cons) (define (make-op func priority nof) (cons* priority func nof)) (define (stack-apply-op s op) (let ((nof (op-nof op))) (cons (cons (op-func op) (reverse! (list-head s nof))) (list-tail s nof)))) ;---- read infix expr-------------------------------------------------- (define (read-infix-expr get-token end? allow-commas) (let loop ((stack '()) (ops '()) (token (get-token)) (unary? #t)) (define (flush) (let flush-loop ((stack stack) (ops ops)) (if (null? ops) (car stack) (flush-loop (stack-apply-op stack (car ops)) (cdr ops))))) (define (continue func priority nof right? unary?) (let iloop ((stack stack) (ops ops)) (if (and (pair? ops) (not (and right? (eq? func (op-func (car ops))))) (<= priority (op-priority (car ops)))) (iloop (stack-apply-op stack (car ops)) (cdr ops)) (loop stack (push (make-op func priority nof) ops) (get-token) unary?)))) (if unary? ; -- "unary" operators -- (cond ((eq? token #\() (loop (push (read-infix-expr get-token char-rparen? #f) stack) ops (get-token) #f)) ((eof-object? token) (error "Unexpected EOF")) ((end? token) (error (%% "Unexpected ~a" token))) (else (let ((priority (get-infix-priority token))) (if priority (continue (get-infix-func token) priority 1 #f #t) (loop (push token stack) ops (get-token) #f))))) ; --- "binary" operators (cond ; fcall (x , y , z) ((and (eq? token #\() (symbol? (car stack))) (loop (push (cons (car stack) (read-infix-expr get-token char-rparen? #t)) (cdr stack)) ops (get-token) #f)) ; smthng [ index ] ((eq? token #\[) (loop (push (list helper-nth (car stack) (read-infix-expr get-token char-rbracket? #f)) (cdr stack)) ops (get-token) #f)) ; smthng , smthng ((and allow-commas (eq? token #\,)) (cons (flush) (loop '() '() (get-token) #t))) ; end-of-expr ((end? token) ((if allow-commas list identity) (flush))) ((eof-object? token) (error "Unexpected EOF")) ; smthng 'op' smthng (else (let ((priority (get-infix-priority token))) (if priority (continue (get-infix-func token) priority 2 (infix-right-assoc? token) #t) (error (%% "Unknown infix operator ~a" token))))))))) ;--- Utils ...--------------------------------------------------------- (define (infix-string->expr s) (read-infix-expr (make-read-tokenizer (open-input-string s)) eof-object? #f)) (define (read-hash-infix _ port) (read-infix-expr (make-read-tokenizer port) char-rbracket? #f)) (define (activate-infix) (read-hash-extend #\[ read-hash-infix)) ;--- Init ... --------------------------------------------------------- (add-infix-operator '|| 5 #:func 'or) (add-infix-operator '&& 10 #:func 'and) (add-infix-operator '< 15) (add-infix-operator '> 15) (add-infix-operator '== 15 #:func 'eq?) (add-infix-operator '<= 15) (add-infix-operator '>= 15) (add-infix-operator '+ 20) (add-infix-operator '- 20) (add-infix-operator '* 25) (add-infix-operator '/ 25) (add-infix-operator '% 25 #:func 'modulo) (add-infix-operator '^ 35 #:func 'expt #:right #t) (add-infix-operator '** 35 #:func 'expt #:right #t) (add-prefix-operator '! 40 #:func 'not) (add-prefix-operator '- 40) ;--- Export ... ------------------------------------------------------- (export make-read-tokenizer add-infix-operator add-prefix-operator read-infix-expr infix-string->expr activate-infix) _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://mail.gnu.org/mailman/listinfo/guile-user ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Infix syntax 2002-10-03 11:26 Infix syntax Daniel Skarda @ 2002-10-05 8:55 ` Neil Jerram 2002-10-06 8:05 ` Daniel Skarda 0 siblings, 1 reply; 31+ messages in thread From: Neil Jerram @ 2002-10-05 8:55 UTC (permalink / raw) Cc: guile-devel, guile-user >>>>> "Daniel" == Daniel Skarda <0rfelyus@ucw.cz> writes: Daniel> I revived my module infix.scm, which enrich Guile syntax Daniel> with expressions. The module was part of cursed gettext Daniel> patch. While ago I rewrote the module and removed Daniel> dependencies on poor gettext patch. This looks nice! If no one objects by mid tomorrow, I will add it to CVS. Have you signed assignment and disclaimer papers that cover this? Neil _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Infix syntax 2002-10-05 8:55 ` Neil Jerram @ 2002-10-06 8:05 ` Daniel Skarda 2002-10-08 21:51 ` Adding stuff to the core distro (was Re: Infix syntax) Neil Jerram 0 siblings, 1 reply; 31+ messages in thread From: Daniel Skarda @ 2002-10-06 8:05 UTC (permalink / raw) Cc: guile-devel > This looks nice! If no one objects by mid tomorrow, I will add it to > CVS. Have you signed assignment and disclaimer papers that cover > this? Thank you. In fact I am quite surprised that this patch went in so smoothly. - it introduces new syntax - once you use-module and activate-infix, infix syntax is active in all modules, not only in module where it was activated. I do not want to undermine my own patch - I am happy it is accepted, though I was surprised there was no exhausting discussion (or flamewar :-) But maybe when people start using infix module, it turns out that these doubts were not real problem at all (just a result of too much coffee :) 0. _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 31+ messages in thread
* Adding stuff to the core distro (was Re: Infix syntax) 2002-10-06 8:05 ` Daniel Skarda @ 2002-10-08 21:51 ` Neil Jerram 2002-10-08 22:40 ` Han-Wen Nienhuys ` (3 more replies) 0 siblings, 4 replies; 31+ messages in thread From: Neil Jerram @ 2002-10-08 21:51 UTC (permalink / raw) Cc: guile-devel >>>>> "0" == Daniel Skarda <0rfelyus@ucw.cz> writes: >> This looks nice! If no one objects by mid tomorrow, I will add it to >> CVS. Have you signed assignment and disclaimer papers that cover >> this? 0> Thank you. In fact I am quite surprised that this patch went in so smoothly. 0> - it introduces new syntax 0> - once you use-module and activate-infix, infix syntax is active in all 0> modules, not only in module where it was activated. I was aware of this. However, we already have modules with the identical issue in CVS, like (srfi srfi-10). And we already have the issues of xxx-options (e.g. (read-options 'prefix)) and, e.g., (current-input-port) being global -- which, at least to my mind, are in the same category. And, all these issues are somewhat hypothetical until someone reports them causing a significant practical problem -- I don't believe anyone has done so yet. Taking all this into account, I didn't think that incorporating (ice-9 infix) created any new issue. Also, the nice requirement to `(activate-infix)' as well as `(use-modules (ice-9 infix)' gives a strong hint that something global is happening (just like `(activate-readline)'). On the other hand... Rob has raised the question of whether we should be adding things to the core distro that don't strictly need to be there, so perhaps we should stop for a moment to consider our principles on this point. I'm not sure what to suggest, myself. Seems to me that one extreme is the Emacs approach - basically bundle everything. The convenience of the opposite extreme depends on what kind of package repository system (aka GUMM) we can create. Any clarifying ideas, anyone? 0> I do not want to undermine my own patch - I am happy it is 0> accepted, though I was surprised there was no exhausting 0> discussion (or flamewar :-) Well, maybe we can have a flamewar now ... :-) Neil _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 31+ messages in thread
* Adding stuff to the core distro (was Re: Infix syntax) 2002-10-08 21:51 ` Adding stuff to the core distro (was Re: Infix syntax) Neil Jerram @ 2002-10-08 22:40 ` Han-Wen Nienhuys 2002-10-09 3:30 ` Rob Browning ` (2 subsequent siblings) 3 siblings, 0 replies; 31+ messages in thread From: Han-Wen Nienhuys @ 2002-10-08 22:40 UTC (permalink / raw) Cc: Daniel Skarda, guile-devel neil@ossau.uklinux.net writes: > principles on this point. > > I'm not sure what to suggest, myself. Seems to me that one extreme is > the Emacs approach - basically bundle everything. The convenience of > the opposite extreme depends on what kind of package repository system > (aka GUMM) we can create. > > Any clarifying ideas, anyone? Yes: bundle anything that is usable/finished and documented. All package documentation should be in the reference manual, or perhaps in a separate package-manual. The beauty of using python is that I can go to the python doc-dir, and do grep 'whatever-I-need' *.tex, (or sometimes even, rpm -ql python| grep 'whatever-I-need' ) and I know directly if it's supported. No hassle with looking around for relevant webpages, or finding out how to install it. Perhaps it makes for easier logistics if all packes were in a separate tarball, due to release frequencies -- don't know about that. -- Han-Wen Nienhuys | hanwen@cs.uu.nl | http://www.cs.uu.nl/~hanwen _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Adding stuff to the core distro (was Re: Infix syntax) 2002-10-08 21:51 ` Adding stuff to the core distro (was Re: Infix syntax) Neil Jerram 2002-10-08 22:40 ` Han-Wen Nienhuys @ 2002-10-09 3:30 ` Rob Browning 2002-10-09 18:15 ` Neil Jerram 2002-10-10 12:29 ` Daniel Skarda 2002-10-10 16:06 ` Daniel Skarda 3 siblings, 1 reply; 31+ messages in thread From: Rob Browning @ 2002-10-09 3:30 UTC (permalink / raw) Cc: Daniel Skarda, guile-devel Neil Jerram <neil@ossau.uklinux.net> writes: > On the other hand... Rob has raised the question of whether we should > be adding things to the core distro that don't strictly need to be > there, so perhaps we should stop for a moment to consider our > principles on this point. I not all that concerned with things that require an explicit activation. I'm more concerned with any additions to what's visible in the core of guile (guile) and (guile-user) at startup, and more particularly, how much happens in ice-9/boot-9.scm, though to some extent that's an efficiency issue as much as a semantic issue. I do think it would be nice if eventually guile were separable to the extent that it was easy to install a "guile-base" that was perhaps much smaller than "guile-base + guile-foo + guile-bar", but I'm not saying I know how things should be broken up in to guile-base, guile-foo, and guile-bar... -- Rob Browning rlb @defaultvalue.org, @linuxdevel.com, and @debian.org Previously @cs.utexas.edu GPG=1C58 8B2C FB5E 3F64 EA5C 64AE 78FE E5FE F0CB A0AD _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Adding stuff to the core distro (was Re: Infix syntax) 2002-10-09 3:30 ` Rob Browning @ 2002-10-09 18:15 ` Neil Jerram 2002-10-09 20:17 ` Rob Browning 0 siblings, 1 reply; 31+ messages in thread From: Neil Jerram @ 2002-10-09 18:15 UTC (permalink / raw) Cc: Daniel Skarda, guile-devel >>>>> "Rob" == Rob Browning <rlb@defaultvalue.org> writes: Rob> Neil Jerram <neil@ossau.uklinux.net> writes: >> On the other hand... Rob has raised the question of whether we should >> be adding things to the core distro that don't strictly need to be >> there, so perhaps we should stop for a moment to consider our >> principles on this point. Rob> I not all that concerned with things that require an explicit Rob> activation. I'm more concerned with any additions to what's Rob> visible in the core of guile (guile) and (guile-user) at Rob> startup, and more particularly, how much happens in Rob> ice-9/boot-9.scm, though to some extent that's an efficiency Rob> issue as much as a semantic issue. But hang on, this is nothing to do with the size of the distro, is it? Rob> I do think it would be nice if eventually guile were Rob> separable to the extent that it was easy to install a Rob> "guile-base" that was perhaps much smaller than "guile-base + Rob> guile-foo + guile-bar", but I'm not saying I know how things Rob> should be broken up in to guile-base, guile-foo, and Rob> guile-bar... So now I'm confused... should I view your comment "we'd be better off moving in the direction of a smaller base" as a commit-stopper or not? (Or did you mean "not in ice-9, but something like (tools infix) would be fine"?) Neil _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Adding stuff to the core distro (was Re: Infix syntax) 2002-10-09 18:15 ` Neil Jerram @ 2002-10-09 20:17 ` Rob Browning 2002-10-10 12:20 ` Daniel Skarda 0 siblings, 1 reply; 31+ messages in thread From: Rob Browning @ 2002-10-09 20:17 UTC (permalink / raw) Cc: Daniel Skarda, guile-devel Neil Jerram <neil@ossau.uklinux.net> writes: > Rob> I not all that concerned with things that require an explicit > Rob> activation. I'm more concerned with any additions to what's > Rob> visible in the core of guile (guile) and (guile-user) at > Rob> startup, and more particularly, how much happens in > Rob> ice-9/boot-9.scm, though to some extent that's an efficiency > Rob> issue as much as a semantic issue. > > But hang on, this is nothing to do with the size of the distro, is it? Right. In this case, I'm referring to the (old idea) that we might want to clean up boot-9.scm. I know that's not what we were originally talking about, but I was just trying to clarify one of my general inclinations wrt additions to guile ATM. > So now I'm confused... should I view your comment "we'd be better off > moving in the direction of a smaller base" as a commit-stopper or not? Nope, not a definite commit-stopper, not unless it was a heavyweight addition (code-wise or runtime-cost-wise) to the startup process or to boot-9.scm. > (Or did you mean "not in ice-9, but something like (tools infix) would > be fine"?) I'm OK with (ice-9 infix), though perhaps (infix-syntax) or (syntax infix) might be better. Also, (and more generally) I'm still not convinced that an a-priori per-topic organization of the module space is a good idea except in cases where it's really clear what that organization should be. For example, I tend to think (gtk) is at least as good as, if not better than (graphics gtk). However, I'd be likely to agree with sub-sections for say (gnome print) (gnome pilot) (gnome vfs) (gnome canvas), etc. I also think that we shouldn't feel too much pressure to use generic names. In this I tend to agree with ttn's practices. For example, unless we were sure we'd come up with the "one true GL interface", I'd be likely to prefer (blarg gl) or (blarg-gl) to just (gl) since we might also have (swig-gl), (gwrap-gl), (super-smart-gl) etc. -- Rob Browning rlb @defaultvalue.org, @linuxdevel.com, and @debian.org Previously @cs.utexas.edu GPG=1C58 8B2C FB5E 3F64 EA5C 64AE 78FE E5FE F0CB A0AD _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Adding stuff to the core distro (was Re: Infix syntax) 2002-10-09 20:17 ` Rob Browning @ 2002-10-10 12:20 ` Daniel Skarda 0 siblings, 0 replies; 31+ messages in thread From: Daniel Skarda @ 2002-10-10 12:20 UTC (permalink / raw) Cc: Neil Jerram, guile-devel Rob Browning <rlb@defaultvalue.org> writes: > I'm OK with (ice-9 infix), though perhaps (infix-syntax) or (syntax > infix) might be better. AFAIR somebody works on Python (and CTAX) syntax for Guile. So maybe there should be some agreement on names of such modules? 0. _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Adding stuff to the core distro (was Re: Infix syntax) 2002-10-08 21:51 ` Adding stuff to the core distro (was Re: Infix syntax) Neil Jerram 2002-10-08 22:40 ` Han-Wen Nienhuys 2002-10-09 3:30 ` Rob Browning @ 2002-10-10 12:29 ` Daniel Skarda 2002-10-13 14:28 ` Neil Jerram 2002-10-10 16:06 ` Daniel Skarda 3 siblings, 1 reply; 31+ messages in thread From: Daniel Skarda @ 2002-10-10 12:29 UTC (permalink / raw) Cc: guile-devel Neil Jerram <neil@ossau.uklinux.net> writes: > I was aware of this. However, we already have modules with the > identical issue in CVS, like (srfi srfi-10). And we already have the > issues of xxx-options (e.g. (read-options 'prefix)) and, e.g., > (current-input-port) being global -- which, at least to my mind, are > in the same category. > > And, all these issues are somewhat hypothetical until someone reports > them causing a significant practical problem -- I don't believe anyone > has done so yet. New TODO entry: modularize reader, so there can be per moudule reader configuration and than extend use-modules/define-module syntax: (define-module (foo) :use-module (ice-9 blah blah) :use-syntax (infix) ....) There is also CLisp-like readtables on my Guile wish list (so maybe I start hacking, some day ...) 0. _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Adding stuff to the core distro (was Re: Infix syntax) 2002-10-10 12:29 ` Daniel Skarda @ 2002-10-13 14:28 ` Neil Jerram 2002-10-16 21:35 ` Daniel Skarda 0 siblings, 1 reply; 31+ messages in thread From: Neil Jerram @ 2002-10-13 14:28 UTC (permalink / raw) Cc: guile-devel >>>>> "Daniel" == Daniel Skarda <0rfelyus@ucw.cz> writes: Daniel> Neil Jerram <neil@ossau.uklinux.net> writes: >> I was aware of this. However, we already have modules with the >> identical issue in CVS, like (srfi srfi-10). And we already have the >> issues of xxx-options (e.g. (read-options 'prefix)) and, e.g., >> (current-input-port) being global -- which, at least to my mind, are >> in the same category. >> >> And, all these issues are somewhat hypothetical until someone reports >> them causing a significant practical problem -- I don't believe anyone >> has done so yet. Daniel> New TODO entry: modularize reader, so there can be per Daniel> moudule reader configuration Probably read-options should also be per-module. Daniel> and than extend use-modules/define-module syntax: Daniel> (define-module (foo) Daniel> :use-module (ice-9 blah blah) Daniel> :use-syntax (infix) Daniel> ....) We already have :use-syntax. It installs a syntax transformer -- which is something that translates expressions inbetween reading and evaluation -- for the specified module. BTW, does (ice-9 infix) handle tricky whitespace like in `#[2+4* 8]'? If not, you could use a simple macro rather than a read hash extension: `(infix 2 + 4 * 8)' rather than `#[2 + 4 * 8]'. As a macro, `infix' would obey the usual module rules. Neil _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Adding stuff to the core distro (was Re: Infix syntax) 2002-10-13 14:28 ` Neil Jerram @ 2002-10-16 21:35 ` Daniel Skarda 2002-10-19 4:50 ` tomas 2002-10-19 22:17 ` Christopher Cramer 0 siblings, 2 replies; 31+ messages in thread From: Daniel Skarda @ 2002-10-16 21:35 UTC (permalink / raw) Cc: guile-devel > BTW, does (ice-9 infix) handle tricky whitespace like in `#[2+4* 8]'? > If not, you could use a simple macro rather than a read hash > extension: `(infix 2 + 4 * 8)' rather than `#[2 + 4 * 8]'. As a > macro, `infix' would obey the usual module rules. Wow, that's clever. It seems I played with read hash extension too much that I have not noticed simpler (and schemish) way... (On the other hand, #[] is shorter :-) Current infix module is divided to tokenizer (an arbitrary function without any parameter, that returns new token) and parser (read-infix-expr tokenizer ....) There is also function make-read-tokenizer, that can build tokenizer for particular port. This tokenizer uses combination of read-char/read, it also splits symbols, when there is #\[ #\] or #\, inside them. No other tricky whitespace handling is performed (it would be dangerous, since #\- and #\* are often used in scheme symbols). infix.scm proposal, second edition: ------------------------------------- (define-infix-macro NAME) define macro `NAME' which transforms infix syntax to scheme expressions. It also defines variables *NAME-infix*, *NAME-prefix* hash tables (or rather alists?) and *NAME-split-list*. NAME splits its arguments according characters in *NAME-split-list* list and creates tokenizer, which successively feeds read-infix-expr with tokens. (add-infix-operator NAME operator func paramers ...) (add-prefix-operator NAME operator func paramers ...) (add-infix-separator NAME character) I think that "clever" whitespace handling would be sometimes very confusing. It is possible to split 4*8, but #\- will cause nightmare (foo-bar). IMHO it would not be wise to split using symbol lookup (defined?) since it could cause mysterious bugs ... I am going to rewrite infix.scm as soon as I get some spare time (first I should stop spamming guile-devel with long emails, I guess :) 0. ps: Sometimes I also use read-hash extension for shorter (sed|awk|perl|...)-like regular expressions: #/foo.*bar/i, sometimes I also use srfi-10 #,(rx "foo.*bar" icase). Do you think that other guilers would benefit from such hairy extensions? I try to clean up my regexps.scm and post it later. _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Adding stuff to the core distro (was Re: Infix syntax) 2002-10-16 21:35 ` Daniel Skarda @ 2002-10-19 4:50 ` tomas 2002-10-20 19:15 ` Daniel Skarda 2002-10-19 22:17 ` Christopher Cramer 1 sibling, 1 reply; 31+ messages in thread From: tomas @ 2002-10-19 4:50 UTC (permalink / raw) Cc: Neil Jerram, guile-devel On Wed, Oct 16, 2002 at 11:35:15PM +0200, Daniel Skarda wrote: > [Neil: macro instead of read-hash-extension] > Wow, that's clever. It seems I played with read hash extension too much that I > have not noticed simpler (and schemish) way... (On the other hand, #[] is shorter :-) Isn't Scheme surprising to us mortals ;-) [...] > No other tricky whitespace handling is performed (it would be dangerous, since > #\- and #\* are often used in scheme symbols). Albeit dangerous, I'd vote for having it (as an option, at least). It should just accept ``classical'' identifiers (C-like if you wish). Background: I'm playing with the idea of letting users enter formulas for a small application (users not aware of Scheme), and I think the ``classical'' syntax is easier to grasp for them. > infix.scm proposal, second edition: > ------------------------------------- [snip] Yes, makes sense to let the macro expander do the parse work. Maybe a first-stage tokenizer for the ``micro-syntax'' (this would be called a lexer in a more traditional framework?) could be thrown in as an option. Thanks -- tomas _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Adding stuff to the core distro (was Re: Infix syntax) 2002-10-19 4:50 ` tomas @ 2002-10-20 19:15 ` Daniel Skarda 2002-10-21 9:36 ` tomas 2002-10-21 18:21 ` Neil Jerram 0 siblings, 2 replies; 31+ messages in thread From: Daniel Skarda @ 2002-10-20 19:15 UTC (permalink / raw) Cc: Neil Jerram, guile-devel tomas@fabula.de writes: > > No other tricky whitespace handling is performed (it would be dangerous, since > > #\- and #\* are often used in scheme symbols). > > Albeit dangerous, I'd vote for having it (as an option, at least). It should just > accept ``classical'' identifiers (C-like if you wish). Background: I'm playing with > the idea of letting users enter formulas for a small application (users not aware > of Scheme), and I think the ``classical'' syntax is easier to grasp for them. This would require more clever tokenizer (symbol splitting) than current implementation in infix.scm. How would you split 1-1e-1? I do not want to write another tokenizer - rather I would like to rewrite "read" to support lisp-like readtables and than configure it to enable "classical" identifiers. Any objections? (well, my diary say something about no spare time, but I try to fix that :-) 0. _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Adding stuff to the core distro (was Re: Infix syntax) 2002-10-20 19:15 ` Daniel Skarda @ 2002-10-21 9:36 ` tomas 2002-10-21 18:21 ` Neil Jerram 1 sibling, 0 replies; 31+ messages in thread From: tomas @ 2002-10-21 9:36 UTC (permalink / raw) Cc: guile-devel On Sun, Oct 20, 2002 at 09:15:14PM +0200, Daniel Skarda wrote: > > tomas@fabula.de writes: [stuff about white-space-less infix `syntax'] > This would require more clever tokenizer (symbol splitting) than current > implementation in infix.scm. Yup. > How would you split 1-1e-1? I do not want to write > another tokenizer - rather I would like to rewrite "read" to support lisp-like > readtables and than configure it to enable "classical" identifiers. Sounds good. > Any objections? No, of course not! > (well, my diary say something about no spare time, but I try to fix that :-) Sigh. A wide-spread bug, I'd say. Thanks -- tomas _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Adding stuff to the core distro (was Re: Infix syntax) 2002-10-20 19:15 ` Daniel Skarda 2002-10-21 9:36 ` tomas @ 2002-10-21 18:21 ` Neil Jerram 1 sibling, 0 replies; 31+ messages in thread From: Neil Jerram @ 2002-10-21 18:21 UTC (permalink / raw) Cc: tomas, guile-devel >>>>> "Daniel" == Daniel Skarda <0rfelyus@ucw.cz> writes: Daniel> rather I would like to rewrite "read" to support lisp-like Daniel> readtables and than configure it to enable "classical" Daniel> identifiers. Daniel> Any objections? No, but please avoid degrading performance in the case where the reader is reading the same things that it can already. Neil _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Adding stuff to the core distro (was Re: Infix syntax) 2002-10-16 21:35 ` Daniel Skarda 2002-10-19 4:50 ` tomas @ 2002-10-19 22:17 ` Christopher Cramer 2002-10-20 19:05 ` Daniel Skarda 1 sibling, 1 reply; 31+ messages in thread From: Christopher Cramer @ 2002-10-19 22:17 UTC (permalink / raw) Cc: guile-devel On Wed, Oct 16, 2002 at 11:35:15PM +0200, Daniel Skarda wrote: > ps: Sometimes I also use read-hash extension for shorter > (sed|awk|perl|...)-like regular expressions: #/foo.*bar/i, sometimes > I also use srfi-10 #,(rx "foo.*bar" icase). Do you think that other > guilers would benefit from such hairy extensions? Ack. I actually started using #/ for SQL. I think there definitely needs to be some better method of preventing read-hash-extend collisions. The current method, where you pick one character and hope no other code uses it, is going to cause problems at some point. Per-module hash extensions would be the best way, I think. -- Christopher Cramer <crayc@pyro.net> <http://www.pyro.net/~crayc/> "Gore would have finished ahead by the barest of margins had he pursued and gained a complete statewide recount." -- Associated Press, 9/6/2002 _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Adding stuff to the core distro (was Re: Infix syntax) 2002-10-19 22:17 ` Christopher Cramer @ 2002-10-20 19:05 ` Daniel Skarda 0 siblings, 0 replies; 31+ messages in thread From: Daniel Skarda @ 2002-10-20 19:05 UTC (permalink / raw) Cc: guile-devel > On Wed, Oct 16, 2002 at 11:35:15PM +0200, Daniel Skarda wrote: > > ps: Sometimes I also use read-hash extension for shorter > > (sed|awk|perl|...)-like regular expressions: #/foo.*bar/i, sometimes > > I also use srfi-10 #,(rx "foo.*bar" icase). Do you think that other > > guilers would benefit from such hairy extensions? > > Ack. I actually started using #/ for SQL. Oops :-) How do you use it for SQL? I usually do not support adding new syntactic sugar to Scheme, but sometimes I simply can not resist :-) I picked up #/regexp/ since almost all programmers are familiar with similar syntax from perl, awk, sed and other shell utils. The advantage of this style of writing regexps is its "regexpness" :-) and the ability to create regexp during read (no need to "toplevel" define etc). The later can also be achieved by #,(rx "regexp"), which is more schemish but less regexpish, it is longer and you have to write two escapes instead of one (definitely not tempting features for lazy programmers :-). As I wrote in another email I would like to add lisp-like readtables to Guile read so it would be possible to make read-hash-extension per-module. IMHO Guile should come with modules that implement/activate syntax extensions (like infix syntax, #/regexps/, #,(rx "regexp") or whatever), if we preserve following rules: 1) extensions are off by default 2) no Guile code (srfi,ice-9) use or depends on these extensions. 3) user is clearly warned that these extensions are not portable 4) one extensions does not clash with another... Maybe we also should pick some policy to prevent future clashes (#/regexps/ versus your #/ in SQL) 0. _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Adding stuff to the core distro (was Re: Infix syntax) 2002-10-08 21:51 ` Adding stuff to the core distro (was Re: Infix syntax) Neil Jerram ` (2 preceding siblings ...) 2002-10-10 12:29 ` Daniel Skarda @ 2002-10-10 16:06 ` Daniel Skarda 2002-10-10 17:12 ` Rob Browning ` (2 more replies) 3 siblings, 3 replies; 31+ messages in thread From: Daniel Skarda @ 2002-10-10 16:06 UTC (permalink / raw) Cc: guile-devel > On the other hand... Rob has raised the question of whether we should > be adding things to the core distro that don't strictly need to be > there, so perhaps we should stop for a moment to consider our > principles on this point. > > I'm not sure what to suggest, myself. Seems to me that one extreme is > the Emacs approach - basically bundle everything. The convenience of > the opposite extreme depends on what kind of package repository system > (aka GUMM) we can create. I vote for Emacs approach - bundle everything that is mature, documented and stable. Before you reply that my message was driven by megalomania, I try to explain my view: Scheme is very pretty language, but I think that these days "pretty language" does not imply success. Also libraries that come with language are important as well. So we should not see Guile as a single package but rather as a development platform. The development platform that is not as popular as other (python, perl) ... I my opinion, breaking guile into small (orthogonal) packages is nice from "pure" developer's view, but it fails in "real world" and builds unnecessary walls between Guile and Joe Average Programmer, who wants to evaluate Guile: "Install guile-x.y, guile-foo-y.z, guile-bar-a.b. Joe, do you want to use feature XYZ? than you have to checkout, compile, install guile-CVS, checkout guile-foo-CVS, because guile-foo-y.z does not work with guile-CVS... Also users of your program must do the same because there are no Debian/RedHat/... packages for development versions." Do you think that Mr Joe A. Programmer will choose Guile because Scheme is superior language and "Official GNU blah blah blah"? I think programmers want to start coding, not to spend their time collecting/ maintaining/upgrading various tiny packages. Also Guile development would be easier with "one big development pot": * Read "guile-debugger" thread on guile-devel. Even developers have not known that there is guile-debugger package. "One big pot" means less probability you miss some important package, because have not noticed its announcement or reference deep inside the Guile documentation. * When somebody changes (read: improves :-) some interface, it is easier to spot and fix all places, where the change breaks actual code. Even thought a developer, who was responsible for some feature, retires, code from big pot will not become orphan (there is always somebody who fixes it). * It saves us a lot of time. cvs update -dP, autogen, configure, make, make install, cvs update, autoget, configure, make install, .... * "One big pot" also simplifies dependecies (see Joe's example). And there is no need for a lot of #ifdef GUILE_HAS_FOO_FEATURE, #ifdef GUILE_1_x_y,.. which are hell to maintain. So these were my arguments I could think of. Please try to write down your oppinions. I would also like to hear arguments from "the other side" (break Guile into small and orthogonal packages), but I can not think of any benefit that would come from scattered development (except specific "beauty"). IMHO it is easier to write script, that extracts small subset from guile-core, than to maintain zillions of small packages (think: guile-core, guile-infix, guile-srfi-1, guile-srfi-*, guile-readline, guile-.....) 0. ps: It would be also nice to "release Guile regularly, release Guile often". I would like to propose to release Guile development branch monthly (or every fortnight). At least for some time, so we can find if this approach is an advantage or not. Also detailed development roadmap (timeline, schedule) would be very helpful. ps: Another successful example of "big development pot" is Linux kernel (or XFree project). ps: Example of tools/utils/code I would merge into Guile immediately or ASAP: g-wrap, build-guile-gtk script or any other tool for making language bindings. There are plenty of them and it is strange that there is no standard one. Also sgtk_flags2scm family of C utils would be helpful. (When I say "merge" here, I do not mean to merge directly into libguile, but merge into guile-core as libguiletools or something like that). ps: Maybe "hybrid" approach would be the best way. Bundle everything possible, but also provide an easy way for creating/distributing/maintaining Guile packages (and a repository to archive them). _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Adding stuff to the core distro (was Re: Infix syntax) 2002-10-10 16:06 ` Daniel Skarda @ 2002-10-10 17:12 ` Rob Browning 2002-10-10 18:46 ` Clinton Ebadi ` (3 more replies) 2002-10-10 18:08 ` Bill Gribble 2002-10-13 14:27 ` Neil Jerram 2 siblings, 4 replies; 31+ messages in thread From: Rob Browning @ 2002-10-10 17:12 UTC (permalink / raw) Cc: Neil Jerram, guile-devel Daniel Skarda <0rfelyus@ucw.cz> writes: > I my opinion, breaking guile into small (orthogonal) packages is > nice from "pure" developer's view, but it fails in "real world" and > builds unnecessary walls between Guile and Joe Average Programmer, > who wants to evaluate Guile: I wouldn't propose that we break guile up into a "maze of twisty packages", but I do think that long-term, maintaining some divisions may make sense. I'm not even sure we necessarily need to do anything wrt to guile-core as it stands -- for the most part, I'm interested in what we might do going forward. IMO whether or not we break up the *source-tree* is a different question from what we do at install time, and what policies we adopt wrt interdependencies inside and outside guile-core. For example, we might decide to have a very large source tree that by default installs everything, but can also just install parts of itself. Maybe make install-core make install-srfis make install-gtk or whatever, if we went the "big tree" route. Two parties I'd like to keep in mind when making these decisions: - the packagers - we should consider what happens if I want to package guile for debian and we've stuck guile-gtk, qt, kde, gnome, etc. all in the main tree. If I build and install with everything, I can assure you there will be a *lot* of users who will (legitimately) complain that I'm forcing them to install, say X, gtk, qt, and gnome on their *non-X* system. There are a variety of ways we could handle this, but I think it's important to keep in mind. (This has actually been a fairly major hassle to fix in the current emacs21 wrt x and no-x, and I'm still not finished.) - the special cases -- we should consider what effect any arrangement we discuss might have on the difficulty of using guile in small environments. i.e. the user (or distribution) who wants to put guile on a firewall, ipaq, or mini-board. If we only support a make install of 20MB+, then we're not considering this case, and IMO it's not very workable to just say "these people need to pick out the bits they need themselves" -- if we don't have some policies wrt to our "core", then we'll eventually end up with all kinds of cross-dependencies between different modules. As an example of a policy question -- if we added a perlre module, would it be OK for the core code to use it? How about srfi-1?, etc. -- Rob Browning rlb @defaultvalue.org, @linuxdevel.com, and @debian.org Previously @cs.utexas.edu GPG=1C58 8B2C FB5E 3F64 EA5C 64AE 78FE E5FE F0CB A0AD _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Adding stuff to the core distro (was Re: Infix syntax) 2002-10-10 17:12 ` Rob Browning @ 2002-10-10 18:46 ` Clinton Ebadi 2002-10-10 22:24 ` Lynn Winebarger ` (2 subsequent siblings) 3 siblings, 0 replies; 31+ messages in thread From: Clinton Ebadi @ 2002-10-10 18:46 UTC (permalink / raw) Cc: Neil Jerram, guile-devel On Thursday 10 October 2002 13:12, Rob Browning wrote: > IMO whether or not we break up the *source-tree* is a different > question from what we do at install time, and what policies we adopt > wrt interdependencies inside and outside guile-core. For example, we > might decide to have a very large source tree that by default installs > everything, but can also just install parts of itself. Maybe > > make install-core > make install-srfis > make install-gtk > How about making guile-core as small as possible and then adding a guile-standard (or -extras) with everything else? Then the Guile CORE would be the core, and the standard module would be the modules and tools that most people would want. -- http://unknownlamer.org Truth lies in loneliness When hope is long gone by _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Adding stuff to the core distro (was Re: Infix syntax) 2002-10-10 17:12 ` Rob Browning 2002-10-10 18:46 ` Clinton Ebadi @ 2002-10-10 22:24 ` Lynn Winebarger 2002-10-13 15:09 ` Proposal for scope of core distro Neil Jerram 2002-10-17 0:10 ` Adding stuff to the core distro (was Re: Infix syntax) Daniel Skarda 3 siblings, 0 replies; 31+ messages in thread From: Lynn Winebarger @ 2002-10-10 22:24 UTC (permalink / raw) Cc: Neil Jerram, guile-devel On Thursday 10 October 2002 12:12, Rob Browning wrote: > Daniel Skarda <0rfelyus@ucw.cz> writes: > > > I my opinion, breaking guile into small (orthogonal) packages is > > nice from "pure" developer's view, but it fails in "real world" and > > builds unnecessary walls between Guile and Joe Average Programmer, > > who wants to evaluate Guile: > > I wouldn't propose that we break guile up into a "maze of twisty > packages", but I do think that long-term, maintaining some divisions > may make sense. I'm not even sure we necessarily need to do anything > wrt to guile-core as it stands -- for the most part, I'm interested in > what we might do going forward. > > IMO whether or not we break up the *source-tree* is a different > question from what we do at install time, and what policies we adopt > wrt interdependencies inside and outside guile-core. For example, we > might decide to have a very large source tree that by default installs > everything, but can also just install parts of itself. Maybe X is the real example of this "throw everything into one big honkin' pot and pray" approach. What a beast it is, too. Regardless of how guile is packaged to the end user (and that's not really J. guile hacker's job in many respects), more code barriers are better. Keeping the trees separate is a proactive measure for preventing code incest. So to speak. Lynn _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 31+ messages in thread
* Proposal for scope of core distro 2002-10-10 17:12 ` Rob Browning 2002-10-10 18:46 ` Clinton Ebadi 2002-10-10 22:24 ` Lynn Winebarger @ 2002-10-13 15:09 ` Neil Jerram 2002-10-17 0:10 ` Adding stuff to the core distro (was Re: Infix syntax) Daniel Skarda 3 siblings, 0 replies; 31+ messages in thread From: Neil Jerram @ 2002-10-13 15:09 UTC (permalink / raw) Cc: guile-devel >>>>> "Rob" == Rob Browning <rlb@defaultvalue.org> writes: Rob> Two parties I'd like to keep in mind when making these decisions: Rob> - the packagers - we should consider what happens if I want to Rob> package guile for debian and we've stuck guile-gtk, qt, kde, Rob> gnome, etc. all in the main tree. If I build and install with Rob> everything, I can assure you there will be a *lot* of users who Rob> will (legitimately) complain that I'm forcing them to install, say Rob> X, gtk, qt, and gnome on their *non-X* system. There are a Rob> variety of ways we could handle this, but I think it's important Rob> to keep in mind. Rob> - the special cases -- we should consider what effect any Rob> arrangement we discuss might have on the difficulty of using guile Rob> in small environments. i.e. the user (or distribution) who wants Rob> to put guile on a firewall, ipaq, or mini-board. If we only Rob> support a make install of 20MB+, then we're not considering this Rob> case, and IMO it's not very workable to just say "these people Rob> need to pick out the bits they need themselves" -- if we don't Rob> have some policies wrt to our "core", then we'll eventually end up Rob> with all kinds of cross-dependencies between different modules. These cases are very helpful. Based on these, and on the feedback from everyone else on this subject, I'd like to propose the following plan for the scope of guile-core and other Guile add-on distributions. - In general, define Guile distributions by their dependencies. This is a nice way of looking at things: guile-core becomes the collection of all Guile code that depends only on Guile itself, guile-gtk the collection that depends logically on Guile+Gtk, and so on. - In particular, as regards guile-core, we would not allow adding anything that introduces any new external dependencies, but we would accept pretty much anything that is reasonably stable, well-written and of general interest, so long as it doesn't introduce any new dependencies. This includes most new pure Scheme code. (We may need some kind of staging post or review process here; cf. the Emacs Lisp archive.) - guile-gtk, for example, should remain a separate distribution, as the rule above prohibits us from merging it into guile-core. But guile-gtk in turn could grow by accepting any new contributions whose dependencies were only Guile and Gtk. - Within a distribution, and in particular within guile-core, we should aim to provide full configuration-time control over which parts of the distribution are built and installed, with two important special cases being "minimal" and "everything". In guile-core, we already have a lot of this - try typing `./configure --help' to see the control available. We just need to - extend it to cover Scheme module selection (including, in some cases, the C libraries that they incorporate) - add in implicit dependencies so that we always create a consistent build - eventually, factor out more of libguile into selectable options, so that the "minimal" option can be more so - document everything clearly. It would be a good idea to track the size of a "minimal" install in automated builds, so that if we did introduce a dependency that increased the size, we'd notice. Rob> As an example of a policy question -- if we added a Rob> perlre module, would it be OK for the core code to use Rob> it? How about srfi-1?, etc. The decision would lie in the details. According to the above guidelines, though, - it _would_ be OK to bundle the perlre module in guile-core, assuming that perlre doesn't depend on Perl or anything other new dependencies - the sense of using perlre in, say, srfi-1 could be informed by looking at the effect on the minimal install size. Neil _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Adding stuff to the core distro (was Re: Infix syntax) 2002-10-10 17:12 ` Rob Browning ` (2 preceding siblings ...) 2002-10-13 15:09 ` Proposal for scope of core distro Neil Jerram @ 2002-10-17 0:10 ` Daniel Skarda 2002-10-18 7:24 ` Lynn Winebarger 3 siblings, 1 reply; 31+ messages in thread From: Daniel Skarda @ 2002-10-17 0:10 UTC (permalink / raw) Cc: Neil Jerram, guile-devel, Lynn Winebarger > Two parties I'd like to keep in mind when making these decisions: > > - the packagers - we should consider what happens if I want to > package guile for debian and we've stuck guile-gtk, qt, kde, > gnome, etc. all in the main tree. If I build and install with > everything, I can assure you there will be a *lot* of users who > will (legitimately) complain that I'm forcing them to install, say > X, gtk, qt, and gnome on their *non-X* system. There are a > variety of ways we could handle this, but I think it's important > to keep in mind. > > (This has actually been a fairly major hassle to fix in the > current emacs21 wrt x and no-x, and I'm still not finished.) In my opinion, Guile _development_ should not copy the way how various distributions split Guile into packages. Last time I compiled Emacs myself, it was one big executable - either with or without X support (no modules possible). Guile has big advantage over Emacs that it can be split into modules and these modules can be distributed independently (with different dependencies). > - the special cases -- we should consider what effect any > arrangement we discuss might have on the difficulty of using guile > in small environments. i.e. the user (or distribution) who wants > to put guile on a firewall, ipaq, or mini-board. If we only > support a make install of 20MB+, then we're not considering this > case, and IMO it's not very workable to just say "these people > need to pick out the bits they need themselves" -- if we don't > have some policies wrt to our "core", then we'll eventually end up > with all kinds of cross-dependencies between different modules. "What if". Your are afraid that if Guile was bloated, Guile would lose users who want to use Guile in small environments. Notice that are not such users - otherwise there would be demand for small guile or there would be such guile distribution already. How can Guile lose users that it does not have? I am afraid that Guile has not many users. I am trying to find better development model and how to attract more users. I am thinking: better development -> more users (-> more developers ...). Also when more users are familiar with Guile and use it for their daily work, it is more likely that somebody choose Guile for his ipaq application... I think that there are many ways how to strip down Guile and decide what should or should not be included. Until there is somebody who really needs such Guile, we are not able to guess which way is right. It seems to me that you want to invent a hammer, but you do not know yet what it will be good for. > As an example of a policy question -- if we added a perlre module, > would it be OK for the core code to use it? How about srfi-1?, > etc. Lynn Winebarger <owinebar@free-expression.org> writes: > Keeping the trees separate is a proactive measure for preventing code incest. (I had to read this sentence few times before I fully understood it :-) srfi-1 is very good example - it is really large module and it sometimes makes me thinking: "I want to use only function `every' (or fold-left) - why I have to include so BIG list library?" Pros/cons: + srfi-1 is standard - it is so BIG + If I implement fold (every, any) every time I need it, again and again, - I waste my time - it negates any benefits that come from standard libraries - I bloat code of my programs anyway (various `fold' implementation - here and there...) - when I copy buggy implementation of `fold', I also copy a bug. When I fix the bug, I also have to fix all copies of `fold'.... If I do not bloat my program by using BIG srfi-1, I end up with zillions of fold (every,and*..) implementations bloating every library. So, (use-module (srfi srfi-1)) or not to (use-module (srfi srfi-1))? That's question. What does it mean "keeping the trees separate is a proactive measure for preventing code incest"? If it means that every guile developer has to reinvent the wheel again and again (because of holy grail of small set of dependencies), than it is bad measure. We should distinguish three different problems: Development process - I think that we should integrate here as much as possible. When I say "integrate", I do not mean "put everything in one big libguile.so or boot-9.scm", rather I mean "one development pot". Even though Neil announced his guile-debugger many times, it passed unnoticed by many developers (though many of them wrote in their TODO list - "I really have to look into guile-debugger..." :-) I bet that if somebody had merged guile-debugger sooner, it would have been already in wide use and possibly it would already have been enhanced with many new features. Release - when "one big pot" is not feasible, it seems that Guile has to be split into packages (just for release). I think that it is not wise to use "smallest dependencies" criteria, instead I would split packages "logically" - I would look for the ways people often use them. Guile-Gdk would depend on less packages than Guile-Gtk, but almost all people use them together. If somebody really, really wants to extract Gdk bindings out of Guile-gtk, he should invest some work. If we want to think of all ways in which people may use Guile and a priori satisfy all possible demands on Guile, we are going to fail. Nothing is perfect from the beginning. We should be careful to not to close some doors (many interdependencies now -> hard to make stripped down version later), but such care should not paralyse and slow down development. Policies - As you already warned, we should consider what policies we keep so we do not close any door and make some further development impossible. Please, separate these three issues in your mind. Policies should only affect the source code, they should not slow down development or make it harder. Guile is divided into packages according to distribution policies. Using distribution (foreign) policies during Guile development sounds unnatural to me. To divide Guile to several packages is the task of package maintainer. 0. _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Adding stuff to the core distro (was Re: Infix syntax) 2002-10-17 0:10 ` Adding stuff to the core distro (was Re: Infix syntax) Daniel Skarda @ 2002-10-18 7:24 ` Lynn Winebarger 2002-10-20 20:25 ` Daniel Skarda 0 siblings, 1 reply; 31+ messages in thread From: Lynn Winebarger @ 2002-10-18 7:24 UTC (permalink / raw) Cc: Neil Jerram, guile-devel On Wednesday 16 October 2002 19:10, Daniel Skarda wrote: > Lynn Winebarger <owinebar@free-expression.org> writes: > > Keeping the trees separate is a proactive measure for preventing code incest. > > (I had to read this sentence few times before I fully understood it :-) I blame ttn for that. I believe he's infected me with some sort of language virus. ;-) It also has the virtue of being both true and funny to say. > srfi-1 is very good example - it is really large module and it sometimes makes > me thinking: "I want to use only function `every' (or fold-left) - why I have to > include so BIG list library?" I think this misposes the question. I should be able to have all the functions in srfi-1 _presented_ in one large module, but the module system should not require that they are all defined in one big file, or even that I need to actually import them all. Why can't I define a bunch of little modules (possible with dependencies) and then load those into srfi-1 which then exports all those names as one big group? [ Or just load the subset I actually want/need ] Not being able to do that is a deficiency in a module system IMO. > What does it mean "keeping the trees separate is a proactive measure for > preventing code incest"? If it means that every guile developer has to reinvent > the wheel again and again (because of holy grail of small set of dependencies), > than it is bad measure. The goal is not a small set of dependencies (per se). It's just cleaner to keep code from having more knowledge about other code than it should. SE101. I think it's a little easier to enforce this minimalism of code knowledge if you actually keep code in separate directories. If anything, I'd probably advocate separating what's in the libguile directory now into smaller, mostly independent directories, where a developer could be reasonably certain that to understand a piece of code in a file they probably would only need to look at other files in that subdirectory, or possibly in some header files (or possibly other subdirectories closer to the real core code, i.e. eval.c). As I said, I think the eventual dependencies of distributions are the job of the vendor, not of Guile hackers (per se). Rob, of course, does both, but they are separate roles and the one shouldn't unduly influence the other. Making it easy to reduce dependencies is probably a good idea, but because it comes from the same basic SE101 principles I mentioned above rather than just in and of itself. Lynn _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Adding stuff to the core distro (was Re: Infix syntax) 2002-10-18 7:24 ` Lynn Winebarger @ 2002-10-20 20:25 ` Daniel Skarda 0 siblings, 0 replies; 31+ messages in thread From: Daniel Skarda @ 2002-10-20 20:25 UTC (permalink / raw) Cc: Rob Browning, Neil Jerram, guile-devel Lynn Winebarger <owinebar@free-expression.org> writes: > Why can't I define a bunch of little modules (possible with dependencies) > and then load those into srfi-1 which then exports all those names as one big group? > [ Or just load the subset I actually want/need ] AFAIK it is possible (see for example srfi-2 and re-export) but unfortunately srfi-1 is not implemented this way :-( Short list of other module faux pas: - two list libraries - srfi-1 and ice-9/common-list. Both of them implement `every' etc. I guess module names like (list foo) would be very boring... - structs (guile-core), make-record (boot-9), define-struct (match, psyntax), define-record-type (srfi-9), define-class (goops). > The goal is not a small set of dependencies (per se). It's just cleaner to keep > code from having more knowledge about other code than it should. SE101. I > think it's a little easier to enforce this minimalism of code knowledge if you actually > keep code in separate directories. If anything, I'd probably advocate separating > what's in the libguile directory now into smaller, mostly independent directories, > where a developer could be reasonably certain that to understand a piece of > code in a file they probably would only need to look at other files in that subdirectory, > or possibly in some header files (or possibly other subdirectories closer to the real > core code, i.e. eval.c). I understand. I do not oppose to separate code into directories. I just do not understand why Guile _development_ is so separated - guile-core here, guile-debugger over there etc. I do not propose to put everything into libguile or boot-9. I propose more centralised development - distribute with guile everything somebody may find useful (so he can directly start using guile for some specific task - no need to search inet etc), develop everything together (lower maintenance cost), make Guile more attractive. SE (Scheme Elephant :-), 0. _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Adding stuff to the core distro (was Re: Infix syntax) 2002-10-10 16:06 ` Daniel Skarda 2002-10-10 17:12 ` Rob Browning @ 2002-10-10 18:08 ` Bill Gribble 2002-10-17 2:42 ` Daniel Skarda 2002-10-13 14:27 ` Neil Jerram 2 siblings, 1 reply; 31+ messages in thread From: Bill Gribble @ 2002-10-10 18:08 UTC (permalink / raw) Cc: Neil Jerram, guile-devel On Thu, 2002-10-10 at 11:06, Daniel Skarda wrote: > So these were my arguments I could think of. Please try to write down your > oppinions. I would also like to hear arguments from "the other side" (break > Guile into small and orthogonal packages), but I can not think of any benefit > that would come from scattered development (except specific "beauty"). Deployability. I'd like to be able to pick and choose which pieces of guile library functionality I need to install on a target platform -- for example, I have an actual client who I am actually delivering a guile application running on a Compaq iPaq running Linux. It's a very small platform, and if I have to pull in every SRFI, an Emacs debugger interface, and all of the Gnome and Gtk libraries to install guile, that's a problem for me. I agree that for building general hacking interest it's good to have the kitchen sink and all. But that's just a piece of the puzzle -- for guile to be successful, it has to have long-term usefulness as a tool that can be used by people getting paid to use it. Perl wouldn't be perl if it was just fun to hack stuff up with it -- people push on it because they use it in their jobs. Personally, I have been using debian for so long that I don't want to follow anything in CVS unless I'm hacking on it myself. From my POV if it's manageably decomposed in debian, apt will do the thinking for me and if I want a new shiny widget it's easy to install it. b.g. _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Adding stuff to the core distro (was Re: Infix syntax) 2002-10-10 18:08 ` Bill Gribble @ 2002-10-17 2:42 ` Daniel Skarda 0 siblings, 0 replies; 31+ messages in thread From: Daniel Skarda @ 2002-10-17 2:42 UTC (permalink / raw) Cc: Neil Jerram, guile-devel Bill Gribble <grib@linuxdevel.com> writes: > I have an actual client who I am actually delivering a guile application > running on a Compaq iPaq running Linux Oops! If I had read this email before I started to shout in my previous today's email that there are no such Guile users ... I am sorry for that (next time I have to read all mails before I reply...) OK. What guile features you consider essential for your application? How would you split Guile into packages? BTW - why you chose Guile? I do not know the world of Compaq iPaq running Linux, which tools you use to manage packages. I guess that this world differs a lot from average desktop and you have to create all packages with special care. I see that one can not shape Guile to fit perfectly to any particular application (mine or anybody else) and its requirements... It is always in the middle. One can not ask Linus to exclude XY support from kernel distribution, because he do not use it and find it bloatware. > I'd like to be able to pick and choose which pieces of > guile library functionality I need to install on a target platform -- Yes, that would be nice and really helpful for wider acceptance of Guile in small environments. > It's a very small platform, and if I have to pull in every SRFI, an Emacs > debugger interface, and all of the Gnome and Gtk libraries to install guile, > that's a problem for me. On the other hand, if you want to follow Guile development... :-) > Personally, I have been using debian for so long that I don't want to > follow anything in CVS unless I'm hacking on it myself. Suppose you write big application - it will take you few years before you finish it. At the time you release your application, there will be already new Guile version. If you stick to stable Guile version, you gain stability, but you can not change anything in Guile - even though something is really clumsy or you have to do nasty tricks to reach your goals (but that's dangerous from long-term POV). On the other hand you will port your application to new version anyway, so why not to follow CVS development? You can help Guile developers to debug Guile development version, you may warn them when you find some interface awkward or you miss some feature. It is hard to choose the way - each one has it cons and pros. I chose the second way so I am looking how to make it easier and secure. 0. _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Adding stuff to the core distro (was Re: Infix syntax) 2002-10-10 16:06 ` Daniel Skarda 2002-10-10 17:12 ` Rob Browning 2002-10-10 18:08 ` Bill Gribble @ 2002-10-13 14:27 ` Neil Jerram 2002-10-17 1:25 ` Daniel Skarda 2 siblings, 1 reply; 31+ messages in thread From: Neil Jerram @ 2002-10-13 14:27 UTC (permalink / raw) Cc: guile-devel >>>>> "Daniel" == Daniel Skarda <0rfelyus@ucw.cz> writes: Daniel> I my opinion, breaking guile into small (orthogonal) Daniel> packages is nice from "pure" developer's view, but it Daniel> fails in "real world" and builds unnecessary walls between Daniel> Guile and Joe Average Programmer, who wants to evaluate Daniel> Guile: I agree; I've been thinking about some of my own guile packages that I have been keeping separate (from each other) and came to the same conclusion: it's a pain for me because of the overhead of working out dependencies and the best place for everything, and it puts barriers in the way of someone coming across something interesting just because it is there. With their xxx-pers-scheme distributions, ttn and mgrabmue have had this right all along. Daniel> Do you think that Mr Joe A. Programmer will choose Guile Daniel> because Scheme is superior language and "Official GNU blah Daniel> blah blah"? Yes I do, but that doesn't mean we have to make other aspects of the experience hard. Daniel> * Read "guile-debugger" thread on guile-devel. Even Daniel> developers have not known that there is guile-debugger Daniel> package. In this case, though, the package is still new and possibly not ready for the core. Daniel> So these were my arguments I could think of. Please try Daniel> to write down your oppinions. Here are the opposing arguments that I can think of. - As Rob says, life gets tricky if the distro as a whole has more external dependencies - e.g. gtk, xlib, postgres, librx. Building from source is OK: just allow and handle a corresponding --with-xxx flag to ./configure for each dependency. But distributors will want to build different pieces with different dependencies: - the "core" piece, with no additional dependencies - the gtk add-on piece, which depends on the core and on Gtk etc. Note that, if this logic is correct, distribution package users will always end up seeing lots of small packages, even if coming from a single Guile distribution. It might be fun to have a flexible build that allowed to build all these pieces from a single distribution, but (i) would we just be reinventing the wheel known normally as packages, and (ii) is it worth it just for the ./configure && makers? Or we could agree only to bundle stuff that does not introduce any new dependencies. - Download size. (Although, globally, this is reduced, by not multiplying copies of COPYING, ltmain.sh, texinfo.tex etc.) _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Adding stuff to the core distro (was Re: Infix syntax) 2002-10-13 14:27 ` Neil Jerram @ 2002-10-17 1:25 ` Daniel Skarda 2002-10-19 10:56 ` Neil Jerram 0 siblings, 1 reply; 31+ messages in thread From: Daniel Skarda @ 2002-10-17 1:25 UTC (permalink / raw) Cc: guile-devel Neil Jerram <neil@ossau.uklinux.net> writes: > Daniel> * Read "guile-debugger" thread on guile-devel. Even > Daniel> developers have not known that there is guile-debugger > Daniel> package. > > In this case, though, the package is still new and possibly not ready > for the core. In my opinion it should go to CVS - development HEAD or new branch. Inclusion would accelerate both acceptance and development of guile- debugger (IMHO). > etc. Note that, if this logic is correct, distribution package > users will always end up seeing lots of small packages, even if > coming from a single Guile distribution. Yes, I understand. There are going to be a lot of small packages anyway. But I still do not see the reason why you also want to scatter and slow down Guile _development_? > It might be fun to have a flexible build that allowed to build all > these pieces from a single distribution, but (i) would we just be > reinventing the wheel known normally as packages, and (ii) is it > worth it just for the ./configure && makers? Single distribution (or one big development pot) means for me as a developer of Guile application many important things: * Everything in that distribution works together. Otherwise I have to figure out which versions work together. I have to know that guile-foo-x.y depends on guile-x.y, guile-bar-a.b depends on guile-foo-c.d and guile-e.f. Also I have to remember that guile-x.y does not have function scm_foo and I have to write many ifdefs. Also I should not forget that somewhere between 1.2 and 1.6 gh_scm2newstr changed behaviour ... * Everything is released together. Suppose that there is brand-new guile-20.0 and Guile-Foo. Latest stable release of Guile-Foo is for guile-18.6.1, there is a version of Guile-Foo for guile-20.0, but only in Guile-Foo CVS. Now suppose my project depends on Guile and Guile-Foo. If I want to release new version with new features that rely on features found in Guile-20.0, I have to wait until Guile-Foo maintainer release new Guile-Foo. * Everything that is "inside" will not accidentally orphanate. Older package gets more "deprecated" warnings than newer package. It would be pity to lost some package just because nobody renamed scm_foo to scm_c_foo ... May be we should distinguish Guile (as in libguile or guile-core) and GUILE as a development platform (all guile-foo packages together). Maybe what I am calling for is not "one big Guile" (Guile == GUILE), but more organised GUILE - some policy for GUILE development. My proposal: * release often, release regularly * release together. Think GNOME - there are many big packages, but they form together one development platform. You develop for GNOME (or GNOME2), not for libfoo-x.y, libbar-a.b,.... Do you think that Guile != GUILE? Is GUILE necessary or is it just my crazy dream? What do you see as the most needed GUILE policy? Thank you for your opinions, 0. _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Adding stuff to the core distro (was Re: Infix syntax) 2002-10-17 1:25 ` Daniel Skarda @ 2002-10-19 10:56 ` Neil Jerram 0 siblings, 0 replies; 31+ messages in thread From: Neil Jerram @ 2002-10-19 10:56 UTC (permalink / raw) Cc: guile-devel >>>>> "Daniel" == Daniel Skarda <0rfelyus@ucw.cz> writes: Daniel> Neil Jerram <neil@ossau.uklinux.net> writes: Daniel> * Read "guile-debugger" thread on guile-devel. Even Daniel> developers have not known that there is guile-debugger Daniel> package. >> >> In this case, though, the package is still new and possibly not ready >> for the core. Daniel> In my opinion it should go to CVS - development HEAD or new branch. Daniel> Inclusion would accelerate both acceptance and development of guile- Daniel> debugger (IMHO). I'm convinced. Unless anyone objects soonish, I'll merge guile-debugger into core CVS over the next week or so. Neil _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 31+ messages in thread
end of thread, other threads:[~2002-10-21 18:21 UTC | newest] Thread overview: 31+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2002-10-03 11:26 Infix syntax Daniel Skarda 2002-10-05 8:55 ` Neil Jerram 2002-10-06 8:05 ` Daniel Skarda 2002-10-08 21:51 ` Adding stuff to the core distro (was Re: Infix syntax) Neil Jerram 2002-10-08 22:40 ` Han-Wen Nienhuys 2002-10-09 3:30 ` Rob Browning 2002-10-09 18:15 ` Neil Jerram 2002-10-09 20:17 ` Rob Browning 2002-10-10 12:20 ` Daniel Skarda 2002-10-10 12:29 ` Daniel Skarda 2002-10-13 14:28 ` Neil Jerram 2002-10-16 21:35 ` Daniel Skarda 2002-10-19 4:50 ` tomas 2002-10-20 19:15 ` Daniel Skarda 2002-10-21 9:36 ` tomas 2002-10-21 18:21 ` Neil Jerram 2002-10-19 22:17 ` Christopher Cramer 2002-10-20 19:05 ` Daniel Skarda 2002-10-10 16:06 ` Daniel Skarda 2002-10-10 17:12 ` Rob Browning 2002-10-10 18:46 ` Clinton Ebadi 2002-10-10 22:24 ` Lynn Winebarger 2002-10-13 15:09 ` Proposal for scope of core distro Neil Jerram 2002-10-17 0:10 ` Adding stuff to the core distro (was Re: Infix syntax) Daniel Skarda 2002-10-18 7:24 ` Lynn Winebarger 2002-10-20 20:25 ` Daniel Skarda 2002-10-10 18:08 ` Bill Gribble 2002-10-17 2:42 ` Daniel Skarda 2002-10-13 14:27 ` Neil Jerram 2002-10-17 1:25 ` Daniel Skarda 2002-10-19 10:56 ` Neil Jerram
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).