using haskell as a shell language

[Juan Carlos Arevalo-Baeza]

On Tue, 6 Nov 2001 03:42:51 +0000 (GMT), D. Tweed wrote:

>The name that
>gets passed to the interpreter is `the top-level name of the=
 script', so
>if /home/tweed/bin/myscript.hs is actually a symlink to
>/home/tweed/src/haskell/myscript.hs and I invoke it from=
 /home/tweed/odd/
>with ../bin/myscript.hs, what gets passed is=
 "../bin/myscript.hs" (at
>least under bash on linux). So whilst the interpreter could in=
 principle
>get to thinking it should look in /home/tweed/bin/ for imports=
 by applying
>"../bin/myscript.hs" to $cwd, AFAICS there's no way it can get=
 hold of the
>directory /home/tweed/src/haskell. When I figured this out I=
 just decided
>that the method that would lead to least banging of my head=
 against wall
>was just to absolute path any imports of non standard=
 distribution code.

   Well... I still disagree. From my point of view, it could be=
 argued the order in which directories are searched for modules,=
 but I don't think there's any need to exclude any directories.=
 The interpreter should search not just the current directory,=
 but also the directory of the file where the source was found.=
 At least. I'd even add subdirectories "./modules/" (or=
 "./haskell.modules/" or something like that) of both of them,=
 just for added value :)

   IMHO, there's no reason not to search a reasonable place for a=
 needed piece of information. It's like Koenig lookups in C++. It=
 just makes sense to look there, just in case.

>>=A0=A0Is this behavior specified in the Report? And what's the=
 rationale for using it? I mean, not even GCC uses this kind of=
 thing (in fact the C/C++ standards specify the proper search=
 order for #includes).
>
>I guess unix symlinks make handling imports automatically=
 impossible, so
>at least on some platforms handling things automatically can't=
 be
>specified by the report.

   Yes, I understand that this can make matters a little more=
 convoluted. I'm just advocating for flexibility here. You lose a=
 bit of predictability in exchange for much flexibility. Maybe=
 that's a price you don't want to pay, but I sure would.

   And if not standard, this makes sense, at least, as a=
 toggleable switch.

   Anyway... This is not my war. Just my opinion. O:-)

   Salutaciones,
                        JCAB
email: jcab@roningames.com
ICQ: 101728263
The Rumblings are back: http://www.JCABs-Rumblings.com