Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!ncar!noao!arizona!gudeman From: gudeman@cs.arizona.edu (David Gudeman) Newsgroups: comp.lang.misc Subject: Re: The Universal Language Message-ID: <24281@megaron.cs.arizona.edu> Date: 16 Aug 90 19:40:28 GMT Organization: U of Arizona CS Dept, Tucson Lines: 56 In article <27388@nigel.ee.udel.edu> carroll@udel.edu (Mark Carroll ) writes: >In article , >>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