[Snow-users-list] include* only relative? (was: include-program* usage)

James Long longster at gmail.com
Sat Aug 18 22:02:05 EDT 2007


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 at 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 at 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 at iro.umontreal.ca
> > https://webmail.iro.umontreal.ca/mailman/listinfo/snow-users-list
> >
>
>
> --
> James L
> Indium Studios, Inc.
> Graphics Programmer
> longster at gmail.com
> http://okono.chattablogs.com/
>


-- 
James Long
Coptix, Inc.
longster at gmail.com


More information about the Snow-users-list mailing list