I figured out the problem with include-program*. The problem is that include* only accepts relative paths, while include-program* expands to this (on gambit):
(begin (define _snow:program-filename "test1.scm") (define _snow:cleanup-handlers '()) (define (_snow:cleanup-handler-push! thunk) (set! _snow:cleanup-handlers (cons thunk _snow:cleanup-handlers))) (define (_snow:cleanup) (let ((handlers _snow:cleanup-handlers)) (set! _snow:cleanup-handlers '()) (for-each (lambda (h) (h)) handlers))) (include* "/usr/share/snow/v1.1.0/pack/snowlib/v1.0.1/snow/snowlib.scm") (include* "test1.scm") (_snow:cleanup))
So there's a line which includes the snow runtime library with an absolute path. Here's the what include* does though:
(define^ (_snow:expand-macro-include* filename) (_snow:generate-include (_snow:parse-unix-relative-path-string filename)))
And parse-unix-relative-path-string does this:
(define^ (_snow:parse-unix-relative-path-string str) (if (or (= 0 (string-length str)) (char=? #/ (string-ref str 0)) (char=? #/ (string-ref str (- (string-length str) 1)))) #f (let loop1 ((i 0) (rev-path '())) ....
which returns false if the string starts with the '/' character (any absolute path). The load macro doesn't do this, it accepts any filename:
(define^ (_snow:expand-macro-load* filename) (_snow:generate-load filename))
Is there a reason why include* forces the filename to be relative?
On 8/16/07, James Long longster@gmail.com wrote:
Sure, it uses the underlying module system of the host. That's to be expected.
What I want is a *portable* fully qualified name. It's pretty much useless to use snow and to use a host-specific fully qualified name to resolve conflicts.
I'm a little dissapointed that Snow focuses so heavily on loadable modules, while it wouldn't be hard to make packages slightly more usable as a namespacing mechanism as well. How this relates to releasing Snow packages publicly, I'm not sure, but I'd love to use Snow for namespaces because much of the code is similar. Maybe a real 'package' could be built with several namespaces and simply provide the interface. Namespaces are just for semantically separating code after all.
So, I would love to see a portable fully qualified name syntax, as well as something like a package-namespace* macro. These are things which I may build as extensions to Snow. What's everyone think about this?
On 8/16/07, Etienne Laurin laurieti@iro.umontreal.ca wrote:
On Thu, Aug 16, 2007 at 11:31:59AM -0400, andrew cooke wrote:
Also, how does Snow handling naming conflicts?
can't answer your other questions, but as far as i can see there's no namepsace support for snow modules. code seems to use "hopefully unique" prefixes (myproject-function-name ...). i was surprised by this - seems to be the biggest omission given the other things snow fixes - so perhaps i am wrong...
Snow uses a different namespace for each package in gambit and chicken:
(load-program* pi/v1) (pp (lambda () (pi-digits 4)))
(lambda () (pi/v1#pi-digits 4))
Etienne Laurin _______________________________________________ Snow-users-list mailing list Snow-users-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/snow-users-list
-- James L Indium Studios, Inc. Graphics Programmer longster@gmail.com http://okono.chattablogs.com/