4 ms·

I've skimmed through the "mutable value semantics" paper: do I understand correctly that authors suggest replacing references and pointers with either: a) neste

I've skimmed through the "mutable value semantics" paper: do I understand correctly that authors suggest replacing references and pointers with either: a) nested structs (with some indirection via `Any` with runtime-checks); b) array indices? The following phrases got my eye: "It is reasonable to ask, then, how we can use mutable value types to represent self-referential data structures, such as doubly linked lists and directed graphs. In fact, any arbitrary graph can be represented as an adjacency list. For example, a vertex set might be represented as an array, each element of which contains an array of outgoing edge destination indices.". I don't see how one can reasonably implement doubly-linked list without re-inventing memory heap and some kind of garbage collection in the implementation. UPD: found some discussion at https://github.com/orgs/val-lang/discussions/736 https://github.com/orgs/val-lang/discussions/736 , seems that there will be some escape hatches akin to Rust's `unsafe`. That resolves all issues, and "whether the safe subset of Val is enough for reasonable application" question is open to long years of debate.

nine_k 3y ago
Indeed, you can reinvent memory by using arrays, and using array indices instead of pointers. It's much less silly than one could think, because these indices are locked to your particular data structure (doubly-linked list, graph, etc) and cannot be manipulated to access anything else in the program, at least not easily. This applies bot to the compiler checking that, and to the attempts to crack the program.
- yeputons 3y ago
  > these indices are locked to your particular data structure Are they, though? Consider I have a linked list (or a map/dictionary, or any data structure that allows removal of arbitrary elements). I add elements with indices 1, 2, 3, 4, 5. I remove elements with indices 2 and 4. I'd like to make memory consumed by these elements available again. At the same time I don't want to change indexing scheme of the whole data structure. So I have to keep "holes" with indices 2 and 4 at the very least. After few million operations that may become very inefficient. In a typical language, that would be resolved by having a global allocator that allows indices 2 and 4 to be reused in neighboring data structures. If I don't implement a global allocator that shares indices between objects (as that kills the whole point), I consume more memory than needed and rely on my own clunky implementation of garbage collection/defragmentation, don't I?
  - Woodi 3y ago
    I think lists as arrays is just example of what can be used instead of pointers. Also section was titled "representation something" so probably it is just one possible low level representation of linked lists. And Val can have standard library of lists, including represented as arrays with build in online reindexing. But this makes Val high level lang so not really system programming language... But what irks me is: why not just program in plain C with passing structs by value ?? All aliasing will be gone and probably compilers already know how to deal with that. "Becouse somehing_hard_to use is included" is just dumbing thing down and not gaining much. Lack out of bound indexes checking ? That's like one function. Call it everywhere :) Programmers need to learn dealing with reality (what features CPU's gives) instead of being castrated. Becouse moving problem somewhere else do not annihilate problems. Maybe we need high level CPU's and some hw level guarantees some engineers can bake in :) But that can end like hardware on call register saving :)

nine_k 3y ago

Indeed, you can reinvent memory by using arrays, and using array indices instead of pointers. It's much less silly than one could think, because these indices are locked to your particular data structure (doubly-linked list, graph, etc) and cannot be manipulated to access anything else in the program, at least not easily. This applies bot to the compiler checking that, and to the attempts to crack the program.

yeputons 3y ago
> these indices are locked to your particular data structure Are they, though? Consider I have a linked list (or a map/dictionary, or any data structure that allows removal of arbitrary elements). I add elements with indices 1, 2, 3, 4, 5. I remove elements with indices 2 and 4. I'd like to make memory consumed by these elements available again. At the same time I don't want to change indexing scheme of the whole data structure. So I have to keep "holes" with indices 2 and 4 at the very least. After few million operations that may become very inefficient. In a typical language, that would be resolved by having a global allocator that allows indices 2 and 4 to be reused in neighboring data structures. If I don't implement a global allocator that shares indices between objects (as that kills the whole point), I consume more memory than needed and rely on my own clunky implementation of garbage collection/defragmentation, don't I?
- Woodi 3y ago
  I think lists as arrays is just example of what can be used instead of pointers. Also section was titled "representation something" so probably it is just one possible low level representation of linked lists. And Val can have standard library of lists, including represented as arrays with build in online reindexing. But this makes Val high level lang so not really system programming language... But what irks me is: why not just program in plain C with passing structs by value ?? All aliasing will be gone and probably compilers already know how to deal with that. "Becouse somehing_hard_to use is included" is just dumbing thing down and not gaining much. Lack out of bound indexes checking ? That's like one function. Call it everywhere :) Programmers need to learn dealing with reality (what features CPU's gives) instead of being castrated. Becouse moving problem somewhere else do not annihilate problems. Maybe we need high level CPU's and some hw level guarantees some engineers can bake in :) But that can end like hardware on call register saving :)