[GRASS-dev] programming languages & GRASS scripting

[Ivan Shmakov]

>>>>> Glynn Clements <glynn at gclements.plus.com> writes:

 >>> IMHO, it's a pretty primitive and opaque programming language
 >>> (e.g., you have to use another scripting language like awk to do
 >>> floating point math).

 >> That's quite a frequent practice (consider, e. g., `expr' in Tcl, or
 >> Cpp for C.)  I don't think it should be afraid of.

 > At least Tcl's "expr" is actually part of the language.

	So is Cpp, and Shell `expr', as long as POSIX is considered.

 > But Tcl isn't a particularly good example here; very few languages
 > have a separate function for arithmetic.

	There's nothing special in arithmetic.  A separate little
	language may be employed for almost any task.  And it may be
	implemented either at the core of the language, or as an
	extension.

 >>> However, I think that it would benefit the community settle on a
 >>> new scripting "standard" that is truly cross- platform and an
 >>> easier, more up-to-date, powerful, and easier to use
 >>> language. There are several good candidates for this, but Python
 >>> has a number of pragmatic advantages in the current context.

 >> Indeed, it may be a reasonable decision.  (Though it'd be
 >> interesting for me to know what are the particular problems with
 >> Tcl, which is both portable and was used in GRASS for quite some
 >> time?)

 > Tcl isn't much better than the Bourne shell as a language. The main
 > issue is its reliance upon textual substitution.

	Does it?

 > Look at the number of uses of "eval" and "subst" in e.g. gis.m; every
 > one of those demonstrates a deficiency in the language.

	Please forgive me if I sound too harsh here, but the gis.m
	source demonstrates the ignorance of its authors of the Tcl
	basics far better than the deficiency of the Tcl language.

	Please consider, e. g.:

% set a 2
2
% expr $a + 1
3
% expr { $a + 1 }
3
% set b "2 * 2"
2 * 2
% expr $a + 1
5
% expr { $a + 1 }
can't use non-numeric string as operand of "+"
% 

	AFAIK, the use of `expr $x ...' was abolished as error-prone a
	while ago.  The code using `expr { $x ... }', apart from being
	easier to understand and debug (since it doesn't rely on the
	textual substitution), also runs faster, as the whole form is
	byte-compiled just once (while `expr $x ...' is re-interpreted
	each time it's evaluated.)

	You may want to check the Tcler's Wiki [1] for the way how it
	works in Tcl.

 > Textual substitution and "eval" make it easy to write code which only
 > "mostly" works, but falls down e.g. for values which contain
 > syntactic characters. E.g. it's common for code which deals with
 > lists which fails when list items contain spaces.

	Yet again, please consider:

% set a "puts" ; set b "Hello, world!"
Hello, world!
% eval $a $b
can not find channel named "Hello,"
% eval [ list $a $b ]
Hello, world!
% 

	The latter form is the one that is expected to be used most of
	the time.  You may want to check [1] again.

	BTW, as the usual Tk `-command' option's argument is passed to
	`eval', the proper way to use a variable substitution in its
	argument is, e. g.:

    Button $row.b ... \
        -helptext [G_msg "labels file to display"] \
		-command [ list GmLabels::select_labels $id ]

	and not:

    Button $row.b ... \
        -helptext [G_msg "labels file to display"] \
		-command "GmLabels::select_labels $id"

	(To some extent, one may think of Tcl `eval' as operating on
	lists, and not strings.)

 >>> What this means is that we need to have Python people volunteer to
 >>> begin to rewrite existing Bash scripts in Python and begin writing
 >>> any new scripts in that platform so that we can have the critical
 >>> mass to encourage others to learn it and write in it. A couple
 >>> people have started on this.

 >> I'm afraid that an attempt to rewrite /all/ the Shell scripts in
 >> Python will both take time and bring some mess along.  Would you,
 >> e. g., consider an untested 100-lines Python substitute for a
 >> 50-lines Shell script (that's known to be working for years) to
 >> encourage anyone to write in Python?

 > The deficiences of the Bourne shell as a programming language are
 > such that I would tend to have more faith in a minimally-tested
 > Python re-write than in a shell script. Programs written in a real
 > language tend to either work or not work, while shell scripts tend to
 > sort-of, kind-of mostly work.

	This doesn't match my experience, as I've seen quite a few
	programs written in the ``real languages'' which are ``sort-of,
	kind-of mostly work.''  (May [2] serve as a recent example.)

	The better one knows a language, the less it will surprise him
	(and the others.)

[1] http://wiki.tcl.tk/
[2] http://trac.osgeo.org/grass/changeset/30281