[sac-user] SaC beginner: modularization, declaration

Juhasz David juhda at inf.elte.hu
Thu Dec 9 16:02:11 CET 2010

Hi Bodo,

Thanks the quick and detailed answer, it was very useful.

On Wed, 2010-12-08 at 19:00 +0000, Scholz, Sven-Bodo wrote:
> Hi David,
> On 08/12/2010 13:50, "Juhasz David" <juhda at inf.elte.hu> wrote:
> > Hi,
> > 
> > I'm participant of a project in Eötvös Loránd University, Hungary. In this
> > project we want to develop a general programming language for multicore
> > and distributed systems, wich is not hardware-specific, but can make an
> > effective code from the source. My actual assignment is to write a summary
> that sounds interesting; is it a follow up on the feldspar work?

This project is a different one, started several months ago as part of a 
university project. The Faculty of Informatics has the subproject Software 
technology issues of distributed and multicore systems. This subsubproject 
in Department of Programming Languages and Compilers is about the compiler 

> What architectures are you targeting?

This is not really decided yet. We'd like to support as many architectures 
as possible. :) In this first period of the project we summarize the 
current solutions for multicore systems.

> In Sac, we have now backends for SMPs, GPUs, and MicroGrids.
> However, the latter two are not yet publically available. If you want to
> play around with our prototypes, we can make our pre-alpha version
> available....

That's great! We'd love to try out these backends :)
> > * How is it possible to define uniqueness type explicitly? Classtypes are
> >   uniqueness, but I'd like to define uniqueness types on a general way.
> The entire idea is to hide uniqueness types from the user. Instead, we talk
> about state-full objects. A class introduces a state-full data type which is
> guaranteed to be used single threaded-ly (even if you use our
> non-determinism feature as explained in
> http://doi.acm.org/10.1145/1481839.1481847). Then, uniqueness types serve as
> an implementation vehicle only. We even mimick the touch and feel of
> side-effects by supporting reference parameters and global objects, both of
> which lead to compiler inserted extra parameters to ensure proper
> single-threadedness.

The non-determinism sounds interesting. Is this feature accessible in the 
actual version of the compiler?

> use the type system to infer array shapes. We only propagate type errors to
> the user, if we can guarantee that the type error will be hit,

This approach gives some peace to the programmer, but the execution of the 
program can cause errors. Our idea is to show up errors as soon as 
possible, better in compile time, i.e. if the compiler makes the 
executable, the execution can't run into erronous situation.

Best regards,

More information about the sac-user mailing list