DO .1$.1 <- #7, and other assignments that assign two different values to the same variable
ais523
pretty clear (assume nothing else is overloaded and no constants have
had their values changed, and I'm using C-INTERCAL notation here):
DO .4 <- .3/".1$.2"
DO .3 <- #7
It assigns #3 to .2 and #1 to .1. (In C-INTERCAL, if the right
compiler switches are used, the same effect can be achieved in one
statement as
DO .1$.2 <- #7
).
What I was wondering about is what the effect of
DO .4 <- .3/".1$.1"
DO .3 <- #7
ought to be. At the moment in C-INTERCAL, it assigns both #3 and #1
to .1 in some order, and it ends up with exactly one of those values.
However, I'm not convinced that this is desired behaviour. Some of the
possibilities as to what to do here:
- Produce a run-time error if the values being assigned are different
- C-INTERCAL's current behaviour of assigning one of the values to the
variable
- Multithread and/or go quantum so as to assign both the values to the
variable
- Anything else I haven't thought of
What do people think the correct behaviour here ought to be? What does
CLC-INTERCAL do in such situations?
On a related note, if a mesh appears on the left of an assignment (by
overloading, for instance), and there's one way to do the assignment
that changes the mesh and another way that doesn't, is it a good idea
to preferentially do the assignment in a way that doesn't change the
mesh? I'm thinking of expressions like
DO .1~#14 <- #3
(it would be interesting, conceptually neat, non-orthogonal and still
unlike any other language if that assigned #6 to .1; unfortunately,
other possibilities like assigning #3 to .1 and #65535 to #14 exist).
I'm assuming that the meshes still end up changing in value if the
expression can't be forced to work any other way.
--
ais523
Claudio Calvelli
> What I was wondering about is what the effect of
> DO .4 <- .3/".1$.1"
> DO .3 <- #7
> ought to be. At the moment in C-INTERCAL, it assigns both #3 and #1
> to .1 in some order, and it ends up with exactly one of those values.
> However, I'm not convinced that this is desired behaviour. Some of the
> possibilities as to what to do here:
> - Produce a run-time error if the values being assigned are different
> - C-INTERCAL's current behaviour of assigning one of the values to the
> variable
> - Multithread and/or go quantum so as to assign both the values to the
> variable
> - Anything else I haven't thought of
> What do people think the correct behaviour here ought to be? What does
> CLC-INTERCAL do in such situations?
Well, CLC-INTERCAL at present assigns #3 to .1 - not intentionally, as
a matter of fact I never given any thought to multiple side effects
on the same variable or constant.
On the other hand, "intercalc", the INTERCAL calculator, produces a splat,
but this is a bug and will be fixed in 1.-94.-2
> On a related note, if a mesh appears on the left of an assignment (by
> overloading, for instance), and there's one way to do the assignment
> that changes the mesh and another way that doesn't, is it a good idea
> to preferentially do the assignment in a way that doesn't change the
> mesh? I'm thinking of expressions like
> DO .1~#14 <- #3
At the moment, CLC-INTERCAL handles a mesh like any other subexpression,
so the above has the same effect on #14 as:
DO .1~.2 <- #3
DO #14 <- .2
However, it is undocumented what exactly gets assigned, the only
"official" line is that there will be assignments so that if you
now use .1~#14 its value will be #3
> (it would be interesting, conceptually neat, non-orthogonal and still
> unlike any other language if that assigned #6 to .1; unfortunately,
> other possibilities like assigning #3 to .1 and #65535 to #14 exist).
> I'm assuming that the meshes still end up changing in value if the
> expression can't be forced to work any other way.
The unary division has the same problem: if you assign the current
base to the result of an arithmetic unary division, then by definition
almost any number will be acceptable. A similar problem occurs with
the logical unary division. The result, in this case, is to find a
random number which fits, and assign that to the operand.
Perhaps the select operator can be modified to assign random numbers,
as long as the result is correct. And, to deal with a mesh, it could
check what bits are already available, and only change them if it
is absolutely necessary. In other words,
DO .1~#14 <- #3
would not change #14
DO .1~#8 <- #3
would need to change one bit of #8 to make things work. It would,
however, keep bit 3 unchanged, so that the choice is somewhat
restricted.
As an aside, this has just found its way on my "TO DO" list for 1.-94.-2
C
--
The address in the "From" header won't work. Email to "usenet" at "intercal" dot
"dyn-o-saur" dot "com" may or may not reach me, depending on how far it manages
to go through the spam filter, and other conditions which I won't disclose.