Re: [Chicken-hackers] [PATCH] add pathname-expand

[Peter Bex]

On Thu, Nov 14, 2013 at 12:24:26PM +0100, Felix Winkelmann wrote:
> >>
> >> Well, if it is such a can of worms, then perhaps it's not such a great
> >> thing to have, after all. There are so many special cases and platform
> >> dependencies, that it actually confuses more than it helps.
> > 
> > Getting rid of it is the simplest approach.  There are other ones,
> > though.  Here are some of them:
> > 
> > * move pathname-expand to an egg.  From users standpoint, I think it
> >   won't make a big difference between having pathname-expand in the core
> >   or in an egg.  It's something new anyway.  Having it as an egg can
> >   actually be a win in the end: it would be available to older chickens
> >   (although it wouldn't do anything, since pathname expansion is
> >   implicit).  But at least applications wouldn't break on an "Unbound
> >   variable: pathname-expand" error.  If pathname-expand is in the core,
> >   programs that use it will have a hard dependency on CHICKEN 4.9.0.
> 
> Makes sense.

Same here.  Let's deprecate it, move it to an egg and get rid of the
damn thing in 4.10.0.

> > * make it simpler.  Only expand ~/user.  No ~user and no ~~whatever.
> 
> Also makes sense.

Not sure, but it might be enough for most uses.

> > * to work around the issue "what to do when home cannot be determined",
> >   an additional parameter to determine the default home directory (a
> >   string) or behavior (a procedure).  Example:
> > 
> >   (define default-user-home-directory
> >     (make-parameter "/"))
> > 
> >   (define (pathname-expand path)
> >     (if (home-is-defined?)
> >         (do-expand path)
> >         (if (procedure? (default-user-home-directory))
> >             ((default-user-home-directory) path)
> >             (do-expand path (default-user-home-directory)))))
> > 
> >   If default-user-home-directory can be a procedure, users may 
> >   decide what to do when no home is defined.
> 
> Hm. One more option. I'm not sure if this isn't perhaps too much choice.

I also think this is overkill.  Having it as a string parameter is a
good idea though!  Maybe allow it to be #f to indicate an exception must
be thrown for paranoid people like me.

> > Personally, I'd vote for leaving it out of the core and eventually
> > implement it as an egg, when we have a consensus on what it should do.
> 
> Good idea.

Yeah, then it can evolve at its own pace.

Cheers,
Peter
-- 
http://www.more-magic.net