Re: [q-lang-users] Two proposed improvements to Q

[John C. <co...@cc...>]

Albert Graef scripsit:

> Well, considering namespace pollution, clib is probably the worst single
> offender. But starting the interpreter with the full library takes some
> 0.35 secs on my devel box (Athlon 2500+ running Linux, so not really a
> fast computer by today's standards), and clib takes maybe 0.12 secs from
> that. So I don't know whether it's really worth the hassle.

Startup is rather slower on my Cygwin-based laptop:  comparing average
wall-clock times for "q </dev/null" and "q --no-prelude </dev/null"
gives me a library load time of 1.8 seconds, long enough to be quite
annoying (the interpreter itself starts up in just 0.12 seconds).

> Still, by unbundling *both* the POSIX interface part of clib (maybe
> moving that to a system.q module, along with the stuff in getopt.q) and
> stdtypes.q from the prelude, we might be able to shave off almost 80% of
> the interpreter's default startup time and clean up the namespace
> considerably. Could be worth the hassle after all. 

I'd agree with factoring Clib into Posix and non-Posix parts.
For the rest, I'd remove everythin in prelude.q except the library
includes to another file, and then people can include or exclude
whatever they like just by changing prelude.q.  That would preserve
backward compatibility but make it easy to change a local installation.

> What does everybody else think about this? Are you all running little Q
> scripts in tight loops from the shell, or do you rather use them
> interactively? I.e., how do you want your prelude: "slim" or "fat"? :)

I tend to start Q with a small script and then evaluate a few
expressions, then shut down, using Q as a sort of more-capable
calculator.

-- 
The experiences of the past show                John Cowan
that there has always been a discrepancy        co...@cc...
between plans and performance.                  http://www.ccil.org/~cowan
        --Emperor Hirohito, August 1945