'canonical' library-set ?

I think I read sometime ago that [perhaps unix/C] designed a set/s of
library/s, intended to be a minimal but sufficient set to do 'any' task ?
But that it is not widely accepted.

So eg. for strings, you might have:
* return position of substring in string, else zero;
...
* insert substring in string at position;
... etc.

I imagine programming then being mostly a matter of
selecting procedures/function out of the library ?

So you've moved the problem to navigating the library ?

Which would be heirarchically arranged ?
eg. > strings > insert > args-description .... ?

Perhaps java-programmers do this by 'browsing' the methods of classes ?
Does it work ?

This query is prompted by an attempt to read some forth code;
where a dictionary of fields:
<forthWord> : <text explanation>
would be usefull.

But then why not just structure the dictionary as a heirarchy, where
you can browse the <text explanation> to get the <forthWord> ?

Such visual tools WORK for me, eg. mc, but many prefer to
'remember instead of just recognize' . I think it gives them a
childish feeling of power: the motive to resist deskilling.

Ideas ?

== Chris Glur.

I am not sure I understand what you are asking...

On Mar 26, 3:01 am, problems@gmail wrote:
> I think I read sometime ago that [perhaps unix/C] designed a set/s of
> library/s, intended to be a minimal but sufficient set to do 'any' task ?
> But that it is not widely accepted.

Are you thinking of something specific? Both the C standard runtime
library and the Java runtime / component library (among many, many
others -- just using those two as an example, since you mentioned them
both) could be described as sufficient to do 'any' task.

> I imagine programming then being mostly a matter of
> selecting procedures/function out of the library ?
>
> So you've moved the problem to navigating the library ?

Well, I mean, "navigating" the C and Java runtime libraries would
consist of "reading the documentation"... unless you mean something
else?

> Which would be heirarchically arranged ?
> eg. > strings > insert > args-description .... ?

The Java API documentation is fairly well organized...

> Perhaps java-programmers do this by 'browsing' the methods of classes ?

I think they do this by reading the documentation. If you mean
browsing methods of classes programmatically, this is part of a
feature called "reflection" -- some languages have this feature (such
as Java), others do not... but I don't see how reflection helps you
out here (what are you trying to do?).

> Does it work ?

Depends on how good they are at reading. :-)

> This query is prompted by an attempt to read some forth code;
> where a dictionary of fields:
>     <forthWord> : <text explanation>
> would be usefull.

You mean, if the Forth programmer had documented the words they
defined?

> But then why not just structure the dictionary as a heirarchy, where
> you can browse the <text explanation> to get the <forthWord> ?

A hierarchy? This is more a simple table... where you can browse the
text explanations. There is no hierarchy, unless I'm misunderstanding
you. You could accomplish this, for example, by simply entering the
forth words and their text descriptions in, say, an Excel spreadsheet,
and visually browsing through it or using the find feature to search
for specific text. What are you asking?

> Such visual tools WORK for me, eg. mc, but many prefer to
> 'remember instead of just recognize' . I think it gives them a
> childish feeling of power: the motive to resist deskilling.

What does this mean? That you want to remember what your Forth words
do without having to consult the documentation every time you
encounter a word? That will happen once you consult your dictionary
enough times.

How does that all that fit in with the string processing you had
mentioned? Are you trying to generate documentation from Forth code?
Are you trying to parse some sort of word dictionary and present the
information in a way that isn't just a table of words and
definitions?

> Ideas ?

It seems I may be misunderstanding what you are asking... but it is
pretty late at night. Can you be more specific?

Jason

Responding to problems...

> I think I read sometime ago that [perhaps unix/C] designed a set/s of
> library/s, intended to be a minimal but sufficient set to do 'any' task ?
> But that it is not widely accepted.
>
> So eg. for strings, you might have:
> * return position of substring in string, else zero;
> ...
> * insert substring in string at position;
> ... etc.
>
> I imagine programming then being mostly a matter of
> selecting procedures/function out of the library ?
>
> So you've moved the problem to navigating the library ?
>
> Which would be heirarchically arranged ?
> eg. > strings > insert > args-description .... ?

Yes -- if you are programming in a procedural or functional language
this sort of functional decomposition was the basis of Structured
Development and it is the most intuitive way to build complex modules
from atomic functional elements like language operators or library
functions.

> Perhaps java-programmers do this by 'browsing' the methods of classes ?

Not really. OO development uses a completely different paradigm for
developing program structure. In fact, one can argue that the main goal
of OO development is to avoid the hierarchical dependencies usually
associated with functional decomposition. Instead, the OO paradigm
creates software elements by direct abstraction of problem space
entities and those elements collaborate on a peer-to-peer basis to solve
the problem in hand. The browsers provided by the language IDEs are
primarily a tool for navigating the program structure once it has been
defined.


--
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development".  Email
info@pathfindermda.com for your copy.
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH

On Mar 26, 3:01 am, problems@gmail wrote:
> I think I read sometime ago that [perhaps unix/C] designed a set/s of
> library/s, intended to be a minimal but sufficient set to do 'any' task ?
> But that it is not widely accepted.

> So eg. for strings, you might have:
> * return position of substring in string, else zero;
> ...
> * insert substring in string at position;
> ... etc.

> I imagine programming then being mostly a matter of
> selecting procedures/function out of the library ?

The thing is, when you have that low level set of libraries, there can
still be a lot of design work to be done to get a set of capabilities
that works smoothly together for a particular task. And when that
design work is done, and put into a library in turn, people will start
borrowing from that higher level library for something where it
*almost* fits, and often add in the hook needed to make it fit better
than it did originally ... and that higher level library starts to
take a life of its own, based on the history of uses to which it was
put.

And somebody comes along and say, "look at this pile of encrustations
and barnacles that have been added to make this thing a jack of all
trade, master of none", and goes about rebuilding a library from
scratch to do one thing and do it well (and of course under their view
of what "well done" counts for in that area), and around it goes.

And of course, maybe they are a firm believer in the canonical library
system and rebuild on top of the canonical library, and maybe they
aren't, and they build from scratch, or on the basis of some other
library that they think is more effective for their area of concern.

However, its clear that effective library browsing technology is going
to be useful in any part of that library life cycle.

Have you looked at how one of the commercial Forth's goes about it?
Both of the commercial Forth houses have been working with the task of
providing effective access to their bundled libraries for quite a
while now, so they have certainly learned some lessons on usability
along the way.