Just about to reply to your earlier comments. For which - many thanks.
They are helpful.

> Zulu though... why would I want to "convert a string"?

Yes that's a typo. Should be Stringlist Conversion Package.
...but the thing is, "stringlist" is a neologism in the J context.

> There should be some standard way of loading the base functionality
> without emitting any messages.

Yes definitely.
...And that awful message must come out:
+++ zulu-lite --loaded.

> Also, I think that the sample data does not belong in a separate
> package, and should not be loaded when the package is loaded.

As an experienced programmer I'd agree. It was what I first thought.

But what's uppermost in my mind is the inexperienced J user who is
trying to build something useful. The first point of contact will be
the main way s/he will use it, probably for a long time to come. So I
see the prime way-in being:
   require 'format/zulu'
which will get the Sandbox by default.

It's no big deal to have Sandbox (_zulu_) lurking around unused. By
today's lights it doesn't take up much space...

   7!:6 <'zulu'
28000

But a professional developer would think it untidy to ship it in
released code. Some developers still strip comments before release :-)

As it happens, there's no strict need for zulu-lite as a separate
addon. The same effect can be achieved by:
   load 'format/zulu'
   coerase <'zulu'

It's really there to allow me to give it its own Lab, and so package
it up for a different audience.

Addon: zulu-bare is a different kettle of fish, because it needs to be
loaded standalone, and actually unloads format/zulu first. It's aimed
at the coder who wants to run lean'n'mean. Who might be better off
copy/pasting words straight out of format/zuv.ijs. Like zulu-lite it's
really there to allow me to give it its own Lab. Which saves having to
mention it in novice circles, where it would only confuse and
distress.

Yes, I too would like to combine the whole thing in one single addon.
You'll recall the extensive correspondence (17 posts) that followed my
original proposal to do just this, and how best to do it?
   http://www.jsoftware.com/pipermail/programming/2012-September/029259.html
The LAPACK way would be to keep separate "loader" scripts in
format/zulu and run them like this:
   load 'format/zulu/lite'
   load 'format/zulu/bare'
...etc.
I can have as many loader scripts as I can fancy a need for. A lot
less trouble than releasing and maintaining three separate addons. But
I got the hint from the forum that using load/require in this way is
"untidy", and that the preferred programmer interface for using any
addon is quite simply:
   load 'category/addon'

Now I've shipped it, and we can all see the result, it's a lot easier
to decide whether or not we want it.

One last observation: I don't have evidence there's an audience for
zulu-lite and zulu-bare, as such. Why would anyone want access to
words like b2x (which is equivalent to: > in zulu-bare)  and x2x
(which is equivalent to: ])? The chief offering is format/zulu --and
that's aimed squarely and uncompromisingly at the novice.

Ian

On Tue, Sep 18, 2012 at 7:48 PM, Raul Miller <rauldmil...@gmail.com> wrote:
> I wrote:
>> So if it were me, I would:
>>
>> 1. Try to explain the purpose of the package (at least enough that a
>> user could look up the names).
>>
>> 2. Combine everything into one package.  To get the cut down variants,
>> it might be worthwhile describing somewhere what can be erased.
>
> After looking at it, I now think differently.
>
> There should be some standard way of loading the base functionality
> without emitting any messages.
>
> Also, I think that the sample data does not belong in a separate
> package, and should not be loaded when the package is loaded.
> Instead, it should be present in a file which can be optionally loaded
> (which is a part of the base package).
>
> At least... that is how I am currently thinking...
>
> --
> Raul
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm

Reply via email to