Betr.: Re: [clean-list] slown down by time annotation

Paul de Mast demast.pjf at avans.nl
Wed Jul 20 13:22:20 MEST 2005


Hello,

The current behavior is confusing and I have reported this as a bug some time ago. The Clean language report says in chapter 3.6:

biglist1 = [1..10000]    // a graph (if defined locally) 
biglist1 = [1..10000]    // a constant function (if defined globally) 
biglist2 =: [1..10000]    // a graph (always) 
biglist3 => [1..10000]    // a constant function (always)

So we may assume that f =: e will ALWAYS define a graph and f => e will ALWAYS define a function. The above 4 example definitions are clear, but unfortunately not implemented in the current compiler 

If you extend the above definition for =,=: and => with the currently implemented exception (local typed definitions are always functions):
1. the definition becomes unnecessary confusing
2. you limit the situations we can type. I like to be able to give type specifications to as much (local) definitions as possible. In the current situation the (operational) semantics changes when a type specifications is added to a local constant expression, so I consider this as an untypable definition.
3. even worse: type specifications are sometimes necessary to solve overloading. So the current implementation even limits the situations we can express.

I propose that the Clean compiler respects the following typing rule:

If a definition is typable, then including the same type specification as the derived type specification (by the compiler), the (operations) semantics remains the same.

So I propose not to change the definition in the language report, but to consider the current implementation for local constant definition,using = or =: with a typespecification as a bug.

Regards,

Paul de Mast



>>> Arjen van Weelden <arjenw at cs.ru.nl> 16-7-2005 16:18 >>>
Hi,

I you give a type to ANY expression in a where clause, it becomes a
function (and is lifted internally).
The array is therefore no longer shared. This explains the slowdown that
is caused by the three uses of the array, which is constructed three times.
Please try adding t` = t to the where clause and using t` in the body of
the function (instead of t).
I don't think that this behaviour is documented anywhere, and I agree that
it is not what you would expect.

regards,
	Arjen

On Thu, 14 Jul 2005, [ISO-8859-1] Valéry Croizier wrote:

> Hello Clean users.
>
> I have written a few programs to taste the language, and the one below
> is about arrays.
> What puzzles me is the type annotation commented out in 'showflam',
> which makes the program 3 times slower.
>
> Can anybody explain me what's happening ?
>
> Valery.
>
> swap :: *{#Int} !Int !Int -> *{#Int}
> swap t i j
>   #! ti = t.[i]
>   #! tj = t.[j]
>   = {t & [i] = tj, [j] = ti}
>
> reverslice :: !Int !Int *{#Int} -> *{#Int}
> reverslice i j t
>   | i < j     = reverslice (inc i) (dec j) (swap t i j)
>   | otherwise = t
>
> flam :: *{#Int} -> *{#Int}
> flam t
>   #! end = t.[0]
>   | end == 1 = t
>   | otherwise  = flam (reverslice 0 (end - 1) t)
>
> showflam :: !Int -> [Int]
> showflam n
>   #! t1 = t.[1]
>   #! t2 = t.[n / 2]
>   #! t3 = t.[n - 1]
>   = [ t1, t2, t3 ] where
> //  t :: *{#Int} // slows down 3X
>   t = flam {{x+1 \\ x <- [1..n]} & [n-1] = 1}
>
> _______________________________________________
> clean-list mailing list
> clean-list at science.ru.nl 
> http://mailman.science.ru.nl/mailman/listinfo/clean-list 
>


_______________________________________________
clean-list mailing list
clean-list at science.ru.nl 
http://mailman.science.ru.nl/mailman/listinfo/clean-list




More information about the clean-list mailing list