It's pretty odd that an lvalue is "a thing with an address" and a pointer is "the address of a thing". They're two views on the same thing but it works surprisingly well. Algol 68 has automatic dereferencing which seems worrying to me, but manual dereferencing gets cumbersome.
-
-
Replying to @shachaf @TimSweeneyEpic
One thing that e.g. Haskell references can't do is "IORef (a,b) -> IORef a" (struct lvalue field access), which is of course critical in a language like C that cares about memory layout. This IRC conversation a while ago helped clarify things for me: http://slbkbs.org/ski-mercury.txt
1 reply 0 retweets 0 likes -
Replying to @shachaf
Mutable substructure references can be done with sound semantics. I built a version of this for transactional memory and it’s really succinct. So that’s is a Haskell IORef design limitation rather than a fundamental problem.
1 reply 0 retweets 1 like -
Replying to @TimSweeneyEpic
Yes, agreed. I'd like to see a low-level language that makes this distinction cleanly with minimal syntactic noise and semantic confusion, but it seems tricky.
1 reply 0 retweets 0 likes -
Replying to @shachaf
In a toy language, I used p^ and p:=p^+1 for reading and writing, p^.x and p^[0].x for reading and then accessing a field, and p.x and p[0] for obtaining a substructure pointer which looks just like an ordinary pointer. Super clean once one accepts the need for explicit reads.
1 reply 0 retweets 2 likes -
Replying to @TimSweeneyEpic @shachaf
The language also has a concept of first class failure, so that p^[2] can fail immediately if p^ has less than 3 elements, and p[2] which always succeeds but can then fail later when dereferenced in that case.
1 reply 0 retweets 4 likes -
-
Replying to @TimSweeneyEpic
Yes, I think this is the way to go if you make reads explicit. https://en.wikipedia.org/wiki/BLISS is close. I'd kind of like to avoid overloading "a.x" if possible -- it has different meanings for pointers and values, though it should be guaranteed that "(a^).x = (a.x)^".
1 reply 0 retweets 0 likes -
Replying to @shachaf @TimSweeneyEpic
I suspect something like that is unavoidable, though, and I should accept that a struct specifies not only memory layout (field-offset map) but value-level meaning (which is also used for calling conventions etc.). The alternative is C-style "." vs. "->" separation, I guess.
1 reply 0 retweets 0 likes -
Replying to @shachaf @TimSweeneyEpic
I'm a bit worried that code like "a[i^+j^] = min(a[i^]^, a[j^]^)" gets much less readable than "a[i+j] = min(a[i], a[j])" with too many dereferences, though I haven't programmed enough in this style to be sure.
3 replies 0 retweets 0 likes
Yes, imperative style code full of mutable variables becomes a lot more ugly this way.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.