* 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-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 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 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
* 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-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
* 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-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-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-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-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-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-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-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
* 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-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-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-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
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).