Programming Forums

Programming Forums (http://www.programmingforums.org/forumindex.php)

- Other Programming Languages (http://www.programmingforums.org/forum38.html)

- - Aspen (http://www.programmingforums.org/showthread.php?t=13422)

For anyone interested in new languages, Aspen is a new programming language that is being developed by a grad student at Purdue. Myself and another undergraduate are being used to see how easy the language is to learn and where improvements can be made.

The idea behind Aspen is to provide a language that requires less code, retains the power and comparable performance of C++, and includes a runtime manager that dynamically allocates threads to handle loads. Aspen is tailored to networking programs such as a webserver.

The language is not publicly released yet but the initial paper on Aspen can be found here: http://cobweb.ecn.purdue.edu/~vpai/P...ya-ppopp07.pdf

There is still much work to be done and the designer is on an internship at Intel, but hopefully Aspen will be ready for release by the end of the year.

So.. Which aspects of this language require the invention of a new language, rather than the introduction of libraries atop an existing language?

I've read the abstract. One could wonder what "less lines of code" means, ultimately. One could also question the statistical significance of the numbers quoted. Is the language deemed to be useful in other than web applications, with the same perceived benefits? Are these issues addressed, with scientific soundness, in the remainder of the paper?

Quote:

Originally Posted by Rashakil (Post 130466)

So.. Which aspects of this language require the invention of a new language, rather than the introduction of libraries atop an existing language?

Mainly the formation of tasks into "Modules" that flow from one to another. The language allows programmers to form their code in a way very similar to a flowchart. Another aspect is what I mentioned earlier about the runtime monitor that handles thread management and dynamic load balancing.

Quote:

One could wonder what "less lines of code" means, ultimately.

This refers to user-written code that is not including comments and whitespace, nor does it include libraries or header files used by the language. Refer to section 6.4 for more information on "lines of code".

Quote:

One could also question the statistical significance of the numbers quoted.

One would have to read the experimental methodology first.

Quote:

Is the language deemed to be useful in other than web applications, with the same perceived benefits?

Theoretically yes, but that is the current focus of research. My work is in porting a popular IDS (Snort) to Aspen for benchmarking against a hand-parallelized version of snort using pthreads. Another project which I am not working on involves applying Aspen to manage kernel scheduling.

Quote:

Are these issues addressed, with scientific soundness, in the remainder of the paper?

If you are referring to the significance of the numbers quoted, than yes that is in the paper, but the applications tested were webservers and a VOD server. The usefulness of non-web based applications is not in the paper but can be explored from the information that is provided. The paper was published so I would hope that the scientific soundness of the paper was deemed acceptable.

The paper doesn't go into many details of the language syntax. For instance, what does the >>> operator do, and how are objects chained via the ||| operator? What features does the language have that would prevent it from being implemented as a C++ library?

Would it be possible to provide a few additional code examples?

Quote:

Originally Posted by Arevos (Post 131113)

I had no part in the actual development of Aspen so there is a lot I do not know about it myself but I'll do the best I can now and get back to you on the others. The >>> operator is an assignment.

somevar >>> othervar;

//is the same as

othervar = somevar;

You're probably wondering why have a new operator for this. I believe the reason is to allow an assignment to be used at the end of a string of function |||'s.
i.e.

funct1() ||| funct2(x) ||| funct3() >>> resultvar;

To answer your question about the ||| operator, there are two flavors of this. One is in the root module declaration. Specified under "Flow:" the ||| tells the parser to establish queue and everything else needed to flow output from module x to module y. The other use of ||| is within program that takes return values from a function and pipes them into another function.

funct1(x) ||| funct2(y) ||| funct3(z) >>> resultvar;



//is the same as



resultvar = funct3(funct2(funct1(x),y),z);

The return value of the former function is the first argument of the current function.

Quote:

What features does the language have that would prevent it from being implemented as a C++ library?

This I am unsure of. I will check into it and get back with you.

Im not sure if I am authorized to distribute sample code yet. I'll check on that as well.

Quote:

Originally Posted by sixstringartist (Post 131195)

You're probably wondering why have a new operator for this. I believe the reason is to allow an assignment to be used at the end of a string of function |||'s.
i.e.

funct1() ||| funct2(x) ||| funct3() >>> resultvar;

I see. So the syntax appears to be modelled around the CLI style of pipes and redirects, but instead of | and >, Aspen uses ||| and >>>.

Quote:

Originally Posted by sixstringartist (Post 131195)

funct1(x) ||| funct2(y) ||| funct3(z) >>> resultvar;



//is the same as



resultvar = funct3(funct2(funct1(x),y),z);

This seems similar to currying and function composition, which can be found in some functional languages. e.g. in Haskell:

resultvar = funct1 z $ funct2 y $ funct3 x



-- is the same as



resultvar = func1 z (funct2 y (funct1 x))

Quote:

Originally Posted by sixstringartist (Post 131195)

Quote:

Originally Posted by Arevos

What features does the language have that would prevent it from being implemented as a C++ library?

This I am unsure of. I will check into it and get back with you.

Im not sure if I am authorized to distribute sample code yet. I'll check on that as well.

Thanks. Programming language design is an interest of mine, and I'm curious to know some more about Aspen.

Forgive my ignorance, but I do not know the answer to your question and my coworkers have not been detailed in their responses. I'll post one of their responses and answer what I can, and hopefully you can come to your own conclusion.

One response to your question.

Quote:

I think the main answer to that question is that there are actual language constructs added to C++, which require a compiler/translator to produce something that a normal compiler will understand. The reason for this is the reason for Aspen's existence: namely, to make the programming easier.

Also wrt the runtime: maybe it could be implemented as some sort of library, although its different from a traditional library in that it actually provides main(), and calls your code instead of vice versa.

Ive been permitted to share some sample code with you, namely an echo server. Now an echo server is a trivial task in Aspen, but we can make some modifications to it as well and play around with that.

/* The following are forward declarations to reference code not found in this particular source file. I dont believe all of these are necessary for an echo server but seem to be placed in out of habit by the programmer.

*/

forward _httpCode;

forward _httpResponseCodes;

forward myMessage;

forward _vodStruct;

forward Payload;

forward TimerPayload;

forward flowPersist;





/*This is the declaration of the Root Module. It specifies the modules required as well as the instances of those modules and the flow between them.

*/

Module EchoServer is Root requires Module NetworkInput,Module NetworkOutput,Module Monitor

{

    void initialize()

        {

            NetworkInput nI(Input is tcp:9877);

            NetworkOutput nO;

            Monitor mon1;

            EmptyMod eM1;

        flow:

            nI ||| nO;

        }

}



Declare Module EmptyMod

{

  Scheduling:

  force SingleThreaded;

}



Module EmptyMod

{

    void initialize(){

    }

    void run(){

    }

}

I said its trivial because Aspen literally handles everything in this example. The built-in functions NetworkInput and NetworkOutput do all the work. We simply tell where NetworkInput should send its payload.

The Empty Module is regrettably necessary at the moment. Due to a bug in the compiler, Aspen will give an error if you do not include a user-made module.

Keep in mind, not only does Aspen make programming easier by interpreting a logical flowchart, but the above code is a parallelized echo server that will exhibit excellent scalability and load balancing.

Id be happy to answer any questions about the example code as well as take modification suggestions.

As an update and clarification, Aspen is a source to source compiler. So presumably anything that can be done in C/C++ can be done in Aspen. Im told that with macro's, there really isnt anything about Aspen that cannot be done in a library, but the motivation to write a new language is ease of programming.

Aspen's focus is to not limit parallelism possibilities, but at the same time only exposing a necessary level of parallelism to the programmer.