Re: K.I.S.S. Factor (Re: Numerics)

Richard A. O'Keefe wrote:
> 	> data: HASHED_DICTIONARY[INTEGER, STRING] is
> 	> 	once
> 	> 		Result := { HASHED_DICTIONARY[INTEGER, STRING] 
> 	> 					<< 
> 	> 						1, "one";
> 	> 					     	2, "two";
> 	> 					     	3, "three"
> 	> 					>>}
> 	> 	end
> 	We are very proud of this new facility. What do other think ?
> 
> Serious ugliness.  Worse still, pointless redundancy.
>>From the context, we *KNOW* (and the compiler could know) that the
> result *MUST* be a HASHED_DICTIONARY[INTEGER,STRING].  So what can
> possibly be the point of forcing the programmer to say it again?
Actually, in most real situations, you would have:

    data: DICTIONARY[INTEGER, STRING] is
       once
          Result := { HASHED_DICTIONARY[INTEGER, STRING]
                      <<
                         1, "one";
                         2, "two";
                         3, "three"
                      >> }
       end

> Let's consider the example again:
> 
>     data: HASHED_DICTIONARY[INTEGER, STRING] is
>        once
>           Result := << [1,"one"], [2,"two"], [3,"three"] >>
>        end
Again, we don't want to create extra TUPLEs.
I continue to think that we made a huge progress from the old manifest 
array notation to the new facilities presented in 
SmartEiffel/tutorial/manifest_notation.e
> 
> 	It is important for us to make Eiffel a good language able to get the 
> 	very best performances.
I confirm that.
> 	
> Are we talking about the same language?  Eiffel is a language where the
> most simple obvious way to write a string results in a run-time copy.
I don't understand.
> Eiffel is a language where all array accesses are range checked (at
> least in principle) _without_ the compile-time bounding of integer
Wrong while using the -boost compilation mode.
BTW, our point is that the most important goal of assertions is for code 
documentation and to debug (to be short).
> variables that makes it safe and simple to omit index checks in Pascal
> and Ada.  Eiffel is a language without a standard binding to the BLAS.
Right. There are no standards for Eiffel. Sad.
> And so on.  Then there's I/O.  In a class on information retrieval, I
> recently demonstrated to students that Java was not yet a good choice
> for building at least the indexing component of an IR system because of
> the truly amazing slowness of its I/O compared with C, _despite_ compilation
> to native code (gjc code was even slower than Sun's JIT).  While Eiffel I/O
> isn't as intrinsically slow as Java I/O, you're not really going to match C.
You cannot speak seriously of Eiffel I/O. There is no Eiffel I/O. There 
is an io _library_ we provides. And you can say that this library is bad 
but not that Eiffel is bad. A library is not a language.
It is easy to reach the C speed by calling the correct C I/O function 
from Eiffel.

> It doesn't really matter if some statement creates a dozen, or a thousand
> objects, provided that statement is not executed very often.
For you but not for us. Again, compare the old situation to the new one.
We made many progresses.

Anyway, I have the feeling that we won't find an agreement ;-)
As usual best regards,

-- 
--------------------------------------------------------------
[email protected] -- IUT (Nancy 2) -- INRIA Lorraine
http://SmartEiffel.loria.fr  --  The GNU Eiffel Compiler
POST: Loria, B.P. 239,54506 Vandoeuvre les Nancy Cedex, FRANCE
Voice:+33 0383913140 Mobile: +33 0665362381 Fax:+33 0383581701