Re: Glasgow haskell vs. Lispworks


Jon Harrop wrote:

Markus E.L. 2 wrote:
Jon Harrop wrote:
Paul Rubin wrote:
Well, these like identity and equality are only meaningful within the
language semantics. In a pure FPL, two expressions have the same
identity if the denote the same value. Memory locations may be part
of the implementation but aren't in the language semantics.

Does that not have a grave cost in terms of memory consumption?

Why do you suspect so? Because one cannot mutate structures?

No, I use physical equality (identity) even in purely functional settings.

I do not understand you reply. The grave cost in the pure case is
probably not memory consumption, but that any comparison has actually
to be recursive and can't take the shortcut of physical equality. But
I think that perhaps the compiler is smart enough to know when it can
take the shortcut.

Or is there any other reason? Personally I see it as a further step
down the same path that started with abandoning malloc/free style
memory management and introducing garbage collection. It leaves all
decisions on actual copying to the compiler or run time environment
and actually buys them a lot of freedom as far as caching is
concerned (only think SMP and what it implies if there are no
mutable memory locations).


I use physical equality in OCaml as an optimization, to test for unaltered
results.

Ah, I understand. This is a very special case, though: It won't work
with mutable structures, would it?


For example, an 'a -> 'a map that avoids all allocation is no rewrites are
done:

let id_map f a =
if a = [||] then a else
let b = ref a in
try
for i = 0 to length a - 1 do
let e = f a.(i) in
if e != a.(i) then begin
b := Array.copy a;
(!b).(i) <- e;
raise (Start (i+1))
end
done;
a
with Start start ->
let b = !b in
for i = start to length a - 1 do
let e = f a.(i) in
if e != a.(i) then b.(i) <- e;
done;
b

or a sort that can return the input list without copying it:

# let rec sort = function
| [] -> []
| h1::t as list -> match sort t with
| h2::t when h1>h2 -> h2::sort(h1::t)
| t' -> if t==t' then list else h1::t';;
val sort : 'a list -> 'a list = <fun>

When handling symbols, I hash cons strings and compare them for physical
equality knowing that it represents semantic equality.

This is indeed a good idea.

I appreciate that this can all be done without using physical equality, but
can that be done efficiently (particularly without allocation)?

The only hope one can entertain here is that the compiler is smart
enough. But probably you're right: This is one of the effects that
make Haskell slower.

Regards -- Markus




.

Relevant Pages

  • Re: Glasgow haskell vs. Lispworks
    ... Memory locations may be part ... of the implementation but aren't in the language semantics. ... Does that not have a grave cost in terms of memory consumption? ... I use physical equality even in purely functional settings. ...
    (comp.lang.functional)
  • Re: Glasgow haskell vs. Lispworks
    ... under any change to A. If I can't change A, equality implies identity... ... Surely two different expressions can evaluate to equal values that are ... Even 'language semantics' needs to be mapped to real machines ... with finite memory. ...
    (comp.lang.functional)
  • Re: Glasgow haskell vs. Lispworks
    ... Memory locations may be part ... of the implementation but aren't in the language semantics. ... Does that not have a grave cost in terms of memory consumption? ... : bool = false ...
    (comp.lang.functional)
  • Re: 9 ball racking order
    ... computer instructions were programmed on paper tape ... Individual memory locations within ... memory occurs when the sequence of locations are in the same ...
    (rec.sport.billiard)
  • Re: Explorer.exe - Application Error
    ... > locations that could not be read and memory locations that could not be ... A malware BHO or ShellExtensionHook may cause this "memory error". ... Ramesh, Microsoft MVP ... > had no internet access. ...
    (microsoft.public.windowsxp.help_and_support)