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?
-
Show 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 -
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
I'm curious whether you wrote much code in this language. This approach is certainly conceptually cleaner than lvalues, but I can't tell whether the syntactic noise is worth it in practice (especially for C-style code with a lot of mutation -- it's easier to pull off in e.g. ML).
1 reply 0 retweets 1 like
Not a huge amount. In my experience, it adds enough noise that it makes you really think about whether mutability is needed in each usage case.
-
-
Replying to @TimSweeneyEpic @shachaf
Tim this concept of language that you have created that more features have you added?
0 replies 0 retweets 0 likesThanks. Twitter will use this to make your timeline better. UndoUndo
-
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.