Should arguments be assignable?

[smarr]

In SOM-st/TruffleSOM#17, @gpummer found that TruffleSOM departed from SOM semantics.
SOM allows assignment to arguments, while TruffleSOM doesn't.

@krono @mhaupt @charig, any opinion on this?

If I am not mistaken, most Smalltalk do not allow assignment to arguments.
And personally, I don't think there is a good reason for them to be assignable.

@charig, what did you do in Mate?

[krono]

On 01.11.2018, at 22:57, Stefan Marr ***@***.***> wrote: In SOM-st/TruffleSOM#17, @gpummer found that TruffleSOM departed from SOM semantics. SOM allows assignment to arguments, while TruffleSOM doesn't. @krono @mhaupt @charig, any opinion on this? If I am not mistaken, most Smalltalk do not allow assignment to arguments. And personally, I don't think there is a good reason for them to be assignable. @charig, what did you do in Mate?

Squeaks says no: I think this is fair.

[smarr]

I think, I'll consider this a bug, and define the desired behavior of SOM to be that arguments are read-only.

Though, testing this is going to be not straight forward. Will need some external testing infrastructure, since parser errors are usually fatal, I think.

Thanks @gpummer for finding this!

[charig]

I almost did not change the parser. So I guess in Mate the behavior is the same. I'd have to check.
This said, it is clearly not the "intended behaviour". In Mate there are capabilities for redefining reading & writing of locals, but for arguments only reading.
I neither see any benefits of assigning to args.

[mhaupt]

Hello. Doesn't the original SOM have bytecode instructions for assigning to arguments? If so, it's intended. As for the issue at hand, I couldn't say. There are points in favour of either way. An argument can be taken as just another local variable, or as a special thing that can't be modified. Neither is right or wrong; it's a language design decision. The Blue Book interpreter spec allows for storing into arguments (see pp. 598/600), whereas it's illegal in the language (p. 49). So ... :-)

…

Am 02.11.2018 um 14:27 schrieb Stefan Marr ***@***.***>: I think, I'll consider this a bug, and define the desired behavior of SOM to be that arguments are read-only. Though, testing this is going to be not straight forward. Will need some external testing infrastructure, since parser errors are usually fatal, I think. Thanks @gpummer for finding this! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[smarr]

@mhaupt good point.
Indeed, there is a bytecode for it: https://github.com/SOM-st/som-java/blob/master/src/som/interpreter/Bytecodes.java#L44

public static final byte POP_ARGUMENT     = 10;

And it does

  private void doPopArgument(final int bytecodeIndex) {
    // Handle the POP ARGUMENT bytecode
    getFrame().setArgument(
        getMethod().getBytecode(bytecodeIndex + 1),
        getMethod().getBytecode(bytecodeIndex + 2),
        getFrame().pop());
  }

https://github.com/SOM-st/som-java/blob/master/src/som/interpreter/Interpreter.java#L118

The easiest change of course would be to fix TruffleSOM, and add a test.
Hmmm.

[smarr]

Ok, #8 added a tests to ensure that the arguments are assignable as they are in the original SOM.

[gpummer]

I will try to add the required functionality to TruffleSOM. At the moment it seems somewhat difficult to me. But that is fine, SOM is for learning:)

[smarr]

@gpummer happy to talk you through if you want help :)