3 ms·

FP languages are almost exclusively pointer heavy; without it they could not do structure sharing which it what allows persistent data structures with efficient

by Veedrac 11y ago

FP languages are almost exclusively pointer heavy; without it they could not do structure sharing which it what allows persistent data structures with efficient operations. FP languages also rely heavily on partial pattern matching, type classes with vtable-style indirection and even GC for cycle collection. Closures in FP languages are boxed, too, almost without exception. In Haskell, even integers are boxed by default. You don't observe many of the problems of references due to their immutability, but this isn't to say they're not there. The "value-heavy" language closest to FP I know of is Rust, and many functional idioms are plain irritating to use because of it. Maybe Clojure is different, but I'd be surprised. Perhaps you were in disagreement about the use of the word "value" in "value type", which I meant in the D or Rust sense of a stack-allocated, indirection-free type.

deleted 11y ago
[deleted]
gary_bernhardt 11y ago
You're talking about implementation now. The text you quoted said "references' introduction into high level languages", not "references' use in the implementation of high level languages". The quote was about languages' conceptual models, not their underlying implementation forced by a particular type of CPU that code written in the language happens to be running on. A language can present value semantics while doing structural sharing using references underneath, as Clojure's persistent data types do.
ratboy666 11y ago
"even integers are boxed by default" Um... why? For example, 2 is.. 2. 2 is not 3. If I "box" 2, can I then make it 3? Some very old FORTRAN implementations actually allowed this: subroutine x(j) write(,)j j = 3 return do 1 i = 1,2 1 x(4) 4 3 (sorry... it's been years). Note that the reference is immutable (j refers to a single location) -- but the value is boxed (4 is put into a memory location). And this is why this can even work. FredW
- Veedrac 11y ago
  Your code is quite hard to read, especially as I don't know Fortran. Can I have it with indentation (indent each line 2+ spaces to make a code block)? --- Integers are boxed because Haskell's semantics almost exclusively deal with boxed types (eg. you can't pass unboxed types to most functions). The optimizer might specialize some functions for boxed types, but this is a transparent optimization and does not affect semantics.

by Veedrac 11y ago

deleted 11y ago

[deleted]

gary_bernhardt 11y ago

You're talking about implementation now. The text you quoted said "references' introduction into high level languages", not "references' use in the implementation of high level languages". The quote was about languages' conceptual models, not their underlying implementation forced by a particular type of CPU that code written in the language happens to be running on. A language can present value semantics while doing structural sharing using references underneath, as Clojure's persistent data types do.

ratboy666 11y ago

"even integers are boxed by default" Um... why? For example, 2 is.. 2. 2 is not 3. If I "box" 2, can I then make it 3? Some very old FORTRAN implementations actually allowed this: subroutine x(j) write(,)j j = 3 return do 1 i = 1,2 1 x(4) 4 3 (sorry... it's been years). Note that the reference is immutable (j refers to a single location) -- but the value is boxed (4 is put into a memory location). And this is why this can even work. FredW

Veedrac 11y ago
Your code is quite hard to read, especially as I don't know Fortran. Can I have it with indentation (indent each line 2+ spaces to make a code block)? --- Integers are boxed because Haskell's semantics almost exclusively deal with boxed types (eg. you can't pass unboxed types to most functions). The optimizer might specialize some functions for boxed types, but this is a transparent optimization and does not affect semantics.