🚀 go-pugleaf

In article <KERS.91Mar21130048@cdollin.hpl.hp.com> kers@hplb.hpl.hp.com (Chris Dollin) writes:
> 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.

Feh. Here are the two pieces of code, side by side, with a few changes
to fit a change in the strinf library and to show the parallels:

#include <stdio.h>
#include "sop.h"
#include "strinf.h"
main() {                             define program();
 strinf *s; int i;
 SOP(strinf) *syl;                   lvars syllables =
 syl = SOPempty(strinf);
 while (s = strinfgets(stdin)) {     'syllables'.discin.incharline.pdtolist;
   strinfchop(s);
   SOPadd(syl,s,strinf);
 }
 for (i = 0;i < 3;++i) {                     repeat 3 times
   puts(strinfs(SOPrandpick(syl,strinf)));   syllables.oneof.pr
 }                                           endrepeat;
 putchar('\n');                      nl( 1 );
}                                    enddefine;

Sure, the C version is longer: it #includes library header files (to
declare functions), and declares variables. But everything else is
parellel. I didn't define repeat or nl, and I didn't hide discin or
incharline inside a subroutine, but I'm sure we can all manage to pay
attention to the real issue rather than these syntactic trivialities.

The C code is no more complex than the original. End of example.

> It's not clear that Dan gets ``better'' type-checking: Steve's code
> works if -syllables- is a list or a vector, for example.

What's your point? I do get better typechecking: the compiler tells me
immediately that I haven't made any type errors. Given that it didn't
take me a significant amount of time to include the declarations, what
do I lose?

  [ speed ]

Actually, if I needed this program for something, I'd be more worried
about memory. I'd use one of the selection algorithms in Knuth to pick
three (or however many) random syllables from the list on the fly,
without having the whole thing in memory at once; then I'd output those
syllables in a random order. In any case, the superior speed of the C
version doesn't really matter given that it already provides superior
typechecking.

> 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?

*What* advantages? If any advantages exist, they certainly didn't matter
for this example.

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

It's adequate.

---Dan