tag:blogger.com,1999:blog-8383004232931899216.post1836212039991082357..comments2023-11-01T11:47:57.046-04:00Comments on Designing ParaSail, a new programming language: A load-and-null-out operationTucker Tafthttp://www.blogger.com/profile/08866496974237052847noreply@blogger.comBlogger4125tag:blogger.com,1999:blog-8383004232931899216.post-59005034129423783142011-08-07T15:59:02.992-04:002011-08-07T15:59:02.992-04:00(me again)
yet another option is :.=
this way, th...(me again)<br /><br />yet another option is :.=<br />this way, the implementation of the above example is:<br />mytree :.= left<br />since the problem is only about sub-objects, having the dot is very consistent with :+= (although it only goes one level at a time.bestdndhttps://www.blogger.com/profile/08618543381520585454noreply@blogger.comtag:blogger.com,1999:blog-8383004232931899216.post-19634013359362827052011-08-07T15:50:31.567-04:002011-08-07T15:50:31.567-04:00bestdnd wrote:
another option to overcome the &qu...bestdnd wrote:<br /><br />another option to overcome the "get-and-null" thing, is to have assignment statements return the ORIGINAL value of the assigned variable.<br /><br />That is essentially what the "::=" deferred assignment was doing. However in trying to write some programs using this, I found it hard to read and not very intuitive. Switching to the idea of a "move" operation "<==" seems more natural, and reads pretty well.Tucker Tafthttps://www.blogger.com/profile/08866496974237052847noreply@blogger.comtag:blogger.com,1999:blog-8383004232931899216.post-2265567807406083732011-08-07T15:44:33.820-04:002011-08-07T15:44:33.820-04:00(my first time seeing the language, so it might be...(my first time seeing the language, so it might be inconsistent with other things or have beed discussed in the past).<br /><br />another option to overcome the "get-and-null" thing, is to have assignment statements return the ORIGINAL value of the assigned variable.<br /><br />reasoning:<br />since the old data is no longer needed, there is no need to copy the data again, just to return a reference to it.<br />since we don't use the new value any more than needed to the original assignment, we don't need to copy it either.<br />because the original value is mostly unwanted, we need to destroy it anyway.<br /><br />the use on the tree:<br />mytree:=(mytree.left:=NULL)<br /><br />potential problems:<br />* it's inconsistent with C/C++ way (where assignments return the new value)<br />* it forces the compiler work with referencesbestdndhttps://www.blogger.com/profile/08618543381520585454noreply@blogger.comtag:blogger.com,1999:blog-8383004232931899216.post-2369261069474418942011-08-06T11:35:31.290-04:002011-08-06T11:35:31.290-04:00On further reflection, this seems like overkill, s...On further reflection, this seems like overkill, since probably 90% of the time the use will be to load a value and leave a "null" behind. Hence, I think we are going to go for a "move" operation, probably "<==" which means move the value from the RHS to the LHS, leaving the RHS null. For example, to move the tail of a list to be its head:<br /> List <== List.Next;<br />To move the right subtree to be the left subtree:<br /> Tree.Left <== Tree.Right;<br />If we adopt "<==" to mean "move" then it probably makes sense to change the swap operation from ":=:" to "<=>", since the latter is easier to notice, and is more like a "move" than an "assignment" (since assignment generally involves copying). For example, to switch left and right subtrees:<br /> Tree.Left <=> Tree.Right;<br />Or to simply swap X and Y:<br /> X <=> Y;<br />This seems to make the swap operation more readily recognizable than the subtler ":=:".<br />-TuckTucker Tafthttps://www.blogger.com/profile/08866496974237052847noreply@blogger.com