🚀 go-pugleaf

In article <2582@enea.se> sommar@enea.UUCP(Erland Sommarskog) writes:
>
>On type conversions: (Explicit or not?)
>  The key word here for me is data abstraction. Even integer to integer
>may be wrong.
>(Using Pascal here)
>   SIA_range : (some interval);      (* Index in the IA *)
>   DIL_range : (some interval);      (* Index in a block *)
>Assignment from type to the other does seem like a error.

Logically, it is an error.  C does not provide data abstraction on this level;
if you want it, use a language like C++.

Looking at Pascal (the other extreme :-)), if I define two arrays of two
different sizes I must use two different routines to manipulate them.  This
makes things like string processing nearly impossible (most uses of strings are
with variable length).

>It is these kinds of logical mistakes I talk about. Not the risk
>of losing some accuracy. (But allowing reals to integer without
>explicit conversion was something I thought only Fortran did. 
>C does also?)

C does do type conversion automatically but in a well-defined way.  (See K&R
section 2.7)

>
>Array-index checking:
>
>If you write checks yourself, that seems like a source of error to me.
>
>Another comments on range checking in loops: It's only safe to leave
>them out if the index can't be altered while in the loop. Don't 
>know about C, but this is certainly possible in Pascal. Ada, on other
>regards the loop index as a constant.

In C, there is no real concept of a loop index; 'for' statements are much more
general in C than in Pascal.  (I will not describe the mechanism here; look at
K&R section 1.3)  Also, arrays in C are not necessarily indexed; pointers may
be used insted (abstractly, these are equivalent, however).

>Generally, a good compiler should give you the possiblity to surpress
>checking, either for the entire program, or just a part of it. So you   
>can always the remove the checks on delivery. The quetsion is just: Dare
>you? The hostile user's may provide data you've never dreamt of.

What actually happens when a program gets an out of range error?  Usually, the
program just dies.  If you don't dare remove the checks, you shouldn't be
programming!  I would rather put the checks in myself so that I may be able to
perform a more graceful handling of possible bugs.

These types of runtime checks do not in any way insure that my code is more
correct; they only provide a way of stopping badly written programs.  The only
thing that these checks might do is help someone find an error in their code
(although as an experienced C programmer this information would not usually
help me).

In an earlier article you mentioned that we should all buy faster hardware to
compensate for run-time checks.  I'm sorry, but when I am sorting 100,000 +
records I do NOT want the execution time to be tripled just to perform checks
on each operation.  Faster hardware should NOT be an excuse for badly-written
software!

>Yes. But he should get as much support as possible from the language. Thus,
>the compiler should suspect any input.

Most compilers I know of do this on a syntactic level.  You are proposing that
this should be done on a semantic level.  Very few languages are this
well-defined.  Pascal, for example, at the end of a FOR loop, the index is
undefined.  Are you stopped from using it again before assigning it a value?  I
think not.  Should I be stopped from using it, or should the value of an index
be defined at the end of a FOR loop?  I prefer the latter, but that's just my
opinion.

>> A programmer is simply a
>>person who translates concepts from one language (that of the application) to
>>concepts in another language (that of the programming model).  It is very
>>similar to natural language interpreters.  If I were to hire a Russian
>>to interpret for me, I would want one who understood both Russian and English.
>
>Not really. Your Russian interpreter doesn't need to have a full notion
>of what you are talking of as long as he gets the words right.

This just isn't true.  If it were, why isn't there a computer program available
that will do this?  David Letterman tried this type of language translation
once.  He took the Beatle's song "A Hard Day's Night", had it translated into
six different languages (English -> Russian, Russian -> French, ...) and back
into English.  Funny, the meaning wasn't quite the same as the original song.

>What have this to with C? Well, a powerful language with good possibilities
>abstracting the data is a help here to see: "What is to be done?". 
>Does C have the good devices for this? I doubt. Strong type checking is
>a must here, I believe.

First of all, if you want C to become Pascal why don't you use Pascal instead?
Strong type checking only helps you find more errors at compile time, that's
all.  The function of English is not to stop me from expressing myself badly,
so why should the function of C be to stop me from programming badly?  USE THE
RIGHT LANGUAGE FOR THE RIGHT PURPOSE!!  If I need strong type checking, I would
pick a language like C++.


Can we discuss modern languages now?  I'm tired of the 'which language is best'
argument.

My favorite language is Icon :-) :-); this language is VERY loosely typed.  My
problems usually don't come about because of type differences (Note:  since it
is an interpretive language it does provide the equivalent of runtime checks).
This language helps me find my logic bugs (I don't have to worry about silly
little things like stacks and lists; they are built into the language.

One of the philosophies of Icon is that every function should either return a
useful value or fail (i.e., x < y returns y if true; otherwise fails).  Another
thing is that functions can return more than one value (generators; i.e.,
find(s1,s2) returns all the positions of s1 in s2, and fails when it can't find
any more).  I love these concepts; what do others' think?

BTW, Icon is relatively modern (it was created in the late '70s), and is the
successor to SNOBOL4 and SL5.

What I would like to know are interesting concepts people have found in other
languages, and from these discussions try to decide what we think would belong
in (to coin a phrase from the Icon Newsletter) 'the Perfect Programming
Language'.
-- 
 _ __			NEVIN J. LIBER	..!ihnp4!ihlpf!nevin1	(312) 510-6194
' )  )				"The secret compartment of my ring I fill
 /  / _ , __o  ____		 with an Underdog super-energy pill."
/  (_</_\/ <__/ / <_	These are solely MY opinions, not AT&T's, blah blah blah