## Dao, a new programming language

Hi,

I started to read LtU regularly since two or three months ago, and found it is very interesting. I am also very interested in programming languages, and create one named Dao. It is still under active developing, to further improve it, I would like to bring it to the attention of LtU users, and to see if I can get some feedbacks from you;-)

Though no stable version of this language has been made available yet, a number of interesting features have been implemented in this language. In particular, IMHO, there following could be interesting for LtU users:

1. Concurrency: coroutine, thread, asynchronous function call and message passing interface;
2. A macro system that allow defining new syntax in a similar way as writing a BNF-like syntax description;
3. Mixed programming with C language, allowing embedding C codes in Dao scripts.

Dao is an object-oriented language with rich data types and syntax. Though it is not designed to be functional, it supports first class functions, so it may allow certain kind of functional programming. Other features supported include exception handling, numeric array, regular expression matching and automatic memory management etc. It also has a clean interface to C language, and is extendable and embeddable.

The implementation of the language and the mentioned features is by no means perfect, there is still much to be improved. The documentation is still priliminary, but should be enough to get a clear idea of the language. It would nice if you can make some comments, critiques and suggestions on this language. Thank you!

## Comment viewing options

### What's the hook for your language?

What's the hook for your language? Why would I want to look at it as opposed to many others? What's different about it?

### Hooks need not apply

The documentation on the website will tell you if there are any "hooks" for you.

### I don't have the wherewithal

I don't have the wherewithal to search for it. I'm not trying to be a jerk, I'm trying to get the creator to make it clear what the "value-added" is. Why was this language created rather than using an existing one?* What is the problem domain that it is aimed at? etc.

To be honest, I doubt I'll be interested anyway, but an important part of the others who might don't know it from the description above.

* I know that the answer is, partially, "for the heck of it", but then I emphasize "this language".

### The mentioned 3 features are the hooks

I believe, but cannot prove;-)

I created this language mainly because I was very frustrated by Perl, and "luckily" at that time it was the only scripting lanuage I know;-) Honestly saying, if I knew Python or Ruby, I would not have started to create mine. I knew them after I got to be very interested in languages, but it was already too later for me to stop;-)

Initially, the key points I was trying to address during the development were OOP, C/C++ interface and numeric array (for scientific computing) which are generally influenced by my experience with C++ and Matlab. However, due to the lacking of library support, the functionality of numeric array is still limited. Later on, more advanced features were included. In particular, concurrent programming become one of the most important point to be address, as you can see from the documentation(also the above post), concurrency is supported in different way at different level. I believe, few languages support them all.

Considering the current development status, I would not try to persuade people to use Dao as opposed to other languages. Instead, if you like and have time, you can treat it as a "super toy", and play with it;-). If you found it is very suitable for some of you work, then you can start use it...

### Dao VM

If you want to focus on the language and the compiler itself, you could use the NekoVM (http://nekovm.org), that is a fast and lightweight dynamicly typed VM with JIT. Your compiler can generate code for the Neko intermediate programming language, which will then be compiled to VM bytecode by the Neko compiler.

There's already a good number of libraries available for the NekoVM, a C FFI to extend it further, and it's well supported on Linux, OSX and Windows (it's mostly ANSI C, so is well portable as well).

Disclaimer : I'm the Neko author.

### VM is something I am trying to focus

Sure, it is simpler to target the language to an existing VM. But, I don't think everything of Dao can be implemeted on the top of NekoVM, e.g., scheduling of the actors (just to remind, the message passing interface and asynchronous function calls are implemented based on the the actor model).

### Actors

Is there some readable description of Actors? I've never quite understood what it is and Hewitt's description has a reputation for incomprehensibility that's prevented me from ever looking at it.

Or in other words, what do you mean when you say the message passing interface and asynchronous function calls are implemented based on the actor model?

### Actors in Dao

In Dao, in the case of message passing interface for concurrency, each virtual machine process is an actor, which can send, receive and process messages and are scheduled to run in independent OS threads. While for asynchronous functions calls, the callable objects are the actors and the parameters are the messages, the are also scheduled in the same way. The scheduling follows the principles defined in the actor model.

There are a number of references on the actor model from wikipedia:
wikipedia:actor_model
A more practically useful reference can be found here in the chapter about the actor model:
Coordinated Computing: Tools and Techniques for Distributed Software

### Agha's thesis

Gul Agha's PhD thesis is a fairly readable (if a little dated) introduction to the Actor model.

### Or maybe

Since the URL that Allan gave is choosy about who it will let in (certificate based: it's never let me in, and I have an account on a machine in the MIT campus...), you might prefer A Foundation for Actor Computation [citeseer], which gives an actor calculus in a PCF-like presentation. It gives a slightly sketchy but clear motivation for the actor model in general, and the reasons for providing this particular actor calculus.

I was able to download that paper from outside MIT. After I accepted the certificate, it took me to a non-https version of the link: here.

That worked.

### Interesting

-the exception handling:IMHO new language should implement the 'scope' of http://www.digitalmars.com/d/exception-safe.html
for a better design than traditional exception handling.

-there is a documentation error in 'A Quick Guide to Dao' if I've read correctly 'if do .. end' is deprecated.

-there is no documentation of the implementation features: properties of the GC, the runtime, etc.

A minor point: format string like in printf in C and embedded expression like in Ruby would be nice (may be using the same escape character % that printf).

The language's syntax is nice (except for the types in upper case which looks ugly), but that's not the only language to have a nice syntax..

### Thank you for the comments

--- For the exception handling: if a piece of codes is suspectable, they can be put in the "try" block, and any cleaning codes can be put in a "rescue" block, so for the example given in the link mentioned by you:
try{
lock( m )
foo()
unlock( m )
}rescue{
unlock( m )
}

--- Right, there is a documentation error,'if do .. end' is deprecated, but two places in examples are not updated accordingly. Now it is fixed.

--- For the documentation of implementation, I haven't found time to do it yet, so far I was busy with the implementation;-). I will prepare them after I finish further documentation of the language.

For the GC, it is a concurrent GC based on reference counting (an algorithm invented by myself;-), I have prepared a manuscript and submitted to a journal, I don't know if it is proper to make a link to it here). The Dao virtual machine is virtual register based, it uses adaptive intructions and operand caching for optimization for loops. The basic virtual instructions may be generic for different types/operations, at running time they are adapted to more specific instructions for specific types/operations. It seems the idea of using adaptive virtual instructions is also novel, but I am not quite sure about this, somebody may correct me.

--- C like printf, I will add it;-)

--- types in upper case: so far they are not reserved key words, and they are simply constants, I am not sure yet if it is better reserve some names for types, probably yes, I will think about this;-)

### -For the exception handling:

-For the exception handling: I've understood your design, the explanation is clear in the website. What the url given before explained is that 'exception safe programming' is hard and it's better to provide also a scope exit operator to simplify things for the programmer: nesting try/rescue gets unreadable fast.

-For the GC, that's a funny coincidence: yesterday I read a paper on a reference counting GC: 'A Pure Reference Counting Garbage Collector'.

### Funny coincidence

Oops, that paper is by Bacon, my GC algorithm was inspired by his concurrent reference counting GC algorithm!

I understand your point about exception handling, I will try to have a deeper look into the approach by scope exit operator, thank you for pointing me to that url.

### Implicit typing system

Currently I am trying implement an implicit typing system in Dao,
to support more compiling time checking of the type consistency of operations and to use inferred types to generate more specific virtual instructions to improve efficiency. The reason that I started to think a typing system is important, is partially due to reading the discussion in the thread The Next Mainstream Programming Languages, partially due to my recent reviewing on the Dao VM regarding the adaptive instruction and operand caching mechanism, which was implemented in a bit tricky way.

After the typing system is added, the variables will be divided into two classes: statically typed and dynamically typed. Strict compiling time checking will be carried out on statically typed variables. Statically typed variables can be either declared explicitly or inferred from assignment operations. Dynamically typed variables are those declared without type indication or assignment operations. For safety, assignment between 2 differently statically typed variables or assignment from dynamically typed to statically typed will require to use an operator to force conversion explicitly.

Type inferring will be done based on virtual instructions. With the division of statically typed and dynamically typed variables, the implimentation of the typing system seems to be simple. However, when come to list and hash (associative array), there seem to be some problem, I will mention later.

To declare a variable to have fixed type explicitly, one might do like this:

var1, var2 => type

in function/routine declaration, one might also,

routine foo( par1 => typeA ) => typeB
{
...
}
where "typeB" will be the type of the return value of foo().

I also realize it is necessary to specify the element type of a list or hash, otherwise, there will be a problem in inferring type for such expression,

a = alist[i]

though in many cases, it can be sure that "alist" will contain elements of the same type. One possible way to specify the element type of "alist" is, e.g.,

alist => list<number>

this will allow "a" being inferred as a number.

So far so good, but, what about the built-in methods for list, such as list.pushback( item ) and list.top() etc, how do I specify the type of "item" in the parameter list of pushback() or the returned type of top()? These methods are defined internally, it can not be known in advance what is the element type of "alist". So there should be a way to let the typing system know that the type of "item" should be the same as the element type of the "list". There could be two way to solve this problem: the first, a C++ way, to specialize internally these methods; or the second, a hacker way, use special keywords as the type of "item", e.g., "item => _ITEM_TYPE", to inform the typing system to treat the type of "item" in a special way. The second way should be simpler to implement than the first, but the first sounds more consistent with the rest of the typing system. Do you have any
suggestions on this?

And what about the syntax I mentioned above for explicit typing? Does it look reasonable?

### Maybe you could have a look

Maybe you could have a look how Scala do it, I found their typing system elegant.

For the syntax, I don't like much '=>' it looks as if you were trying to assign variable to a type, here's a suggestion:
a:*; #declare variable a with dynamic type or 'any' instead of '*'
a:type; # declare variable a with static type and default value.
a:atype=value; # declare variable a with static type atype and initialise to avalue.
a:=value; # declare a initialised with value and its static type
a:*=value; # declare a with dynamic type and set it to value.
a=value; #normal assignment.
For consts, with a prefix 'const' or 'val' or 'def'.

### Sounds like what is being used

The syntax you suggested sounds like what is being used in Dao;-), except that, the "type" is not a real type, but a constant, and,

a : type_const;

will declare "a" to have the same type as the constant "type_const",

a := type_const;

will declare "a" to have the same type as and initialized to "type_const". ( In previous releases, the variables declared with types are checked in running time )

You are right, "=>" might be confusing, so I will keep using "a:type", "a:=value", and adopt "a:any", "a:any=value" and "a:type=value". Thank you for the suggestions.

### It's implemented in ML

In various ML languages (OCaml, SML) and Haskell, this is implemented using polymorphic type parameters. In your code, this could look like this:
routine pushback( list => list<'a>, item => 'a ) { ... } routine top( list => list<'a> ) => 'a { ... }

The 'a thingy means "a variable which is set to some type", so when top is called on a list of numbers, the type of the list is unified with the type of the parameter, list<'a>, so the 'a type variable is set to number, and all other occurances of 'a are also set to number, so it is clear to the type system that top will return a number.

I guess I wasn't completely clear, but you should take a look at OCaml.

### It is clear

but unfortunately, in the current implementation, the internal methods for list can not be defined in this way. Yet, for Dao routine definition, something like this can be adopted, thank you.

### Dao? Like the song?

This I gotta see -
a programming language named after a Harry Belafonte song?

(sorry - couldn't help myself).

### Dao means Tao

comming from Chinese. Dao and Tao are translated according different pronouncation of the same word in different region in China. Dao was once named Tao, but since there was another (parallel) programming language named Tao before this one, so I changed the name from Tao to Dao to avoid confusion.

Do you mean the song "Day-O"? Actually I didn't know Harry Belafonte before.

### I should have made clear - I do know what Dao is

I've studied a bunch of eastern philosophies.

And it's not the "day-o" song, and it's not "Belafote's song", it's a Jamaican folk song, probably originally sung (this is my thesis) in Creole, not English.

http://en.wikipedia.org/wiki/Banana_Boat_Song

So that's 5 mistakes in a 2 line post - I was making a joke and going for a record.

### The typing system is implemented

A preliminary documentation can be found here.

The release that supports the typing system can be downloaded from here.

In some situation, the typing system might fail to handle the typing of empty list/hash/array properly. There could also be some bugs in the typing system.

Since the virtual machine instructions and the operand caching method have been partially changed, there might be something broken. Of course, there also have been some bugs fixed from previous releases.

Yet, it is more or less ready to play with ;-)