ANN: Dao Language v.0.9.6-beta is release!

[phoolimin]

Dear all,

This is just to let you know that the lastest version Dao language is
released.
This Dao was previously called Tao, and now is changed to Dao to avoid
confusion
with another Tao langauge. There are a number of new features
implemented in
this version, of which the most important one is the supporting for
multi-threaded
programming. A new concurrent garbage collector is also implemented to
for the
multi-threaded interpreter. Now unicode is also supported for string
manipulation
and regular expression (regex) matching etc. The algorithm for regex
matching
is enhanced with fixing of a few bugs which prevent finding the most
reasonable
matching in some case, and allowing reverse matching from the end of
string.
The interface for creating Dao plugin in C++ is further simplified and
matured.
Of course, many bugs are also fixed. For more information,
please visite: http://www.xdao.org.

By the way, a console named DaoConsole with graphical user interface is
also released.

With best regards,

Limin Fu

-----------------------------
ChangLog for this release:
-----------------------------

+ : added
! : changed
* : fixed
- : removed

MULTITHREADING:
+ Multi-threaded programming is supported as a kernel feature of
Dao language. Posix thread library is used in the implementation.
And the thread API in Dao is similar to that in Posix thread.
Parts of the Dao interpreter is re-structured for multithreading.
+ A novel concurrent garbage collector based on reference counting
is implemented to support multithreading.
+ A upper bound for GC amount is applied to prevent memory "avalanche",
where mutators generate garbage faster than GC can collect them.
gcmin(), gcmax().

UNICODE:
+ UNICODE is supported. String quotated with double quotation symbol
is internally represented as Wide Character String(WCS), while string
quotated with single quotation symbol is internally represented
Multi Bytes String(MBS). Corresponding operations on WCS is also
supported.

REGEX:
+ Regex reverse matching is supported.
+ Now internal representation of Regex uses both MBS and WCS for both
efficiency and proper matching character class for unicode. When a
regex is applied to MBS or WCS, the corresponding representation is
used.
+ Regex datatype is added, a regex pattern can be compiled and stored
for later use, by using: define regex: rgx = /\d+\w/;
or, rgx = regex( "\\d+\\w" );
+ New character class abbreviations \u and \U are added for unicode.
+ Customized character class abbreviations are support. Users can
define
their own character class abbreviations by:
define regex: \2 = [WhateverChars];
! Algorithm for regex matching is modified to extend matching when
possible, and is also modified to match regex group correctly.

NUMERIC ARRAY:
+ Specification of precision in numeric array enumeration is supported:
num=[@{numtype} array];
! Transpose operator(right operator) is changed from ' to ~.
- Function convolute() for numeric arrays is removed.

EXTENDING AND EMBEDDING:
+ Some abstract classes are added for supporting easy embedding
of Dao interpreter ( the daoMain.cpp source file is an example
for embedding ).
+ Some wrapper classes for Dao data objects are provide in daoType.h
to faciliate the using of Dao data objects in plugins or other
programs in which Dao is embedded.
! A new technique is implemented to allow more tranparent passing
data between Dao interpreter and C++ modules. Creation of shadow
classes is also supported by the way.

IO:
+ Instead of using STL stream classes, new DaoStream classes are
added mainly for handling unicode in many places.
+ For file IO, more open modes such as "rwat" are supported, and
more methods such as eof(), seek(), tell() ... are implemented.
read() is enhanced such that it can read until meeting EOF.

OTHERS:
+ Multi inheritance is supported for OOP. And the passing parameters
and calling to parent constructor is simplified.
+ Negative subindex is supported for string.
+ Added a feature that allows using Alternate KeyWord (*.akw) to
write Dao scripts in non-english languages. The only requirement
is the character encoding for the .akw file must be the same as the
script files.
! Variable scope specification keyword "global" is added; keyword
"extern" is remove; keyword "share" is changed to "shared"
! Data states are added for constant and frozen data. Now a const
data is a really const, and can not be modified anymore. Function
freeze() is added to freeze some data structures as well as those
are reachable from them, to prevent them from being modified;
And defreeze() is added to defreeze them.
! The using namespace is simplified(compile(),eval(),source()).

 

[Colin J. Williams]

Dear all,

This is just to let you know that the lastest version Dao language is
released.
This Dao was previously called Tao, and now is changed to Dao to avoid
confusion
with another Tao langauge. There are a number of new features
implemented in
this version, of which the most important one is the supporting for
multi-threaded
programming. A new concurrent garbage collector is also implemented to
for the
multi-threaded interpreter. Now unicode is also supported for string
manipulation
and regular expression (regex) matching etc. The algorithm for regex
matching
is enhanced with fixing of a few bugs which prevent finding the most
reasonable
matching in some case, and allowing reverse matching from the end of
string.
The interface for creating Dao plugin in C++ is further simplified and
matured.
Of course, many bugs are also fixed. For more information,
please visite: http://www.xdao.org.

By the way, a console named DaoConsole with graphical user interface is
also released.

With best regards,

Limin Fu

-----------------------------
ChangLog for this release:
-----------------------------

+ : added
! : changed
* : fixed
- : removed

MULTITHREADING:
+ Multi-threaded programming is supported as a kernel feature of
Dao language. Posix thread library is used in the implementation.
And the thread API in Dao is similar to that in Posix thread.
Parts of the Dao interpreter is re-structured for multithreading.
+ A novel concurrent garbage collector based on reference counting
is implemented to support multithreading.
+ A upper bound for GC amount is applied to prevent memory "avalanche",
where mutators generate garbage faster than GC can collect them.
gcmin(), gcmax().

UNICODE:
+ UNICODE is supported. String quotated with double quotation symbol
is internally represented as Wide Character String(WCS), while string
quotated with single quotation symbol is internally represented
Multi Bytes String(MBS). Corresponding operations on WCS is also
supported.

REGEX:
+ Regex reverse matching is supported.
+ Now internal representation of Regex uses both MBS and WCS for both
efficiency and proper matching character class for unicode. When a
regex is applied to MBS or WCS, the corresponding representation is
used.
+ Regex datatype is added, a regex pattern can be compiled and stored
for later use, by using: define regex: rgx = /\d+\w/;
or, rgx = regex( "\\d+\\w" );
+ New character class abbreviations \u and \U are added for unicode.
+ Customized character class abbreviations are support. Users can
define
their own character class abbreviations by:
define regex: \2 = [WhateverChars];
! Algorithm for regex matching is modified to extend matching when
possible, and is also modified to match regex group correctly.

NUMERIC ARRAY:
+ Specification of precision in numeric array enumeration is supported:
num=[@{numtype} array];
! Transpose operator(right operator) is changed from ' to ~.
- Function convolute() for numeric arrays is removed.

EXTENDING AND EMBEDDING:
+ Some abstract classes are added for supporting easy embedding
of Dao interpreter ( the daoMain.cpp source file is an example
for embedding ).
+ Some wrapper classes for Dao data objects are provide in daoType.h
to faciliate the using of Dao data objects in plugins or other
programs in which Dao is embedded.
! A new technique is implemented to allow more tranparent passing
data between Dao interpreter and C++ modules. Creation of shadow
classes is also supported by the way.

IO:
+ Instead of using STL stream classes, new DaoStream classes are
added mainly for handling unicode in many places.
+ For file IO, more open modes such as "rwat" are supported, and
more methods such as eof(), seek(), tell() ... are implemented.
read() is enhanced such that it can read until meeting EOF.

OTHERS:
+ Multi inheritance is supported for OOP. And the passing parameters
and calling to parent constructor is simplified.
+ Negative subindex is supported for string.
+ Added a feature that allows using Alternate KeyWord (*.akw) to
write Dao scripts in non-english languages. The only requirement
is the character encoding for the .akw file must be the same as the
script files.
! Variable scope specification keyword "global" is added; keyword
"extern" is remove; keyword "share" is changed to "shared"
! Data states are added for constant and frozen data. Now a const
data is a really const, and can not be modified anymore. Function
freeze() is added to freeze some data structures as well as those
are reachable from them, to prevent them from being modified;
And defreeze() is added to defreeze them.
! The using namespace is simplified(compile(),eval(),source()).

How does Dao compare with Python? What does Dao permit one to do which
cannot conveniently be done in Python?

Colin W.

 

[sszmidt]

Please trim replies... ; )

 

[phoolimin]

The best way to compare Dao with Python in detail would be, join a SF
project PLEAC, and provide solutions in Dao to those common programming
problems listed in Perl Cookbook(by Tom Christiansen & Nathan
Torkington, published by O'Reilly). The solutions in Python is there,
when solutions in Dao would be available, one can quickly compare it
with other languages using PLEAC project. But unfortunately, I don't
have enough time to it. So I will spend some time to grab some examples
from python tutorials, and show how they can be done in Dao, but you
have to wait for some days

For the second question, I will list some. First I should admit I don't
know well python, so maybe there are convenient solutions for something
that I think not convenient in python.

1. Multi-threaded programming:

In Dao, for any function or expression, one can evaluate them in an
independent thread as: thread.create( myfunc() ); or thread.create(
myexprs );

In python, probably one have to subclass from a thread class, and
reimplement a method (something like run(), if I remember correctly),
and then call that method.

In Dao, one can create and access thread specific data through a
hash/dictionary data structure thread.my["data_key"], which is thread
global. In python, I don't know how to do it yet.

2. Numeric array:
Dao have built-in numeric array type, one can create a numeric array in
the following ways:
array1 = [ 1, 2, 3 ]; # {1,2,3} will create a normal array
array2 = [ 0: 2 :4 ]; # create [0,2,4,6]
array3 = [5] : 1; # [1,1,1,1,1]
array4 = [3] : [1,2]; # [[1,2],[1,2],[1,2]]
....
one can use normal operators +,-,*,/,++,--, +=,-=,etc. to operate on
numeric array and scale number, or two numeric array of the same size,
or two numeric array with different size but constraint the operations
on specific elements by subindex. There are also other features make
operations on numeric array convenient.

I am sure python can do them, but I wonder if they are convenient.

3.Transient variable and "magic" functions:
Dao provides so called features such transient variable (composed of @
and digits) and "magic" functions, which are provided as a kind of
functionaly programming tools, and in particular, transient variable
provides an explicit control during implicit parameter passing in such
"magic" functions. I think this is not something available in python.

As exmaples:
sort( array, @1<@2 ); Or: sort( array, exprs( @1, @2 ) );
where @1 represents the first of the two elements for comparison during
sorting, and @2 represents the second. It will sort array so that any
two neighbors elements satisfy (if possible) the second expression in
sort().

iterate( array, exprs( @1 ) ); will iterate on array and execute the
expressions after the first parameter. Here @1 represents each element
of the array. This function can be nested, in this case one may use @1,
@2, @3 ...

These two features are even more useful in numeric array operations, I
will not show example here. If you want to find it out, please have a
look at the documentation for Dao.

4. Extending using C++:
To extend Dao, one must use C++ (at least as an intermediate
interface). However, the C++ to extend Dao is very simple, and
transparent. And one only need two header files to build a Dao plugin
WITHOUT linking to Dao library! I believe the extending of Dao using
C++ is much simpler and more convenient than python.

That's enough. If I say something wrong about python, please point out.

Limin

 

[bearophileHUGS]

From "An Introduction to Dao":

So I realized the goodness of scripting languages, and spent about two weeks to write some Perl scripts to retrieve informa- tion from GO and construct the DAG. But that experience with Perl was not very nice, because of its complicated syntax. Then I started to think about the possiblity to design a new language with simple syntax, and formed some rough ideas.<

Maybe trying Python requires less time
But trying to implement new languages (like Dao, Boo, etc) is useful
because they can start again with fresh ideas and less legacy syntax
(and some of the new ideas can be backported to Python).

sort( array, exprs( @1, @2 ) );

This @ syntax reminds me of a similar one into Mathematica. It can be
useful, but using lambdas is acceptable enough, I think.

I believe the extending of Dao using C++ is much simpler and more convenient than python.<

If this is true, then this is an interesting (useful) advantage. Maybe
Python can learn something from Dao.

Bye,
bearophile

 

[phoolimin]

Maybe trying Python requires less time

Yes. Maybe if I tried python instead of perl, probably there would be
no Dao language . However there is one thing I don't like in python,
that is, scoping by indentation. But it would not annoy me so much that
make me decide to implement a new language^_^.


Regards,

Limin

 

[Bengt Richter]

Please trim replies... ; )

Not quite so far ;-)

Regards,
Bengt Richter

 

[JohnBMudd]

Here it is again... Python bypassed/discounted because, of all things,
scoping by indentation!?!?

This used to surprise me. Until I hear more and more otherwise
reasonable programmers list this as their number one reason for
shunning Python.

I gauge design defects by how much after market
discussion/documentation a feature generates/requires. Scoping by
indentation is a whopper of a defect.

Could the PyPy people find some way (I don't how) to eliminate this
stumbling block going forward?? That is, after they eliminate the GIL!

John

 

[Paul Boddie]

Here it is again... Python bypassed/discounted because, of all things,
scoping by indentation!?!?
[...]

Could the PyPy people find some way (I don't how) to eliminate this
stumbling block going forward??

No: I believe they could only eliminate it "going backward". ;-)

Paul

P.S. I will admit that the first thing I do when editing someone else's
code (in any language) is to make sure the tab settings are sane in my
editor, but should basic editing skills really be so far beyond the
person/people entrusted with writing the software that runs your
business/organisation/lifestyle? Is Mr Rocket Scientist really
incapable of tying his own shoelaces?

 

[Dave Hansen]

Here it is again... Python bypassed/discounted because, of all things,
scoping by indentation!?!?

This used to surprise me. Until I hear more and more otherwise
reasonable programmers list this as their number one reason for
shunning Python.

I gauge design defects by how much after market
discussion/documentation a feature generates/requires. Scoping by
indentation is a whopper of a defect.

FWIW, indentation scoping one one of the features that _attracted_ me
to Python.

It's far more interesting to me _why_ people think indentation scoping
is a bad thing. The answer I get back fall into two general
categories: 1) I've heard/read/been told it's a bad thing, and 2) It
causes portability problems.

Of these, only (2) is valid. And the only reason it's valid is that
Python recognizes the TAB character as valid indentation. TAB
characters are evil. They should be banned from Python source code.
The interpreter should stop translation of code and throw an exception
when one is encountered. Seriously. At least, I'm serious when I say
that. I've never seen TAB characters solve more problems than they
cause in any application.

But I suspect I'm a lone voice crying in the wilderness. Regards,
-=Dave

 

[paulo.jpinto]

You're not alone.
The first thing I do after installing an IDE or programmers editor is
to change the configuration to use spaces as identantion.

I still don't get why there is still people using real tabs as
indentation.

 

[Tony Nelson]

FWIW, indentation scoping one one of the features that _attracted_ me
to Python.

Me too. Or rather, Python code is much more readable because every
nincompoop has to use indentation correctly whether they want to or not,
and I like readable code.
________________________________________________________________________
TonyN.:' *firstname*nlsnews@georgea*lastname*.com
' <http://www.georgeanelson.com/>

 

[=?ISO-8859-1?Q?Gerhard_H=E4ring?=]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Python recognizes the TAB character as valid indentation. TAB
characters are evil. They should be banned from Python source code.

AGREE! AGREE! AGREE!

The interpreter should stop translation of code and throw an
exception when one is encountered.

You could file a "Parser/Compiler" Feature Request for this [...]

Read PEP 666 first.

- -- Gerhard
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDkLJWdIO4ozGCH14RAiOyAJ4gNZrf5rjv5Cqk2cj/hFGXRaeCZwCdEL/X
ITGPnj6tXblSY1r04zS5djY=
=z37M
-----END PGP SIGNATURE-----

 

[Micah Elliott]

Python recognizes the TAB character as valid indentation. TAB
characters are evil. They should be banned from Python source code.

AGREE! AGREE! AGREE!

The interpreter should stop translation of code and throw an
exception when one is encountered.

You could file a "Parser/Compiler" Feature Request for this (Hmm,
sf.net appears to have just renamed "Request For Enhancment" to
"Feature Request"). Seems the present enformencement of
disallowing tab/space mixing is with -t and -tt. From PEP-8
<URL:http://www.python.org/peps/pep-0008.html>:

...
Tabs or Spaces?

Never mix tabs and spaces. The most popular way of indenting
Python is with spaces only. ... Code indented with a mixture
of tabs and spaces should be converted to using spaces
exclusively. ... When invoking the python command line
interpreter with the -t option, it issues warnings about code
that illegally mixes tabs and spaces. When using -tt these
warnings become errors. These options are highly recommended!

For new projects, spaces-only are strongly recommended over
tabs. Most editors have features that make this easy to do.

If your "FR" is approved, -t and -tt could apply to any use of tabs.
+1 from me.

 

[Simon Brunning]

FWIW, indentation scoping one one of the features that _attracted_ me
to Python.

+1 QOTW

OK, it's a bit of a cliche. But it's a cliche because it's *true*.

 

[Inyeol Lee]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Python recognizes the TAB character as valid indentation. TAB
characters are evil. They should be banned from Python source code.

AGREE! AGREE! AGREE!

The interpreter should stop translation of code and throw an
exception when one is encountered.

You could file a "Parser/Compiler" Feature Request for this [...]

Read PEP 666 first.

And this one too ;-)
http://www.artima.com/weblogs/viewpost.jsp?thread=101968

--Inyeol

 

[Alexander Zatvornitskiy]

Hello, (e-mail address removed)!

28 nov 2005 at 02:48, (e-mail address removed) wrote:

p> This is just to let you know that the lastest version Dao language is
p> released.

Please wrote "hello world" example for us, and some more simple examples which
highlight major features of this language. I think, it is the best way to
evaluate new language.


Alexander, (e-mail address removed)

 

[Tom Anderson]

You're not alone.

I still don't get why there is still people using real tabs as
indentation.

I use real tabs. To me, it seems perfectly simple - i want the line to be
indented a level, so i use a tab. That's what tabs are for. And i've
never, ever come across any problem with using tabs.

Spaces, on the otherhand, can be annoying: using spaces means that the
author's personal preference about how wide a tab should be gets embedded
in the code, so if that's different to mine, i end up having to look at
weird code. Navigating and editing the code with arrow-keys under a
primitive editor, which one is sometimes forced to do, is also slower and
more error-prone.

So, could someone explain what's so evil about tabs?

tom

 

[Scott David Daniels]

So, could someone explain what's so evil about tabs?

They appear in different positions on different terminals (older hard-
copy), do different things on different OS's, and in general do not
behave nicely. On many (but not all) systems, they advance to the next
column that is a multiple of 8, but not all, and people (and editors)
use them freely to get to those positions, not understanding that they
are not necessarily going to the same position. The fact that they
provide an ambiguous display is enough to make them evil.

--Scott David Daniels
(e-mail address removed)

 

[D H]

They appear in different positions on different terminals (older hard-
copy), do different things on different OS's, and in general do not
behave nicely. On many (but not all) systems, they advance to the next
column that is a multiple of 8, but not all, and people (and editors)
use them freely to get to those positions, not understanding that they
are not necessarily going to the same position. The fact that they
provide an ambiguous display is enough to make them evil.

How is that a problem that some editors use 8 columns for tabs and
others use less? So what?
A bigger problem I see is people using only 2 or 3 spaces for indenting.
That makes large amounts of code much less readable. And of course it
is a problem if you mix tabs and spaces at the beginning of the same line.
Tabs are easier to type (one keystroke each) and lead to visually better
results (greater indentation unless you like hitting 8 spaces for each
indent level).