Worst scenario I can think about is that someone ask how could you write this Pascal code in Unicon:" (Local_min(x,y,z) set x,y,z to local minimum of some function closest to the original x, y, z values.)
local_min(x1, x2, x3)
local_min(x1, x3, x4)
local_min(x1, x3, x4)
local_min(x2, x3, x4)
write(x1, x2, x3, x4)Even with "every x1|x2" or similar solution with x1:=:x2:=:x3:= ... (thenks to to Steve Hunter) or mentioned x1,x2,x3:= simplicity of Pascal is not reached, and if only straight structures can be returned, i think it cannot be much better than this one (untested):
local_min(X:=[x1,x2,x3])
local_min(Y:=[X[1], X[2], x4])
local_min(Z:=[Y[1], X[3],Y[3]])
local_min(W:=[Y[2], Z[2], Z[3]])
write(Z[1],W[1],W[2],W[3])This topic attracted lot of attention in past, as can be seen from archives. (Goerwitz, 1987) learnt Icon as first language, but he liked references as he seen it in C or Pascal. It doesn't mean bad design, people will always find some reoccurring pattern that contains syntactical redundancies and try to remove it, like there is always another one prime.
Something like options "original", and "copy" in expressions, procedure declaration or passing arguments could be maybe more Iconish, higher level (references, i.e address is low level). For example, structures are now passed with "copy of reference" semantics. As result, if called from main()
procedure Change(A) #A is copy of reference, thus A:=["X"] # (1) has no effect in main() A[1]:="X" # (2) has effect in main() end
one cannot really understand difference between (1) and (2) without "low level thinking." If A is passed as "original" then both (1) and (2) would have effect, if it is passed as "copy" then neither one. There would be more interesting consequences, and perhaps we cannot get rid of references completely ...
================= Charles mentioned that (!L:=:x) shouldn't fail. Here is comment.
Griswoldean expression/failure is very similar to natural language, it is less abstract than Boolean/mathematical language, but then there is less redundancy. Boolean (x>y) returns us TRUE which we (unless we are philosophers) want to transform in something more usable, while Unicon guess that we want y. Or x, so we write (y<x.) In those two statements, x and y are like subjects in natural language. Look how similar it is "John downloaded Unicon manual and read it."
Subject, John, is carried through statement, and whole statement fails if he didn't downloaded manual. If it succeeds, John as subject is used further and we can concatenate "and started programming."
When we use that advantage in Unicon, we must be sure that expression is correct (like in other languages), but also that we established right subject. That is the case in (!L:=:x) idiom, we wanted plain x:=!L, but also !L as subject. Natural language is very flexible in doing that: "Unicon manual was downloaded by John" .
Mentioned "<" operator has its dual, >, so we can return either x or y, but it has same sense everywhere - in member(x,y), put(x,y) ... Special but important case is =:, (!L=:x) is perfect fit here, it can fail, and it can be faster. There are two ways to achieve it, either consistent introduction of duals for operations, (seems redundant, but if noone see the problem with < and > then why not) or, more general, notation for subject, i.e. something like (x :=subject !L):= ... where subject is near variable that should be returned.
It is perhaps strategical decision, whether Griswoldean concept should be developed further and see how far it can reach, or leave it as it is, and proceed in other directions.
OK, I'll stop here also.
----
Kazimir Majorinc, Zagreb, Croatia
