🚀 go-pugleaf

Dan writes (following up to Steve's message):

   > This program read a file of syllables and printed out "passwords" composed
   > from three random syllables.

   sed 's/$/XXXXXXXXXX/' | travesty -s -o10 | ... Sorry, couldn't resist.

   >     define program();             ;;; build a list of syllables
   >         lvars syllables = 'syllables'.discin.incharline.pdtolist;
   >         repeat 3 times
   >             syllables.oneof.pr    ;;; print a syllable 3 times
   >         endrepeat;
   >         nl( 1 );                  ;;; throw 1 new line
   >     enddefine;

   Fine, this is sort of example I was looking for. I claim that the
   conciseness of this program comes from the libraries available, not from
   the dynamic typing.

   #include <stdio.h>
   #include "sop.h"
   #include "strinf.h"
   main() {
   SOP(strinf) *syl; strinf *s; int i; syl = SOPempty(strinf);
   while (s = strinfgets(stdin)) { strinfchop(s); SOPadd(syl,s,strinf); }
   for (i = 0;i < 3;++i) puts(strinftos(SOPrandpick(syl,strinf)));
   putchar('\n');
   }

   (Yes, I admit I stole the name and concept of strinfchop from Perl.)
   Here strinf is a library for handling arbitrary-length strings, and sop
   is a generic set-of-pointers library.

   Surely you agree that, syntax aside, the C and Pop11 versions work the
   same way to accomplish the same results. The difference? I get better
   type checking and almost certainly better efficiency. For longer
   programs this means better turnaround time.

Since neither Steve nor Dan has chosen to enlighten us as to the meanings of
the identifiers used, how are we supposed to know that they are ``the same''?
(Close watchers ill not that I do in fact know what the Pop routines are, but
that's not the point).

I do note that Dan's example had to be all squashed up to fit in a similar
amount of space; laid out in a similar style it would take another five or so
lines. It's not clear that Dan gets ``better'' type-checking: Steve's code
works if -syllables- is a list or a vector, for example.

Dan certainly gets better efficiency: -oneof- is slow on lists (because
-length- and indexing are slow on lists). Given Steve's propensity for
speed-hacking, I'm surprised he didn't write the definition of -syllables- as

    lvars syllables = {% 'syllables'.discin.incharline.pdtolist.dl %};

to generate a vector rather than a list. Still, if we're only going round three
times, it hardly matters, does it? [Perhaps Steve should add -pdtovec- to our
local library.]

Maybe we should stop muttering about static vs dynamic typing and instead look
to the *real* issue here: how would one capture the advantages of the
dynamically typed systems that David is advocating but still be able to
typecheck at compile-time? It's pretty clear (to me, at least) that some notion
of sub-typing would be required, but I suspect that means run-time checks are
needed after all. [Note for object enthusiasts: classes are NOT types.] ML
doesn't cut it as it stands.

Perhaps David should show us some examples where he thinks dynamic types are
``essential'' and we should attempt to devise type systems that capture that
information at compile-time in a reasonablly checkable way. Perhaps Dan should
present examples where static typing is all that's required - or, contrariwise,
where even he would like more looseness in the type system.

And please bear in mind that C is hardly a good example of a statically typed
system....

--

Regards, Kers.      | "You're better off  not dreaming of  the things to come;
Caravan:            | Dreams  are always ending  far too soon."