[Taoscript-lang] (no subject)

[Josef 'J. S. <ju...@gm...>]

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