If the CSS had been available from the start, things could have developed
  that way.  It is, however, far better design not to use explicit levels but
  rather nesting constructs.  The fact that these headings do not nest but
  sort of "float" in the overall body may have been a good idea to some people
  at some time, but it is generally only a recipe for abuse, which is also the
  development we have seen.

--
Erik Naggum, Oslo, Norway

On 16 Sep 2002, Software Scavenger wrote:

  sub combinations (&$@) {
    my ($code, $size) = (shift, shift);
    do_cmb($code, $size, [@_], []);
  }

  sub do_cmb {
    my ($c, $s, $set, $idx) = @_;
    if (@$idx == $s) { return $c->(@$set[@$idx]) }
    else {
      for my $i ((@$idx ? $idx->[-1] + 1 : 0) .. $#$set) {
        push @$idx, $i; &do_cmb; pop @$idx;
      }
    }
  }

If you want a detailed explanation, I can offer one.  The function is used
like so:

  combinations { print "(@_)\n" } 2, (1..5);

and the output would be:

  (1 2)
  (1 3)
  (1 4)
  (1 5)
  (2 3)
  (2 4)
  (2 5)
  (3 4)
  (3 5)
  (4 5)

  I believe the interesting difference is between languages that instruct a
  very general-purpose engine to do specific things for which it was explicitly
  designed or intended in the concrete sense on the one hand, and on the other
  languages that are mere input languages to specialized applications that
  affect how it does its one task, but cannot change that task in any useful
  way.  That is, HTML is a data language, while JavaScript is a programming
  language.

| The reason for this is that there is no sharp boundary between programming
| languages and "non-programming" languages

  Of course there is.  It is not clear a priori, however, in which category
  every language would fall.  There is a difference between fuzzy categories
  and things that do not fall neatly into only one of them.

| Someone who implements a parser generator doesn't see any real difference
| between HTML and "real" programming languages

  That is obviously because he deals with the syntax of the languages, not
  their semantics.  Just as one who implements a file transfer protocol does
  not see any real difference between HTML files and images.

--
Erik Naggum, Oslo, Norway

There are also many myths of programming that many take as rules. Code
Complete dispels many of those myths.

  I quite agree, but the cost of the transition will be considerable.  The only
  good things about the Web are that web pages are rewritten and applications
  scrapped at an alarming rate even in our current recession and that there is
  apparently no resistance to any kind of design in the community as long as
  they can get their desired visual results.  Such a pragmatic focus may be a
  good foundation for making the necessary changes relatively quickly.

--
Erik Naggum, Oslo, Norway

That's interesting, but not quite as good as independent features.  Please
correct me if I'm wrong, but I assume that the Dewey system (and the others
you've mentioned) are designed for physical objects like books, where each item
belongs in exactly one place.

With online systems, it would seem much better to label each data item with
a whole set of applicable features, and then basically navigate through the
hierarchy by doing searches and building virtual indexes.  In such a scheme,
a given object might appear at numerous "leafs" in the classification tree,
rather than only one.

Do Dewey systems already allow for this somehow?  Or do you think the idea that
an item might not have a unique classification is misguided?

  Yes.  Geography and audience are particularly well-utilized examples.  E.g.,
  a book about Indiana high-school women's basketball would be classified
  under sports, basketball, pre-college, in Indiana, for women.  A book about
  cats for children would be classified under cats, intended for children.

| Please correct me if I'm wrong, but I assume that the Dewey system (and the
| others you've mentioned) are designed for physical objects like books, where
| each item belongs in exactly one place.

  Yes, the books would be in one place, but you would obviously have multiple
  index cards for them if they were cross-classified.  It is useful to find
  related items grouped in the bookshelves, but this is a consequence of the
  nature of bookshelves, not of the classification.

| With online systems, it would seem much better to label each data item with
| a whole set of applicable features, and then basically navigate through the
| hierarchy by doing searches and building virtual indexes.  In such a scheme,
| a given object might appear at numerous "leafs" in the classification tree,
| rather than only one.

  This is already the case.  I have several books that are cross-classified.

| Do Dewey systems already allow for this somehow?  Or do you think the idea
| that an item might not have a unique classification is misguided?

  I think you have assumed that a classified item has only one classification.
  This is false.  It must have one, and the better it is, the more useful that
  one is, but if a book covers some more than subject, there is nothing to
  stop it from getting several classifications.  (Unless, of course, it is a
  "general collection", where the classifiers basically give up on it with the
  assumption that people would not look for it under any specific area.

--
Erik Naggum, Oslo, Norway

        Henry

        Henry

--

My CL version is a macro which builds nested loops, so there is no
need for it to call any functions at run time, recursive or not.  I'm
curious to know if Perl has macros, or if it makes sense for a Perl
program to rewrite Perl code in some situations.

I also wonder if that "print" block of code in your Perl code is a
closure.  If outside of the call to combinations, you were to define a
number of local variables, and in the block, you were to add code
which used those, would it work, even though it would be executed by
combinations rather than in line?

i.e.
  combinations { print "(@_)\n" } 2, (1..5);
               ^  block of code ^
  (add other code inside the same block, and use variables defined
outside)

    Alain> And fear!  Fear, and surprise.  :-)

Regards,
--
Nils Goesche
"Don't ask for whom the <CTRL-G> tolls."