( @(user) ) Login/Signup Logout
The Dao Programming Language
for Scripting and Computing

Home Documentation Download Blog Forum Projects Demo
Label: ♦english ♦news

[940] ANN: Dao-2.0-Beta1 is released!

Comment
This is the first beta release after Dao has reach feature-complete status. In this version, Dao has included many new features and many significant improvements since Dao-1.1 released in 2009.

The most important new features include: (A) code section/block methods as an alternative to functional methods (similar to Ruby code block method); (B) concurrent programming features such as parallelized code section methods, asynchronous class and communication channels (similar to Go channels); (C) bytecode format and single file deployment; (D) deferred code block and exception handling by defer-recover (similar to exception handling in Go with some improvements); (E) abstract interfaces; (F) Enum symbol types (combination of C++ enum and Ruby symbol).

Additionally, Dao now has a LLVM-based JIT compiler (modules/DaoJIT), a Clang-based module to support embedding C/C++ codes in Dao codes, and a Clang-based tool (ClangDao) for automatic binding generation from C/C++ header files. It also has new modules for online help and data serialization etc., and includes a new building system (DaoMake) based on Dao.

For a more complete list of new features, improvements and changes, please see the ChangeLog file in the package.

Homepage: http://daovm.net
Documentation: http://daovm.net/help/en/index.html
Download: http://daovm.net/download
Issue Report: https://github.com/daokoder/dao
Comments
Great !
Dao have been announced on slashdot with mitigated reception. http://developers.slashdot.org/story/13/05/29/0225227/dao-a-new-programming-language-supporting-advanced-features-with-small-runtime
It seems that people does not understand well what is the interrest of a new (again) langage ... There are too much of them nowadays.
I have a question. Would it be easy to implement an AOP framework in DAO ?
The only interest (in my opinion) to learn a new langage today is it's ability to overcome OOP limitations.
It seems that people does not understand well what is the interrest of a new (again) langage ... There are too much of them nowadays.

Too many jump to conclusions too quickly, and believe they can judge a whole language by reading a very short abstract :(
I have a question. Would it be easy to implement an AOP framework in DAO ?

Not sure, I will look into this.
First of all - congratulations! I applaud the effort and was first made aware of Dao from the slashdot reading/posting. However I was dismayed to read the comments of various readers/posters on slashdot?! Many of them did not receive it well. I myself would like to be more open and objective about it, hence I joined this forum and Home site for Dao. I will post more as I gain a better understanding.Please share with me any insights and tips as a new and eager student of Dao.
Regarding comments on slashdot, I think one shouldn't take them too seriously. I am sure many of them didn't bother to look into Dao before judging, for some comments, I even suspected their author didn't even finishing reading the abstract/story on slashdot before commenting. I also saw a few people argue against optional typing, even though they appeared to have no idea what it is really about! There were also some typical reaction to new languages.

However, I did learn something from the feedbacks on this beta release: a feature-wise comparison to other languages may be very helpful for promoting this language.
Yes, I agree ! Today, there are too many new langages, and not everybody has time to look seriously at them.
So to promote a langage, we have to do some "marketing" ;-)
For example, none of the slashdot reader have talked about the macro feature of DAO, which is pretty interresting.
In MY (and only MY ! lol) opinion, comparing DAO is good, and I would like a comparison specifically with AOP langages (because OOP is limited in some annoying ways). But I agree that a comparison with some mainstream scripting langage like Ruby, Pyhton, Lua would be very wise in order to promote DAO.
How fast is the langage would also be appreciated.
The online sandbox with some preset example is also a very good way for early adopters to play with DAO, without the burden of installation.
So to promote a langage, we have to do some "marketing" ;-)

Definitely, wikipedia, slashdot and reddit etc. are good places to start :)

In MY (and only MY ! lol) opinion, comparing DAO is good, and I would like a comparison specifically with AOP langages (because OOP is limited in some annoying ways).

I am quite new to AOP. From what I read, it seems highly related to decorator. Dao supports typed decorators (no documentation yet, but there is a demo with comments: demo/decorators.dao, which can be tried online), I wonder if it can be very useful for AOP.

How fast is the langage would also be appreciated.

I am quite confident on this. I have some very impressive benchmarks, but more will be needed to be convincing.

The online sandbox with some preset example is also a very good way for early adopters to play with DAO, without the burden of installation.

This was the main reason I made it :)
AOP is all about "cross cutting" : http://en.wikipedia.org/wiki/Cross-cutting_concern
It's more than decorator, because, you can decorate classes/methods with some regexp. For example add a log function to all methods of one class. You have your log "aspect", and you decide to inject it in some parts of you code : whether it will be a module, a class, some methods (get* + set* for example), etc...
It's a very powerful mechanism which cannot be emulated easily in OOP. The only way is to prepare some hooks all everywhere that would be needed. AOP allows to inject generic code everywhere.
(This is a short description of the main principle, every implementation has it's specificities)
Thanks. I understand the basic concepts/principles of AOP. Surely AOP is more than decorator, but I consider some kind class decorator could be a sufficient and minimum support for AOP. For example, we could have a class, which contains normal fields to be injected to other classes and a set of decorators which represent both the pointcuts (decorator names and the function signatures of the first parameters) and advices (decorator bodies). A decorator name (and function signature) could encode what methods should be decorated by it. Though representing pointcuts in this way is not very flexible, it may be adequate in most cases. I wonder if supporting AOP in this limited way could be interesting for anyone, the good thing about it is that it requires no new syntax and is reasonably simple to implement, I wouldn't mind to add such kind of class decorator to Dao:).
I think so. I've read (quickly) the decorator documentation : http://www.daovm.net/help/en/dao.routine.decorator.html But I'm not sure if the decorator replace the original function/method automatically or not ?
If it's automatic, then, it would be a very limited AOP since we do not have a real control over code injection. If we can mannually decide to decorate some methods/function by, let's say, choosing with a regexpr over the method/function name, or any kind of loop, then we have a full AOP equivalent.
When a class decorator is applied to a class, the method decorators will have full control on which methods they will decorate. Using regexpr is one way to choose the methods for decoration, but it may be unnecessarily flexible, after all method names usually have very specific patterns.

What I was considering is based on prefix and suffix matching between decorator names and method names, plus parameter signature matching between the first parameter types of decorators and signatures of the methods. For example,
class MyClassDecorator
{
    routine @Set_( func :routine<self :@CLS, value :int> ) { ... }
}
When MyClassDecorator is used to decorate a class, the @Set_ decorator will only be applied to methods whose names start with Set and whose signatures match with routine<self:@CLS,value:int> .

I don't see any trouble to support regexpr for matching method names though, I am just not sure if it's really necessary. Obviously, one shouldn't name their methods arbitrarily.
Yes, sure, regexpr is only a flexible and commonly (or confusing) used way. What's important is that we have programmatic control of which method/function will be decorated.
Some times, regexpr is the most convenient way, some times a loop is best, some times another pattern matching way is sufficient.
I don't know where is the limit between "flexibility" and "practicality" when AOP is concerned. I'm not that a specialist. But I know that a well designed AOP-like capability would be very much appreciated, and could be marketed also ;-)
AspectJ was a precursor in that domain. I think Scala have inherited some of it, and I know that some frameworks in the java world (like spring) have leveraged them. But I never practiced them, so I cannot help you further.
Ruby Mixins are a simpler way of doing AOP and is very much appreciated also.
My 2cts ;-)
I have been thinking about this while thinking about the hypothetical aspect-equivalent class decorator. I am afraid we will also need to support for mixins to properly support the class decorator. The reason is that, for class decorator to be really useful, it will be necessary to support non-static method decorators (which are not yet supported), and to properly apply such decorators, the decorator class has to be added as a mixin class to the target class.

Fortunately, it also seems simple to support:). Now we may need a tiny addition to the class syntax to support mixins and class decorator. I am considering something like the following,
class Name (mixins ; aspects) ...
Namely adding an optional brackets to specify a list of mixins (delimited by comma) and a list of aspects (class decorators). Here thee class decorators are just a special type of mixin classes whose decorator methods may be applied to the target class.
Becareful, aspect MUST be "injected" into a class outside of it's definition. If we have to modify the original class to include aspects, it's not anymore AOP (injecting is called weaving)
Thanks, I am aware of this principle, though I am not convinced that this is always a good idea in practice. Now Dao does support injecting aspect from outside of a class, but such injection must be done at the time of parsing the class definition. That means the "aspect" has to be defined before the class in the same file or in another file (but loaded before the class). So a typical use would be:
load aspect_module
class SomeClass
{
   ...
}
You may be very interested to checkout the Aspects demo from the online demo page :)

Change picture:

Choose file:
Visitor Map This site is powered by Dao
Copyright (C) 2009-2013, daovm.net.
Webmaster: admin at daovm dot net