If I wanted to just write code that 'works' I'd use assembler. I care about making elegant ways to express things we say often. That's what this forum's about, right? enq is evidence that even serial assignment needs (some) love.
My point is that languages can't read our minds. Making a change that makes one thing easier often makes things harder in a different area.
So the question is: which is more preferable? Making sequential assignment the default, or parallel?
Enq is a single data point. A single function that would not benefit much either way. Using it as evidence that a very common operator (assignment) should be one way or the other seems like a weak argument to me.
Consider this: if making = parallel would not affect 99% of code, and would make certain types of code shorter, then whether enq relies on sequential access or not is pretty much irrelevant, right? It can just use `do`, and in exchange for that the other code would get nice benefits.
So yes, enq is evidence for sequential assignment... but this thread (psetf) is evidence for parallel... so we're right back where we started, at a point where the evidence doesn't say much one way or the other.
But, let's suppose that we decided to make = sequential... like it is right now. Now you need to make a new macro (like pset) to describe parallelness. On the other hand, if = were parallel, it's trivial to use `do` to make it sequential: no need to write a new macro. This also makes it obvious that the assignments are indeed happening one after the other, which may be important to you (or may not be).
Thus the evidence that we have right now suggests making = parallel by default, and that is why I said it seems silly to use enq as evidence that = should be sequential.
P.S. I'll note that I was agreeing with you about making parallel the default; I was noting that we shouldn't make it sequential just because of it breaking enq, especially since there is such an easy work-around (using `do`) Apparently I was misunderstood, I'm sorry.
> But, let's suppose that we decided to make = sequential... like it is right now. Now you need to make a new macro (like pset) to describe parallelness. On the other hand, if = were parallel, it's trivial to use `do` to make it sequential: no need to write a new macro.
Minor objection here: No. I could call it trivial to do the work of describing parallel assignments:
(with (new-a b new-b (+ b a))
(= a new-a b new-b))
And, in fact, I would feel the need to write a new macro to express sequential =. "Gar dammit I hate writing "do" and "=" a bunch of times." To me, both things are trivial, and I just might be more annoyed by the latter.
