Dao Language

Dao has finally become feature complete!

Saturday,18-May-2013 05:46:20 GMT

After the recent implementation of communication channel for tasklets, deferred blocks and exception handling by defer-recover, I believe Dao has finally become feature complete. Since now the main tasks will be testing and improving the implementation, preparing documentations and finishing some partially implemented modules. It's also about time to do some serious promotion of Dao, as a good start I will be speaking about Dao at the Emerging Languages Camp of the Strange Loop 2013 :)

I have planned a stable release for this year, but possibly after the conference (Sep. 18th). I am considering to use 2.0 as the version number, as 1.2 no longer reflects the amount of changes and improvements that have been made since version 1.1 released about four years ago!

A new feature for concurrent programming: tasklet communication channels!

Saturday,18-May-2013 00:35:32 GMT

I have been looking for ways to improve Dao's support for concurrent programming. The most recent improvement is the addition of the tasklet communication channel which is inspired by the Go programming language. Channels can be used to communicate between tasklets and synchronize their execution.

The implementation of this feature was simple, because the infrastructure for concurrent programming was already there in Dao virtual machine. But I did take this opportunity to make various and significant improvements to the scheduling of tasklets.

The channel type is implemented as a customized C data type that supports template-like type arguments. So to construct a channel that can send and receive integers, one can use,

chan = mt::channel<int>()

Here channel is prefixed with mt:: , because channel is defined in the built-in mt multi-threading module.

The type argument int indicates this channel can only be used to transmit integers. Currently, only primitive types ( int , float , double , complex , string , enum ) plus array types, and their composition through list , map and tuple types are supported for channels.

Each channel has a capacity for transmitting data, which are buffered in the channel. When the channel's buffer reached its capacity, any attempt to send data to it will result in the blocking of the sender, which will be resumed either after a timeout or after some data of the channel have been read out of the buffer to make room for the new data being sent by the blocked sender. Channel capacity can be passed to the constructor of the channel as an optional parameter, which is one by default.

The channel type has a number of methods which include:

buffer( self :channel<@V> ) => int
It returns the number of unprocessed data items in the channel buffer.
cap( self :channel<@V> ) => int
Return the channel capacity.
cap( self :channel<@V>, cap :int ) =>int
Set the channel capacity and returns the previous one. Set the capacity to zero to prevent it from receiving further data, and effectively close it when its buffer become empty.
send( self :channel<@V>, data :@V, timeout :float = -1 ) => int
Send a data item with a timeout. A negative timeout parameter means infinite waiting. It return 1 upon timeout, 0 otherwise.
receive( self :channel<@V>, timeout :float = -1 ) => tuple<data :@V|none, status :enum<received,timeout,finished>>
Receive a data item with a timeout. A negative timeout parameter means infinite waiting. It returns a tuple with the following possible values:
- (data, $received);
- (none, $timeout);
- (none, $finished);
select( group :list<@T>, timeout = -1.0 ) => tuple<selected: none|@T, value :any, status :enum<selected,timeout,finished>>
Select on a group of channels, wait with a timeout for data become available from any of the channels. It returns a tuple with the following possible values:
- (channel, data, $selected);
- (none, none, $timeout);
- (none, none, $finished);
As the signature indicates, this is a static method.

Here is a simple example, where integers are sent through one channel and strings through another, and these integers and strings are received using the select method:

load sys

chans = { mt::channel<int>(1), mt::channel<string>(1) }

mt.start::{
  index = 0;
  while( ++index <= 10 ){
    if( rand(2) ){
      io.writeln( "sending integer:", index );
      chans[0].send( index )
    }else{
      io.writeln( "sending string: S" + (string) index );
      chans[1].send( 'S' + (string) index )
    }
    sys.sleep(0.5)
  }
  # set channel buffer sizes to zero to close them:
  chans[0].cap(0)
  chans[1].cap(0)
}

while( 1 ){
  data = mt::channel::select( chans, 0.2 )
  io.writeln( "received:", data );
  if( data.status == $finished ) break
}

Please see demo/concurrent for more examples.

Dao now supports Go-style panic/exception handling!

Tuesday,07-May-2013 02:04:56 GMT

I recently looked into the panic/exception handling in the Go programming language (defer-recover), and found it very interesting. After careful evaluation and consideration of its design and possible way of implementation and improvements, I was convinced that it is a better approach to handle exceptions than the conventional try-catch. (But I do think it is a mistake in Go to use returned error codes as the common way to handle errors).

I believe the main advantage of defer-recover exception handling over the try-catch is that it doesn't complicate the control flow of the program. This not only makes programs using defer-recover more readable than using try-catch, but also makes the implementation of this feature in a language much simpler than implementing try-catch exception handling. In fact, I was able to implement defer-recover in Dao in a few days (including testing and bug fixing).

The defer-recover handling in Go does have an disadvantage, that is, it does not allow handling exceptions in place close to where exceptions may arise, and the normal execution has to be resumed in the caller of the function that handles the exception.

This issue is solved in Dao, by supporting a new type of code block (not sure how to call it, maybe I will simply call it framed block for convenience) placed in @@{}. Such framed block is executed in a new stack frame using the same stack data of the function where it is defined. Deferred blocks defined in framed blocks are handled in the same way as in normal functions, namely, when a framed block finishes, its deferred blocks are executed in the reverse order of being deferred. Codes in framed blocks can access variables outside the blocks in the same as that in code blocks for code block/section methods.

Framed block allows to handle exceptions right at the place where they arise, and to resume normal execution right after the framed block (namely in the same function where the exception is handled). Here is a simple example,

fout = io.stdio

@@ { # framed block to be executed in a new stack frame:
  defer { recover() }
  fout = io.open( "NonExistingFile.txt", 'r+' )
}
if( fout != io.stdio ) defer{ fout.close() }
fout.writeln( 'hello' )

These codes basically try to open a file to write something, and if the file cannot be opened successfully, the standard I/O will be used instead. In the deferred block, the built-in function recover() is used to recover a list of exceptions to be handled. This function may take an exception type as parameter to request recovering a specific type of exceptions.

Even better, in situations where one wants to use a optional value produced by may-fail expressions/statements, the following can significantly simplify coding:

value = @@( default_value ) { block_to_produce_new_value }

For example, the above example can be simplified to:

fout = @@( io.stdio ){ io.open( "NonExistingFile.txt", 'r+' ) }
if( fout != io.stdio ) defer{ fout.close() }
fout.writeln( 'hello' )

As it can be seen, defer-recover can be just as convenient as try-catch, yet it offers better readability in the programming part (and better maintainability in the language implementation part, considering how easily it was implemented).

More information about deferred block can be found in the Deferred Block subsection in dao.tutorial.controls , and the panic/exception handling in the help entry dao.tutorial.exception .

Online demos for them is also available at: Dao Online Demo!