Hi!
The problem that=20
> g++ (GCC) 3.4.2 20041017 (Red Hat 3.4.2-6)
fails to compile tao has not yet been solved but fortunately the Linux
binary that comes with 0.9.0_1_beta is compatible to my system so I
can work through the draft version of
'An_Introduction_to_Tao_Language.pdf'[1]
Observations on Section 2.1 already are enough for a mail because two
of them may be seen as an error in Tao :-|
1. Before starting to provide examples one should state that the
semicolon at the end of a line is *required* and this even if one
only provides one command. Some languages do not use any
semicolons, others do not require them, others require them if on
writes several commands on a line, others to separate commands (so
that one does not need a semicolon for only one command) and others
require them to end each command (even if it is the only one). Used
to Ruby's and C's syntax I know both extremes.
2. Use of 'const'. I do not think it is a good idea to use 'const' for
an object that can be modified afterwards. I think a word like
'freeze' would be more mnemonic.
freeze c =3D "old";
c =3D "new" # Warning: Redefinition of frozen value
freeze c =3D "new";
Note that the exclamation 'Freeze!' means 'Stop moving!' - one
would typically hear it in restricted areas of the "use of deathly
force permitted" type.
3. Lists. It should be noted that the last list element can be
followed by a comma. This may seem unimportant but if you
initialize an array using
primes =3D {
"Charly",
"Juliet",
"Mike",
"Oscar",
};
and want to provide the values in a sorted manner, it is very
helpful that all lines can end in a comma - this makes it possible
to use the editor's sort function without any post-editing (i.e.
removing comma on last line, adding comma where it is missing).
4. Parentheses. It should be stated that they are not optinal in Tao.
5. number(). I do not think that the following is intended behavior:
a=3D"ff";
b=3D"FF";
print(number(a,16), "\n");
print(number(b,16), "\n");
255
-289
It is highly unexpected that a) the results are differnt and b) the
second one negative.
6. unpack() behaves unexpectedly as well:
a=3D"abc";
print(unpack(a), "\n");
b=3D"=E4=F6=FC";
print(unpack(b));
results in:
{ 97, 98, 99 }
{ -61, -92, -61, -74, -61, -68 }
Now the latter cannot be. Of course using Unicode the umlauts map
to *two* values but in no case the result should be negative. Let's
take a look at the correct values and do a well educated guess on
the reason for the discrepancy:
ruby -e 'a=3D"=E4=F6=FC";(0..a.length-1).each{|n| puts a[n]}'
195 # 195 - 256 =3D -61
164 # 164 - 256 =3D -92
195 # 195 - 256 =3D -61
182 # 182 - 256 =3D -74
195 # 195 - 256 =3D -61
188 # 188 - 256 =3D -68
Guess has shown to be correct: It's the old signed char vs.
unsigned char issue. Nothing SAR[2] cannot fix.
[1] Nothing very serious but: I am no native speaker of English and
yet I stumble over 'to Tao Language' - AFAIK one usually writes 'An
Introduction to the Tao Language', 'An Introduction to Tao',
'Introducing Tao'.
So much for now,
Josef 'Jupp' SCHUGT
|
