Re: Obstacles for Tcl/Tk commercial application development ?

Óscar Fuentes wrote:
> Show the user a message akin to "I asked you an integer, stupid!".

Sure. I'm just trying to figure out why Tcl's lack of typing makes this more difficult.


Óscar Fuentes wrote:
Darren New <dnew@xxxxxxxxxx> writes:

Óscar Fuentes wrote:
Uh? Once I say a variable, structure member, function return value, etc
has type X, it is guaranteed that it has type X, and nothing can change
it.
And once I put an integer into a variable in Tcl, it stays an integer
until I assign something else to that variable.

I think we are on different wavelengths here. On a static typed
language, if variable X is declared as integer it will remain so forever
and it will always safe to use X where you want an integer.

Yes. I'm aware of what static typing means.

First, please forget C as an example of static typing.

Fair enough.

Second, the *compiler* is what guarantees you are putting an integer in
the variable. It will reject your code, plain an simple.

Hmmm. Tell that to atof().

My point is that Tcl's types aren't "random" in any sense. They don't change out from under you. If I say "my procedure always returns an integer", and that's true, then it's safe to pass it to
expr {23 + [my_procedure]

If I can't manage to make sure I return the right type, chances are I'm not returning the right value either.

I guess that's the real question. I just don't have any more trouble returning the right type than I do returning the right value.

In short: when my design says that certain place (variable, list index,
dictionary item, whatever) must keep certain kind of data (numbers, for
example) a dynamic typed provides zero help. When I deal with complex
data structures, this can turn in a serious source of errors.

Huh. Oddly, I've never really had the "it's the wrong type of data" problem. Wrong value, sure, but wrong type? Rarely, if ever.

Correct type systems defines what happen with integer overflows. Either
they define a type that is an integer modulo 2^32, so never "overflows",

Right. This is how C works. Now go try to FTP a file >4G from somewhere, and see if you don't have problems because you overflowed the "integer". :-)

or throws an exception when an overflow happens,

Not unlike expr throwing an exception when you add 4 to "Hello". :-)

How do you get the wrong types into variables in Tcl without doing any
I/O? [open] always returns a file handle. [expr] always returns the
type indicated by the expression you pass it. [llength] always returns
an integer. How do you get the "wrong type" in there?

There is no need for variables for writing wrong code due to type bugs:
expr {2 + "hello"} is enough.

If that's the quality of code you're dealing with, then sure, I guess the lack of static typing can be a problem.

OK, then, given that you have a variable with the "wrong type", why do
you need to check it?

To make sure the wrongness does not propagate elsewhere, or because at
the check point I can prevent the application state being messed.

Ummm. Ok.

What do you *do* when you get a variable with the wrong type that you
need to "check it all the time"? Checking the variable is the right
type is only useful if you're going to do something about it other
than throw an error.

If an interface expects an integer, and the result of passing something
else is indefined, I'll better check that I'm passing an integer, or
throw an error, or roll back the operation to some usable state.

I see. Yeah, well, I figured if you fail at some point, you better be able to recover. Maybe it's because I write long-running stuff that usually flogs at a persistent store, so it just seemed obvious that throwing an error in the middle should never corrupt things.

From the point of view of type soundness, C and C++ are badly broken,
because things like returning integers from open(), among others

Fair enough.

Ok, so you catch that error because you are a good programmer, not
because the compiler is working for you. Thanks, you are making my point

Except that "{}" was, in theory, also a valid value. It just didn't happen to match what I expected, so I tracked it down. Type systems wouldn't catch that.

Usually, when I code, I know the language well enough to
know what types the expressions return, so I don't wind up with the
wrong types in variables.

Is this still correct when you deal with sets of libraries that sum up
thousands of functions and data structures, writing hundreds of
thousands of lines of code?

Usually, sure. If I understand what the values are, I implicitly understand what the types are. I've worked with systems that implement structured interactive editors, compilers, and interpreters and systems for displaying the code as it runs, for formal languages in Smalltalk. Never really had a problem with not understanding the types of variables.

Occasionally, I'll pass an array name where I meant to pass a
key/value pair (i.e., call "process $alpha" instead of "process [array
get alpha]", but that gets caught right away.

Yea, once your execution path goes through that point. As I said on a
previous message, it is impossible to check all execution paths,

If you've written code that you never executed before you released it, I think type errors are only a tiny part of your problems.

A language with a sound type systems is at least as safe as any
dynamic language.

Sure. No dispute there.

You are confusing data types with state.

Actually, the concept is called "typestate". A file handle that's open can be the same type as a file handle that's closed, with a different typestate, and the compiler can track typestates for you just as it tracks types.

Ensuring that a variable is initialized before first use is a degenerate version of this.

Mars probes have crashed because the were using miles instead of
kilometers, which is clearly a type error.

Indeed! A sane type system would prevent this.

OK. if you're talking about a static typing system that would prevent you from adding integer miles to integer kilometers, and would know that horizontal pixel count can't be added to vertical pixel count, but those can be multiplied to yield pixel count, then sure, that's a type system that can detect a bunch of errors you might otherwise make.

There aren't a whole lot of popular languages that can do this.

Even C++ would do it.

Not without exponential amounts of work defining it all, tho.

You'll agree with me that code composed of:

do A (may fail because it opens a file name and may not exist).
do B (may fail because it writes a socket and the peer may close it
anytime)
do C (may fail because the format of the input data is wrong)

and so on... not only is boring, but pretty scary.

I'm not sure why it would be scary. Depending on what the "do" bits are doing, you're describing (say) an entire web server there.

In dynamic typed languages, something as simple as this:

proc foo {a b} {
return [expr {$a + $b}]
}

may fail because some caller is passing something that are not numbers.

Sure. And in a statically typed language, it may fail because the caller is passing two numbers that when added overflow the valid range of return values. Or because the caller is passing the number of rows in the table instead of the sum of the values in the table.

That's all. Static typing reduces failure points. Dynamic typing brings
you more flexibility. Choose your poison.

I'll grant you that good static typing in a safe language reduces failure points of the type where you have (say) two integers that shouldn't be addable (like miles and kilometers). It also helps if you have enough typestate (like Hermes) or enough preconditions/postconditions (say, Eiffel) that you can catch at compile time that you might be passing a closed file to a procedure that's going to read it.

I just don't think that in Tcl, getting the types right is anywhere near as difficult as getting the values right.

--
Darren New / San Diego, CA, USA (PST)
On what day did God create the body thetans?
.

Relevant Pages

  • Re: How come Ada isnt more popular?
    ... A language with a Hinldey-Milner type system ... fixed size strings, unbounded strings, suffix tree. ... container varies, the element does not. ...
    (comp.lang.ada)
  • Re: Early Adopters Wanted -- New Language Salmon
    ... Are you claiming Salmon's type system is inconsistent? ... typed language, any improperly typed program is simply illegal. ... there is a type of all regular expressions in Salmon. ...
    (comp.lang.misc)
  • Re: Intermediate forms (again?): worthwhile?
    ... replacement language for C, but with a completely different type ... reasons. ... language's type system in C and still get high performance. ... code to look like the source code. ...
    (comp.compilers)
  • Re: Help with Conditional Code
    ... If you fail to quote, I will fail to respond further] ... the option to select another language. ... Your unwillingness to quote has dropped the implementation ... Books today and could not find one book on Jscript. ...
    (microsoft.public.scripting.jscript)
  • Re: Functional programming books for practitioners?
    ... Try expressing that kind of stuff even with Haskell's or SML's type system. ... If you follow that path to its logical end, you'll get a separate type for each precondition and postcondition in the system, which is clearly unmanageable. ... So you have to draw the line somewhere - what goes into types, and what goes into assertions. ... this includes a language where the type system has the full power of reasoning over integers. ...
    (comp.lang.functional)