Re: Tcl Switch case

On Feb 19, 10:59 pm, Andreas Leitgeb <a...@xxxxxxxxxxxxxxxxxxxxxxxx>
wrote:
tom.rmadilo <tom.rmad...@xxxxxxxxx> wrote:
The new syntax, mostly the second form, will likely lead
to many new types of hard to track down errors.

This is, what I (we?) just don't buy.
The scenario of someone forgetting the acual value
and thus having his explicit "--" taken as value is
a very specific case of unluck, that is surely not
described with "many new types of ... errors."


I think what is missing in this analysis is that seasoned developers
don't write code which causes the error that this change fixes, so
your 'fix' is obviously directed at helping out the idiot programmer,
or maybe the lazy programmer, who knows full well the syntax, but
can't be bothered to type in a few extra characters. And this is
because the expert guru doesn't care that some future idiot programmer
will have to read their code and try to figure out what happens in
every case.

It isn't hard to imagine new types of errors. I demonstrated a
handful, including one very baffling one:

% switch -regexp -matchvar a {puts hi} b {puts e} default {puts d}
d

The only reason this works is because the options are not correctly
handled. Since when did option handling become a burden to the
developer of a command?

My thesis is that there could be a good reason to change the syntax of
a command, and one reason is to align with what the byte compiler
could digest. But the current changes actually move the syntax into a
more ambiguous state. If you look at my previous post, there are some
notes from the source. It appears that more code would benefit from
byte compiling if the '--' argument was respected as an option
termination. In fact, if this was used as the sole determinant for
byte compiling, only the old two arg 'bug' would fail to be included
in the list of forms which could be byte compiled.

Again, assuming that the point of the change is to support the byte
compiler, you must recognize that this only happens in certain
contexts. It only happens in a protected context. If you have a script
in a file which has a switch command, this doesn't get compiled. So
the change has no benefit for uses of [switch] at this level.

Given that the effective result of arg processing must be consistent
regardless of compiled or not, I have to reverse my previous claim
that you can include the two arg switch in the list of compiled
commands. The most code would be compiled if '--' was respected as an
option ending option. The convention would also reflect 15 years
experience.

Maybe the current maintainers should reflect on the Ancient wisdom of
the Ancients. Why would some old fart use an option '--' if not to aid
in parsing the meaning of a command? I know that there is a theory
that commands key off of the number of arguments, but this is just a
theory. Another theory, one enshrined in Tcl, is that arguments are
processed _in order_. This is the concept of parsing. Parsing is made
very easy if you 'parse', and that means to process an input from
first char to last, with no backtracking. Otherwise you are just
guessing where any potential errors show up. This is just a divide an
conquer strategy: when you are in the context of option processing,
your rules are more limited. This is good. Programming is not like
throwing spaghetti against the wall and hoping that something sticks.
The requirement for '--' is no different than requiring the use of {}
to avoid substitution. No doubt this is a convention. So what? Think
about the weird conventions of other languages. Python uses invisible
whitespace as some kind of substitute for block definition. Invisible
syntax? Unfortunately there isn't much difference between the Python
weirdness and this particular case. Maybe the [switch] syntax is
worse. At least with Python the compiler can detect the syntax, even
if it isn't visible in the source code. But with [switch] we find that
a certain laziness dominates. How else to interpret the fact that a
bug has persisted for 15 years, but has never kept anyone from writing
a correct program? This is the most well behaved bug in history.

My thesis, or theory, is that if you want to use the argument of
adaptation to the byte compiler to support syntax changes, the result
will be more requirements on the syntax, and less support for
ambiguous cases where the command has lots of options. The byte
compiler is great at supporting unambiguous syntax, this is ripe
fruit, but this cuts, maybe slashes, against what we see with the
changes to [switch].

And as I said before, relying on that typos will result
in thrown errors, is a truely bad strategy. It's even
a bad strategy with static languages (java, c++,...),
and with dynamic langs, where pieces of code aren't
ever checked until they're actually executed, it's
much much worse so.


All of my examples are errors which don't throw errors! This is my
point. Stuff that looks okay to the parser/compiler, but is a
mistake.

compile this one simple form with two args, I see no benefit in the
change, especially a change based on trying to eliminate a bug which
never caused an actual error.

Perhaps not for your definition of "error", which seemingly doesn't
apply to switches on integral values, that unexpectedly can be
negatives.
For many others, the old behaviour *was* an error.


An error corrected by using the correct syntax, no?

* There must be at least one option, --, because without that there is no
* way to statically avoid the problems you get from strings-to-be-matched
* that start with a - ...

That *is* a bug. Comments should eventually be updated to reflect what
really happens. Care to submit a bugreport at sf?
Just add the exception of the two-args case.

Wait, what is the bug? Not sure what I can report as a bug given that
'what is a bug' has been redefined.
.

Relevant Pages

  • Re: Compiler quality (was: Extending discriminant types)
    ... files they use for syntax checking for each Ada specifications. ... even are clarified as BUG free. ... error is not a compiler BUG. ...
    (comp.lang.ada)
  • Re: Help in Monad
    ... Please file one bug containing all the issues. ... Microsoft Command Shell Development ... most of the command syntax information for a cmdlet's help ... > what to do when they're "wrong" for a given cmdlet. ...
    (microsoft.public.windows.server.scripting)
  • Re: The compiled application cannot find my file?
    ... Command line is OS syntax, ... when program is a MATLAB compiler, arg1, arg2 is passed to ... function binary = rgb2binary(rgbpath, binarypath) ...
    (comp.soft-sys.matlab)
  • Re: ASP.NET command line compiler?
    ... > You probably want to use the compiler for the language, ... Visual Studio is not a language itself. ... > VB command line cimpiler name: ... > You can look up the syntax for multi file assemplies etc, ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Simple output problem
    ... it can be a difficult bug to find because the compiler ... isn't going to complain because it is valid C syntax. ... Prev by Date: ...
    (comp.lang.c)