This is supported in Ratcl 0.9:
It's also a major departure from most of the other operators, in that it modifies a view in place.
Yuck, side effects. Open the floodgates! I'm kind of worried...
Maybe it would be better to switch everything to use copy semantics. That means something as trivial as:
$view set 123 name "John Doe"
will need to be rewritten as:
[$view set 123 name "John Doe"] var view
That's a bit verbose. It could be streamlined by introducing a ":=" operator, which does the same thing:
$view := set 123 name "John Doe"
The same notation would then also work for other operators. So instead of the in-place modifying "addcol", it would become a clean functional version with no side-effects. Side-effects, i.e. redefining the view would then be done as follows:
$view := addcol salary:I {100 * age}
The first example on this page would change slightly, to:
X := addcol C:I {B + ?} 100
It all revolves around the question of whether side-effects should be made completely explicit in everything Ratcl does. I think it is worth doing, because then all data manipulation becomes "by value", with variables used as mutable objects.
-jcw
As long as any performance penalty can eventually be eliminated or minimized, I think it is an excellent idea to completely ban implicit side-effects, and instead always use an explicit but handy operator like ":=".
Note that S (e.g., R) basically works that way, but doesn't have a handy operator like ":=". So in S you have to write:
x <- x +1 not: x := +1
S however, does have the nice property that you can index into existing data structures and use the result on the left hand side of an assignment. E.g., this works nicely, and sets rows 10 through 20 of the column named "c" to the value of foo:
table[10:20,"c"] <- foo
--atp, 2004/05/23 05:56 EDT
Posted at May 25/2004 08:36 PM:
jcw: Thanks for the comments. Yes, I'm working towards the no-side-effect approach. It's not trivial: the changes are represented as diffs internally, but multiple changes will be merged into one change set. The trouble is that once a second reference exists to a specific state, a new change set needs to be introduced. See [link] for other comments about this issue.
Notation-wise, Ratcl won't be able to use the R/S syntaxes you've described. I'm sure there are other ways which are not too inconvenient.
Your last example implies implicit looping, i.e. matching up dimensions on either side of the assignment. It's a powerful concept (also present in the J and K vector languages).
Oh yes, what you call "implicit looping" above, S calls "The recycling rule". I'm not familiar with J, K, or the other APL variants, but the "recycling rule" for vectors is one thing that S really got right. It is very useful. --atp, 2004/06/11 13:16 EDT
Posted at May 27/2004 09:15 AM:
jcw: Neil Madden has come up with what one could call "by value objects", in his new TOOT design [link]. It might an interesting option for Ratcl (without altering much of the underlying structure).