🚀 go-pugleaf

In article  <27388@nigel.ee.udel.edu> carroll@udel.edu (Mark Carroll <MC>) writes:
>In article <Aug.14.07.41.57.1990.21197@paul.rutgers.edu>,
>>That's a problem in distribution, not definition...
>
>Actually, it's a problem in definition. If the language claims to be
>"universal", but actually requires you to generate non-standard local
>packages to do any useful programming, then it isn't really universal.

I believe the idea is to have lots of standard packages available, and
to have some sort of standards and distribution system that
continually updates packages.  This is really just a formalization of
the process of natural language evolution.  I expect that a universal
programming language will have to be more formal than a natural
language, at least in a few details...

>Routines/modules/packages from other languages would be called with the
>use of constructs proper to the language in use. So a call to routine A
>written in Pascal will look like a call to function A in ML.

This is more-or-less the way things are heading now.  The problem is
that it requires programmers to know dozens of different languages
with different syntaxes, different special-cases, and many different
obscure rules.  "Lets's see, does Ada use FOR or LOOP for that
construction?", "do I seperate the fields with comma or semicolon?",
"Can I alias the arguments to that procedure?".  What a nightmare.
And the majority of these rule differences are arbitrary, making them
even harder to remember.

>How can we realisticly unify the models of Pascal, Smalltalk, and ML?

It's been pretty much done already, since Smalltalk subsumes both
Pascal and ML (modulo built-in functions that are present in ML but
not in Smalltalk).

>If, as a part of a program, I have something equivalent to an ML functor
>exporting a binary tree package, those binary trees are immutable. To
>switch views as you seem to be suggesting will suddenly take my well debugged
>ML module, and introduce bugs - because the ML program cannot possibly
>copy with non-functional programs altering its structures. 

Why not?  It is trivial to implement applicative data structures in
Smalltalk (or almost any other non-applicative language for that
matter).  The fact that non-applicative data is available does not
effect the nature of an applicative ADT.

>Or, suppose I write a log routine in a language like Prolog. How, within
>the structure of a single language, can I make imperative parts of the
>program handle backtracking?

Icon is an imperative language with backtracking.  It is a beautiful
example of how dissimilar paradigms can be combined.
-- 
					David Gudeman
Department of Computer Science
The University of Arizona        gudeman@cs.arizona.edu
Tucson, AZ 85721                 noao!arizona!gudeman