ALGOL 68 has the nice property that there are no variables/lvalues: There are names that are bound to constant values, and there are values that are addresses. "int x := 5" is shorthand for stack-allocating an int and binding x to its address (so the type of x is "ref int").
-
Show this thread
-
This seems much nicer than lvalues, which are probably much more complicated than most people think. The trouble is that dereferencing everything would be very annoying syntactically. ALGOL 68 solves that by implicitly coercing "ref t" to "t". I don't really like that.
2 replies 0 retweets 0 likesShow this thread -
For example, if you write "f(x)" in C, you know that x is being passed by value. If you write "f(x)" with implicit dereferencing, you can't tell without knowing the types. There are some other potential ambiguities. Is there a better solution to this?
1 reply 0 retweets 0 likesShow this thread -
Replying to @shachaf
Those are the three sane designs: all values constant but there are pointers you can read or write; both constant and mutable values but you can only copy or pass mutable as pointers by taking addresses; and const+mutable+references+pointers.
2 replies 0 retweets 1 like -
Replying to @TimSweeneyEpic
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.
2 replies 0 retweets 0 likes -
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
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.
-
-
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 -
- 9 more replies
New conversation -
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.