[Swift-devel] Scala

[Mihael Hategan]

Do we have funding for this or is this going to be yet another way to
ensure that what we started with isn't going to get done?

On Sun, 2009-10-25 at 11:00 -0500, Michael Wilde wrote:
> 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