On Wed, 2007-05-09 at 08:48 +0200, Nicolas Pouillard wrote:
> I totally disagree, having a single "end" keyword is not ambiguous at
> all since all construction are distinguished by the beginning and that
> end markers are not optionals.
I once read a good book on programming .. actually it was about
how to be a good COBOL programmer .. but it introduced a fairly
radical new idea to me. It's the analogue of what physicists
call 'perturbation analysis', which is a study of satellite orbits.
The basic orbit formula is trivial (orbits are elliptical,
discovered by Kepler if memory serves correctly).
What isn't trivial is what happens to an orbit if it is
*disturbed* by a small amount, such as by
* meteorite impact
* proximity of the moon
* non-spherical shape of the earth
* atmosphere
* firing adjustment rockets
* etc
Now, the point is that one needs to analyse programs and
programming languages the same way: considering stability
in the face of change.
Non-specific 'end' keywords are far less stable than specific
ones. The problem is not just quite bad, but well known
to be bad, and many countermeasures exist, including the latest
version of Vim (7.x) providing automatic {()} balancing
highlighting by default.
Some languages use 'endif' some use 'end if' and some use 'fi',
whereas some even allow constructions to be labelled (Ada
I think):
<<myloop>> for .. end myloop;
The point is the issue here isn't ambiguity of a correct
program .. but ambiguity of an *incorrect* program.
On the other hand,
if .. then .. else .. endif
gets formatted like:
if ...
then ..
else ..
endif
which wastes a line for the endif, and that contributes to
clutter.
I actually like the idea used in Haskell and Python:
visual block structure (indent/undent). The problem
is it doesn't scale very well to great depths and long
bits of code .. you need to de-localise the code or
switch to free form (resp).
> Having "endmatch", "endif", ... is really too boring.
It is a bit.. but Ocaml is worse, because when you do
need a specific close point, you have to edit the start
as well:
match .. with ...... (* goes forever *)
is rewritten as
begin match .. with ... end
which is quite painful.
> IMHO the readability don't doesn't apply on these construct since they
> should be short sized in clean code.
That's a reasonable position..
> It's more about closing classes,
> modules... And here I prefer comments:
.. heh .. and in these cases Felix uses { } .. so actually
Felix has it backwards. The long constructions don't get terminated
with heavy terminators as they should, whereas the light ones do
when they shouldn't.
--
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
