Re: Python discussion, anybody?

["Stephen J. Turnbull" <turnbull@example.com>]

Sorry, it was late and I was working on a slow modem---frustration
leads you to write stupid things (forgivable) and post them (oops).

>>>>> "Todd" == Todd Rudick <trudick@example.com> writes:

    Todd> << As Peter Gabriel said, "I'm a LISP engine, baby, and I
    Todd> want your sexp!" It's a well-defined interface, no? >>

    Todd> Huh?

Hey, there's a whole hyperspec out there.  Well-defined.

    Todd>   Or, I'm thinking functions should have to specify their
    Todd> return type, always.

Ah.  Well, you're saying you want your scripting language to be
strongly typed then.  My point is that I want to deal with polymorphic
functions that accept "union" types as arguments, and return "union"
types as values.

    Todd> << the interface is the string, which is parsed to a
    Todd> sexp. >>

    Todd>   As I said, "eval" type expressions would be a problem, as
    Todd> they would be for many many quite ordinary compilation
    Todd> problems. I'd ignore them (which, for evaled definitions,
    Todd> might mean extra warnings. For evaled calls, you'd be in the
    Todd> normal 'see-what-happens-when-it-runs' mode that you expect
    Todd> from Python, Smalltalk, Perl, etc. for Lisp, I guess that
    Todd> means Lisp won't work)

I don't like the implications for SQL and other RDB or OODB
applications, which are really important.  Or do you see something I
don't see?  An SQL query looks pretty eval-ish to me; I would be
surprised if "SQL scripts" weren't Turing-complete.  (No one in their
right mind would use that as general programming language of choice,
of course.)

    Todd> If you really mean that Lisp treats everything as a String,
    Todd> even code, well..

No, LISP treats everything as an S-expression, more or less a binary
tree in most implementations.  It is not possible to distinguish code
and data by syntax.

AFAIK there are no LISP dialects where strings can be executable, but
I have used a LISP dialect where there were no strings, only symbol
names, and there was no distinction between numerals and other
symbols.  (All symbols had numerical value.)  So you could express the
normal LISP expression `(+ 1 1)' as `(1 + 1)' by assigning a function
definition (actually a LISP macro) to the symbol `1' which when
invoked recursively parsed the rest of the list as a stream of
operators and operands.  (Of course this gets pretty inefficient
pretty fast, since you'd have to define that function for every
number; the LISP engine didn't do it for you.)

You can do much the same thing with Python or Perl; ESR's article in
the Python attachment in Linux Journal (last May?) showed some
meta-programming in Python.

    Todd> Don't whing if this won't work with your favorite ksh
    Todd> object-oriented package, tcl, basic, or the like.

But that's exactly the point!  We were talking about polymorphic
scripting languages like Python, tcl, Perl.  I dunno BASIC, haven't
programmed in that in 20 years.

What you seem to be heading for is a strongly typed scripting language
(which seems to be nearly an oxymoron to me).  Every response you made
tightened the requirements on the declarations (even if they are
somehow implicit in definitions; I'm using the C++ distinction between
declaration and definition here).  You ignore eval, which seems to
rule out programs based on query languages.

Now, how about event-oriented programming?

enum event_t { A, B };
struct eventT { enum event_t type; };
struct eventA { enum event_t type; typeA a; };
struct eventB { enum event_t type; typeB b; };
union event { eventA ea; eventB eb; };

int main()
{
  while (1)
  {
    union event e = ReadEvent();
    
    switch (((struct eventT) e).type) {
    case A:
      funA ((struct eventA) e);
      break;
    case B:
      funB ((struct eventB) e);
      break;
    default:
      OhNO (e);
      break;
    }
  }
}

Well, you have a problem here.  This switch doesn't work, because you
don't plan to check execution paths.  As far as I can see, that means
you are going to require that struct eventB offer the entire struct
eventA interface as used in funA.

Of course you can special case this particular switch.  But as far as
I can see, to get a moderately general and efficient solution for the
event-driven programming paradigm, you're going to need to deal with
the algebra of types, and you have to check execution paths.  Oops,
undecidability (or intractibility, if you prefer) rears its ugly head
again.

So it comes down, again, to personal preference.  Do you want an
environment where most of the time the rules don't hinder you, and the
static checks catch almost all of your typos---but when you need to do
something complex, you have to break the rules or disable the checks.
Or do you want an environment where there are few rules, but the
grammar encourages you to write complex things naturally (and thus is
less error-prone)---but the very lack of rules makes typos and other
such brainos (much?) harder to catch when they _do_ occur?

-- 
University of Tsukuba                Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences       Tel/fax: +81 (298) 53-5091
_________________  _________________  _________________  _________________
What are those straight lines for?  "XEmacs rules."