q-lang-users

[q-lang-users] Proposal for two minor rearrangements

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

(These arose out of my suggested revision of the documentation.)

1) Move the regex function (and possibly the low-level regex functions as well)
back into qlib.c.  Regular expressions are defined by Posix but aren't
in any way system-dependent.

2) Move the Q functions that are overridden by clib functions (documented
in 12.20) into the examples.  Currently they are loaded but then never used.

-- 
Unless it was by accident that I had            John Cowan
offended someone, I never apologized.           co...@cc...
        --Quentin Crisp                         http://www.ccil.org/~cowan

Re: [q-lang-users] Proposal for two minor rearrangements

[Albert G. <Dr....@t-...>]

John Cowan wrote:
> 1) Move the regex function (and possibly the low-level regex functions as well)
> back into qlib.c.  Regular expressions are defined by Posix but aren't
> in any way system-dependent.

Yes, in hindsight it seems much more convenient to have this in the
prelude. So I'm all for this change, but it's going to break existing
code. :( Does anyone object to this?

> 2) Move the Q functions that are overridden by clib functions (documented
> in 12.20) into the examples.  Currently they are loaded but then never used.

Hmm, these functions are there so that the library doesn't break if you
want/need to remove clib from the prelude. That should still be
possible, although I haven't checked it for a while. So I'd rather keep
them where they are. Any specific reason why you want them removed,
other than tidyness?

Albert

-- 
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email:  Dr....@t-..., ag...@mu...
WWW:    http://www.musikinformatik.uni-mainz.de/ag

Re: [q-lang-users] Proposal for two minor rearrangements

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

Albert Graef scripsit:

> > 2) Move the Q functions that are overridden by clib functions (documented
> > in 12.20) into the examples.  Currently they are loaded but then never used.
> 
> Hmm, these functions are there so that the library doesn't break if you
> want/need to remove clib from the prelude. That should still be
> possible, although I haven't checked it for a while. So I'd rather keep
> them where they are. Any specific reason why you want them removed,
> other than tidyness?
> 

I think it better for the code to break than to suddenly run 20 or 200
times slower because you excluded clib for some reason.  After all,
code will break if you exclude other standard modules, too.

-- 
John Cowan  co...@cc...   http://ccil.org/~cowan
Promises become binding when there is a meeting of the minds and consideration
is exchanged. So it was at King's Bench in common law England; so it was
under the common law in the American colonies; so it was through more than
two centuries of jurisprudence in this country; and so it is today.
       --Specht v. Netscape

Re: [q-lang-users] Proposal for two minor rearrangements

[Albert G. <Dr....@t-...>]

John Cowan wrote:
> I think it better for the code to break than to suddenly run 20 or 200
> times slower because you excluded clib for some reason.

I don't agree with that. If you're running without clib, it's a
conscious decision, and most users who want to do that for some reason
will probably prefer the rest of the standard library to just keep
working without having to jump through a lot of hoops.

> After all, code will break if you exclude other standard modules, too.

That's true, but the rest of the stdlib has been specifically designed
to not depend on clib. (Well, that's not 100% true any more, but AFAICS
it's just a single function from clib which is extended in rational.q,
and you can easily comment that one out.)

The rationale behind this is, if someone wants to port Q to some exotic
Gizmo XYZ device which doesn't have a full POSIX interface and thus clib
might not even compile there for some reason, then you still have the
option to make a minimal Q implementation work there, without much ado.
I think that this is important enough to justify the cost of having a
little cruft in the library (it's just a few definitions anyway).

However, if that's a real showstopper for anyone, then I could add a
--with(out)-clib option to the configury. Opinions?

Albert

-- 
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email:  Dr....@t-..., ag...@mu...
WWW:    http://www.musikinformatik.uni-mainz.de/ag

Re: [q-lang-users] Proposal for two minor rearrangements

[Rob H. <hub...@gm...>]

> John Cowan wrote:
> > I think it better for the code to break than to suddenly run 20 or 200
> > times slower because you excluded clib for some reason.

I think (2) would be a bad idea. Thus, I agree with Albert here.

Perhaps there's some argument for the user getting some indication (a
warning?) that Q "fall back" functions are being used. But as removal
of clib would be deliberate, perhaps there's little need for that.


Albert Graef wrote:
> However, if that's a real showstopper for anyone, then I could add a
> --with(out)-clib option to the configury. Opinions?

And/or --with(out)-qfallback ??

My opinion: these are worth doing only if very easy.


Rob.

Re: [q-lang-users] Proposal for two minor rearrangements

[Albert G. <Dr....@t-...>]

Rob Hubbard wrote:
> Perhaps there's some argument for the user getting some indication (a
> warning?) that Q "fall back" functions are being used.

That's not really a viable solution, as having fallback equations to
handle special cases of an operation whose core is defined as an
external is perfectly legitimate. The only way to make that work would
be to have some kind of "not supposed to be extended" markup in extern
declarations, which goes against Q's philosophy to allow extensions
a.k.a. overloading of any operation, even the builtins.

Albert

-- 
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email:  Dr....@t-..., ag...@mu...
WWW:    http://www.musikinformatik.uni-mainz.de/ag

Re: [q-lang-users] Proposal for two minor rearrangements

[Albert G. <Dr....@t-...>]

Albert Graef wrote:
> John Cowan wrote:
>> 1) Move the regex function (and possibly the low-level regex functions as well)
>> back into qlib.c.  Regular expressions are defined by Posix but aren't
>> in any way system-dependent.
> 
> Yes, in hindsight it seems much more convenient to have this in the
> prelude. So I'm all for this change, but it's going to break existing
> code. :( Does anyone object to this?

This is in cvs now as well. Actually I moved both regex et al and
fnmatch/glob back into clib. Note that this will break existing code
doing a qualified import of these routines.

I'm ready to release 7.11 RC1 now, stay tuned.

-- 
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email:  Dr....@t-..., ag...@mu...
WWW:    http://www.musikinformatik.uni-mainz.de/ag