[Peter Newman] 8 January 2005 ----------------------- [Unified Programming Language]

'''Multiple Languages'''

One-eyed Tcl'ers will note the sacrilege at the top of the example [UPL: The Bootstrap File]. What are Perl and Python (etc) interpreters doing there?

Simple; this is the "Unified Programming Language". It's for idiots like me who think that there's no such thing as the perfect programming language (although every programmer probably has his or her preference(s)). 

But UPL is built on the assumption that every programming language has its advantages and disadvantages. And we want the script level programmer to be free to:-

   1. Take data types - commands/functions - and even syntax and quoting rules etc - from other languages, as they see fit, and:-

   2. To be able to script a single application in whatever combination of languages/syntaxes they want, and;

   3. For programmers to be able to invent new quoting rules and syntaxes - and ways of expressing the solution to programming problems, etc - as they see fit.

So not only only can the script-level programmer select the data types and command/functions from their `traditional' programming language of preference (Tcl, Perl Python, C, etc), they can also:-

   * Select data types and commands/functions from other programming languages, and/or;

   * Load a parser/interpreter that will parse '''the UPL version''' of any combination of those other languages too.

----
[jcw] - Interesting idea.  For syntax differences, I see no roadblocks ahead.  But how will you deal with differences in the data & execution model?  Tcl's copy on write vs. Python's mutable/immutable/references?  That a string can be treated as an int or a list in Tcl but not in Python?  Garbage collection versus plain C?  The fact that Python has a "None" datatype?  It'd be fascinating if this can be resolved somehow.  Also, IMO, the main benefits will come when one can adopt library packages from other languages, so as not to have to re-invent all wheels - can UPL end up close enough to any current language to run the reams of existing code there is today (perhaps with minor adjustments)?

[RS] A parser that grows by loaded languages is a formidable idea indeed - however, there are ambiguous cases. Say we loaded both Tcl and Python parsers, what would they do with
 set = 0
This is an assignment in both languages, but Tcl would assign 0 to '''=''', while Python would assign to the variable '''set'''...

[IL] isn't this similar to something .net provides?  i think what they had the languages do was adopt a common specification to be scripting compliant.  i'm guessing thats how it resolved the data type issues... dunno though, i tend to stay away from learning ms technologies...

----
[LV] So basically you are saying that in the end, I might have a program that read like this?

   # First some JCL
  //step10 dd dsn=/home/lvirden/mystuff.txt,
  //              alloc=((100,100), 1000)

  # Now some ksh/bash
  lst=$(ls ~/*.txt)

  # Now some Tcl
  foreach i $lst {
        # Now a pipeline which mixes tcl, ksh notation
        j=`ls -l $i | lindex - 1`
        puts stdout $j
  }

----
[Category Discussion]