Carl Mäsak
Carl Mäsak
But... `{{{x}}} = {{{y}}}` is not always an error, that's the thing. If this were a 100% thing, we'd just outlaw it and move on. The thing that's a prevalent...
Of course, this issue no longer prescribes an _assignment protocol_ as such. With `solidify`, there's no longer any need for `lvalue` and `Location`. The `solidify` macro is more of a...
I'm less enthused by `solidify` now than back when I thought of it. Or rather, I still think it could be very useful as a tool to make code look...
Any "value access" instruction which typically returns an rvalue — whether't be a lexical access or some kind of indexed access on a container — factors into first getting hold...
> The "different `Location` in different frame" problem still looms large, and means that `Location` is a reified thing at runtime, not just a compiler construct. I just thought of...
I think I forgot to mention at the time, but the hard-won [gist](https://gist.github.com/masak/4c1807775f60b86294e27c950f33dfd6) that currently represents our best guess at how macro hygiene will actually be implemented — and see...
> `lvalue()` can also be used in mainline code. But culturally this should be some kind of weak taboo, since Locations outside of macros can only be used to confusing...
> If escape analysis cannot show that the value doesn't escape, code optimizations will be globally switched off. It's possibly worse than that. If we want to have a fair...
As I start implementing `Location` in a branch, I quickly realize two things: * `Location` values, at least the useful ones, are *backed*, in the same sense `Int`s and `Array`s...
All through this issue I've pretty consistently used `lvalue` as the name of the macro. I'm now having second thoughts and want to call it `location` instead. Why? Because it's...