[Swift-devel] Scala

[Michael Wilde]

I believe rather than examining more exotic languages (which themselves 
are likely struggling to gain a toehold) we should stick to and rally 
behind the earlier idea of expressing "swift" semantics as a library, 
which can be used from the already popular languages: Python, Java 
(+Groovy et al), Perl, Ruby - in roughly that order. Probably C/C++ as well.

We should continue, I feel, to pursue two paths:

- improve Swift itself, especially in documentation and support tools, 
because it works and is gaining in usage, from which we can gain a lot 
of experience. Swift's slow pace adoption step more from 
documentation/tutorial shortcomings, rough edges in environment support 
and debugging, and lack of people to do these things, than from an 
intrinsic lack of market attractiveness. Swift is a thin language by 
design, which should enhance its attractiveness.

- try some simple experiments with a Swift library for Python, to see 
how it feels to program in, and how much of our current runtime 
infrastructure we can reuse.

Swift-as-a-library seems to me to have potential similar to MPI to 
achieve great success - wider that Swift-as-a-language - while not 
eliminating the benefits and continued support and improvement of the 
current system.

A Swift function library could have these elements:

- declare data types
- declare data(set) instances
- define app wrappers
- define blocks (dataflow dags)
- define foreach-iterators
- launch a script
- monitor script progress and extract results

It should be possible using these primitives to both run the semantics 
of most or all current swift programs, and likely to re-use, at least 
initially, large portions of the Swift runtime system.

For example, if we were to do an experiment in Jython, we could embed 
much of swift and the karajan engine into a single process with the 
Python language iterpreter.

We could also implement the Swift engine as a companion process with a 
socket interface to accept and process definitions and script execution 
requests, and this engine could both continue to serve the current Swift 
execution base and as a the engine for other language bindings.

- Mike



On 10/24/09 9:07 PM, Mihael Hategan wrote:
> On Sat, 2009-10-24 at 19:51 -0500, Ian Foster wrote:
>> Hi Ben:
>>
>> I gather you are in Australia at present? Say hello from me.
>>
>> I think that the key feature of Swift (apart from functional semantics  
>> and XDTM-like mechanisms) is its use of single assignment variables  
>> for synchronization.
>>
>> I'm not sure that one has to have everything-parallel semantics to do  
>> what we want. One could also have explicitly parallel operators, like  
>> "forall" and "par" used in CC++.
> 
> We could have forall and par in Java, as libraries. Which is something I
> would personally like to see regardless of what Swift does. I'm not sure
> why Scala would be better (other than being a more interesting but more
> obscure language - which is a milder version of the Swift - Java
> conflict).
> 
>> I remain interested in the question of whether we can reduce barriers  
>> to use of Swift, and its long-term maintenance costs, by adopting some  
>> existing technology to build on. Scala is one of several potential  
>> candidates.
> 
> My opinion on that is that what we're trying to address with Swift (as a
> language) is for us to deal with the nasty problems of concurrency so
> that our users don't have to (questions of whether we succeed at that
> notwithstanding).
> 
> Choosing Scala or Java instead would mean that, while being able to work
> with a more stable and better known language (as well as some of us
> having an easier job), our users will have to take care of some of those
> harder problems.
> 
> Taking the limit, the maintenance costs of doing nothing are pretty low.
> 
> 
> _______________________________________________
> Swift-devel mailing list
> Swift-devel at ci.uchicago.edu
> http://mail.ci.uchicago.edu/mailman/listinfo/swift-devel