Smalltalk › Squeak › Squeak VM

Methods with more than 15 args sketch

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

13 messages Options

Clément Béra

Methods with more than 15 args sketch

Hi everyone.

It seems that some people are struggling with the fact that methods in Pharo (and other Smalltalk on top of Cog) cannot have more than 15 arguments. Typically the problem arises while generating Smalltalk code or porting code from other Smalltalks.

I have been thinking for a while about this problem. In this mail I write a small sketch to solve it, it's something that could go to production very quickly and that requires almost only image-side changes. Eliot has already reviewed and approved the sketch, but I''d like to know if someone is strongly against that change.

The generic idea is to change the send calling convention at the bytecode level, using a temp vector to pass overflowing arguments.

The normal calling convention in the Smalltalk bytecode is as follows:

push receiver

push arg 1

push arg 2

....

push arg N

send selector

N is limited to 15 arguments due compiled method header & bytecode encoding.

In the new design, if the send has less than 15 arguments, the calling convention remains the same. Over 15 arguments, the overflowing arguments are passed in a temp vector in a similar way to the closure temp vectors.

The convention will look like that:

push receiver

push arg 1

push arg 2

....

push arg N

popIntoArray N-15 values

send selector

The compilation of a method with more than 15 arguments is then changed:

- As for temp vectors, the 15th arg array can't be become or read-only, hence the temp vector instructions can be used to access the overflowing arguments through the 15th arg.

- the compiled method header is still marked with 15 arguments

In addition one needs to change CompiledMethod to:

- allow larger frames (instead of 56 we could allow 128 or 256)

- have numArgs answering the right number of methods with many arguments. I think the number of arguments could be in the additional method state in this case as it is very uncommon.

And to change the fall-back of a couple primitives, such as:

- Object>>perform: withArgs:

- Object>>perform: withArgs:inSupedClass:

- BlockClosure>>valueWithArgs:

This design would allow methods to up to 141 arguments.

What do you guys think ?

Nicolas Cellier

Re: Methods with more than 15 args sketch

For my personal use which was essentially calling FFI with more than 15 args, i used a single array for all arguments.

This was more simple, and no optimization of the first 15 was needed since most of the time the long method is just a wrapper that passes parameters thru.

I don't know if it's the case for other 3rd party code, but it would be worth inquiring...

https://github.com/nicolas-cellier-aka-nice/smallapack/wiki/SmallapackSqueak
http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-April/102183.html
http://bugs.squeak.org/view.php?id=2918

The (Old) Compiler code is at

http://www.squeaksource.com/Smallapack.html
Smallapack-Compiler.trunk-nice.6.mcz

2016-06-16 8:10 GMT+02:00 Clément Bera <[hidden email]>:

Hi everyone.

It seems that some people are struggling with the fact that methods in Pharo (and other Smalltalk on top of Cog) cannot have more than 15 arguments. Typically the problem arises while generating Smalltalk code or porting code from other Smalltalks.

I have been thinking for a while about this problem. In this mail I write a small sketch to solve it, it's something that could go to production very quickly and that requires almost only image-side changes. Eliot has already reviewed and approved the sketch, but I''d like to know if someone is strongly against that change.

The generic idea is to change the send calling convention at the bytecode level, using a temp vector to pass overflowing arguments.

The normal calling convention in the Smalltalk bytecode is as follows:

push receiver
push arg 1
push arg 2
....
push arg N
send selector

N is limited to 15 arguments due compiled method header & bytecode encoding.

In the new design, if the send has less than 15 arguments, the calling convention remains the same. Over 15 arguments, the overflowing arguments are passed in a temp vector in a similar way to the closure temp vectors.

The convention will look like that:

push receiver
push arg 1
push arg 2
....
push arg N
popIntoArray N-15 values
send selector

The compilation of a method with more than 15 arguments is then changed:
- As for temp vectors, the 15th arg array can't be become or read-only, hence the temp vector instructions can be used to access the overflowing arguments through the 15th arg.
- the compiled method header is still marked with 15 arguments

In addition one needs to change CompiledMethod to:
- allow larger frames (instead of 56 we could allow 128 or 256)
- have numArgs answering the right number of methods with many arguments. I think the number of arguments could be in the additional method state in this case as it is very uncommon.

And to change the fall-back of a couple primitives, such as:
- Object>>perform: withArgs:
- Object>>perform: withArgs:inSupedClass:
- BlockClosure>>valueWithArgs:

This design would allow methods to up to 141 arguments.

What do you guys think ?

Clément Béra

Re: Methods with more than 15 args sketch

Yeah I was wondering too, do we pass all arguments in an array or only the overflowing arguments ?

I don't mind implementing either solution. I would like to know what are the pros and cons. I understand that passing all arguments as an array is simpler to implement and maintain. What are the other advantages and disadvantages ?

On Thu, Jun 16, 2016 at 8:36 AM, Nicolas Cellier <[hidden email]> wrote:

For my personal use which was essentially calling FFI with more than 15 args, i used a single array for all arguments.
This was more simple, and no optimization of the first 15 was needed since most of the time the long method is just a wrapper that passes parameters thru.
I don't know if it's the case for other 3rd party code, but it would be worth inquiring...

https://github.com/nicolas-cellier-aka-nice/smallapack/wiki/SmallapackSqueak
http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-April/102183.html
http://bugs.squeak.org/view.php?id=2918

The (Old) Compiler code is at

http://www.squeaksource.com/Smallapack.html
Smallapack-Compiler.trunk-nice.6.mcz

2016-06-16 8:10 GMT+02:00 Clément Bera <[hidden email]>:

Hi everyone.

It seems that some people are struggling with the fact that methods in Pharo (and other Smalltalk on top of Cog) cannot have more than 15 arguments. Typically the problem arises while generating Smalltalk code or porting code from other Smalltalks.

I have been thinking for a while about this problem. In this mail I write a small sketch to solve it, it's something that could go to production very quickly and that requires almost only image-side changes. Eliot has already reviewed and approved the sketch, but I''d like to know if someone is strongly against that change.

The generic idea is to change the send calling convention at the bytecode level, using a temp vector to pass overflowing arguments.

The normal calling convention in the Smalltalk bytecode is as follows:

push receiver
push arg 1
push arg 2
....
push arg N
send selector

N is limited to 15 arguments due compiled method header & bytecode encoding.

In the new design, if the send has less than 15 arguments, the calling convention remains the same. Over 15 arguments, the overflowing arguments are passed in a temp vector in a similar way to the closure temp vectors.

The convention will look like that:

push receiver
push arg 1
push arg 2
....
push arg N
popIntoArray N-15 values
send selector

The compilation of a method with more than 15 arguments is then changed:
- As for temp vectors, the 15th arg array can't be become or read-only, hence the temp vector instructions can be used to access the overflowing arguments through the 15th arg.
- the compiled method header is still marked with 15 arguments

In addition one needs to change CompiledMethod to:
- allow larger frames (instead of 56 we could allow 128 or 256)
- have numArgs answering the right number of methods with many arguments. I think the number of arguments could be in the additional method state in this case as it is very uncommon.

And to change the fall-back of a couple primitives, such as:
- Object>>perform: withArgs:
- Object>>perform: withArgs:inSupedClass:
- BlockClosure>>valueWithArgs:

This design would allow methods to up to 141 arguments.

What do you guys think ?

timrowledge

Re: Methods with more than 15 args sketch

Regardless of any particular design ideas to implement this, I’d just like to say.. No.
Nononono.
Bad design to use huge parameter lists. What next - allowing 1 billion arguments for someone that thinks each pixel in a large bitmap needs to be an argument?

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Compromise, says Prof. Trefusis, is stalling between two fools

Jan Vrany

Re: Methods with more than 15 args sketch

On Thu, Jun 16, 2016 at 4:57 PM, tim Rowledge <[hidden email]> wrote:

Regardless of any particular design ideas to implement this, I’d just like to say.. No. Nononono. Bad design to use huge parameter lists. What next - allowing 1 billion arguments for someone that thinks each pixel in a large bitmap needs to be an argument?

I say...Yes.

Yesyesyesyes.

Think of generated code. Think of interop. There are too many too low limits already (number of instance variables comes to mind)

More recently designed architectures set limits a little higher. Something like 65535 :-)

Jan

tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Compromise, says Prof. Trefusis, is stalling between two fools

Eliot Miranda-2

Re: Methods with more than 15 args sketch

In reply to this post by timrowledge

Hi Tim,

> On Jun 16, 2016, at 8:57 AM, tim Rowledge <[hidden email]> wrote:
>
>
> Regardless of any particular design ideas to implement this, I’d just like to say.. No.
> Nononono.
> Bad design to use huge parameter lists. What next - allowing 1 billion arguments for someone that thinks each pixel in a large bitmap needs to be an argument?

This sometimes comes up in a porting project. It's not that one wants to support this its that one has to if the port is to proceed simply. Better to have a simple solution (look ma, no VM changes!!) than rewrite the daft automatic code generator that creates these monstrosities, or worse still complicate the VM (eg adding extension bytes to the method header so that all fetching of method numArgs is more complex).

_,,,^..^,,,_ (phone)

>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> Compromise, says Prof. Trefusis, is stalling between two fools
>

timrowledge

Re: Methods with more than 15 args sketch

In reply to this post by Jan Vrany

> On 16-06-2016, at 9:11 AM, Jan Vrany <[hidden email]> wrote:
>
>
>
> On Thu, Jun 16, 2016 at 4:57 PM, tim Rowledge <[hidden email]> wrote:
>>
>> Regardless of any particular design ideas to implement this, I’d just like to say.. No.
>> Nononono.
>> Bad design to use huge parameter lists. What next - allowing 1 billion arguments for someone that thinks each pixel in a large bitmap needs to be an argument?
>>
> I say...Yes.
> Yesyesyesyes.
>
> Think of generated code.

Think of better quality designs for generated code.

> Think of interop.

Think of better designs for interoperation.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
You never finish a program, you just stop working on it.

Eliot Miranda-2

Re: Methods with more than 15 args sketch

In reply to this post by Clément Béra

Hi Clément,

On Jun 16, 2016, at 1:21 AM, Clément Bera <[hidden email]> wrote:

Yeah I was wondering too, do we pass all arguments in an array or only the overflowing arguments ?

Definitely only overflowing arguments.

I don't mind implementing either solution. I would like to know what are the pros and cons. I understand that passing all arguments as an array is simpler to implement and maintain. What are the other advantages and disadvantages ?

My analysis is that handling only overflow arguments provides more graceful degradation, why?

When using this overflow scheme both the send, because of the creation of the argument vector, and argument access in the method, because arguments are indirectly accessed through the array, are slower. If all arguments are passed in the array then there is a big step down in performance from 14 to 15 arguments. But if only arguments greater than the 14th are passed in the array, fewer arguments have to be consed into the array, and arguments 1 through 14 can still be accessed directly.

But the killer is disambiguating 1 argument methods. If all arguments are passed by the array then a 1 argument method may either by a 1 argument method or a greater than 14 argument method, and that must be disambiguated, slowing down or increasing the size of the very common case of a 1 argument method. If only arguments 25 and above are sent we only have to disambiguate the uncommon case of a 15 or more argument method.

_,,,^..^,,,_ (phone)

On Thu, Jun 16, 2016 at 8:36 AM, Nicolas Cellier <[hidden email]> wrote:

For my personal use which was essentially calling FFI with more than 15 args, i used a single array for all arguments.
This was more simple, and no optimization of the first 15 was needed since most of the time the long method is just a wrapper that passes parameters thru.
I don't know if it's the case for other 3rd party code, but it would be worth inquiring...

https://github.com/nicolas-cellier-aka-nice/smallapack/wiki/SmallapackSqueak
http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-April/102183.html
http://bugs.squeak.org/view.php?id=2918

The (Old) Compiler code is at

http://www.squeaksource.com/Smallapack.html
Smallapack-Compiler.trunk-nice.6.mcz

2016-06-16 8:10 GMT+02:00 Clément Bera <[hidden email]>:

Hi everyone.

It seems that some people are struggling with the fact that methods in Pharo (and other Smalltalk on top of Cog) cannot have more than 15 arguments. Typically the problem arises while generating Smalltalk code or porting code from other Smalltalks.

I have been thinking for a while about this problem. In this mail I write a small sketch to solve it, it's something that could go to production very quickly and that requires almost only image-side changes. Eliot has already reviewed and approved the sketch, but I''d like to know if someone is strongly against that change.

The generic idea is to change the send calling convention at the bytecode level, using a temp vector to pass overflowing arguments.

The normal calling convention in the Smalltalk bytecode is as follows:

push receiver
push arg 1
push arg 2
....
push arg N
send selector

N is limited to 15 arguments due compiled method header & bytecode encoding.

In the new design, if the send has less than 15 arguments, the calling convention remains the same. Over 15 arguments, the overflowing arguments are passed in a temp vector in a similar way to the closure temp vectors.

The convention will look like that:

push receiver
push arg 1
push arg 2
....
push arg N
popIntoArray N-15 values
send selector

The compilation of a method with more than 15 arguments is then changed:
- As for temp vectors, the 15th arg array can't be become or read-only, hence the temp vector instructions can be used to access the overflowing arguments through the 15th arg.
- the compiled method header is still marked with 15 arguments

In addition one needs to change CompiledMethod to:
- allow larger frames (instead of 56 we could allow 128 or 256)
- have numArgs answering the right number of methods with many arguments. I think the number of arguments could be in the additional method state in this case as it is very uncommon.

And to change the fall-back of a couple primitives, such as:
- Object>>perform: withArgs:
- Object>>perform: withArgs:inSupedClass:
- BlockClosure>>valueWithArgs:

This design would allow methods to up to 141 arguments.

What do you guys think ?

Clément Béra

Re: Methods with more than 15 args sketch

On Thu, Jun 16, 2016 at 6:28 PM, Eliot Miranda <[hidden email]> wrote:

Hi Clément,

On Jun 16, 2016, at 1:21 AM, Clément Bera <[hidden email]> wrote:

Yeah I was wondering too, do we pass all arguments in an array or only the overflowing arguments ?

Definitely only overflowing arguments.

I don't mind implementing either solution. I would like to know what are the pros and cons. I understand that passing all arguments as an array is simpler to implement and maintain. What are the other advantages and disadvantages ?

My analysis is that handling only overflow arguments provides more graceful degradation, why?

When using this overflow scheme both the send, because of the creation of the argument vector, and argument access in the method, because arguments are indirectly accessed through the array, are slower. If all arguments are passed in the array then there is a big step down in performance from 14 to 15 arguments. But if only arguments greater than the 14th are passed in the array, fewer arguments have to be consed into the array, and arguments 1 through 14 can still be accessed directly.

But the killer is disambiguating 1 argument methods. If all arguments are passed by the array then a 1 argument method may either by a 1 argument method or a greater than 14 argument method, and that must be disambiguated, slowing down or increasing the size of the very common case of a 1 argument method. If only arguments 25 and above are sent we only have to disambiguate the uncommon case of a 15 or more argument method.

That second point convinced me.

_,,,^..^,,,_ (phone)

On Thu, Jun 16, 2016 at 8:36 AM, Nicolas Cellier <[hidden email]> wrote:

For my personal use which was essentially calling FFI with more than 15 args, i used a single array for all arguments.
This was more simple, and no optimization of the first 15 was needed since most of the time the long method is just a wrapper that passes parameters thru.
I don't know if it's the case for other 3rd party code, but it would be worth inquiring...

https://github.com/nicolas-cellier-aka-nice/smallapack/wiki/SmallapackSqueak
http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-April/102183.html
http://bugs.squeak.org/view.php?id=2918

The (Old) Compiler code is at

http://www.squeaksource.com/Smallapack.html
Smallapack-Compiler.trunk-nice.6.mcz

2016-06-16 8:10 GMT+02:00 Clément Bera <[hidden email]>:

Hi everyone.

It seems that some people are struggling with the fact that methods in Pharo (and other Smalltalk on top of Cog) cannot have more than 15 arguments. Typically the problem arises while generating Smalltalk code or porting code from other Smalltalks.

I have been thinking for a while about this problem. In this mail I write a small sketch to solve it, it's something that could go to production very quickly and that requires almost only image-side changes. Eliot has already reviewed and approved the sketch, but I''d like to know if someone is strongly against that change.

The generic idea is to change the send calling convention at the bytecode level, using a temp vector to pass overflowing arguments.

The normal calling convention in the Smalltalk bytecode is as follows:

push receiver
push arg 1
push arg 2
....
push arg N
send selector

N is limited to 15 arguments due compiled method header & bytecode encoding.

In the new design, if the send has less than 15 arguments, the calling convention remains the same. Over 15 arguments, the overflowing arguments are passed in a temp vector in a similar way to the closure temp vectors.

The convention will look like that:

push receiver
push arg 1
push arg 2
....
push arg N
popIntoArray N-15 values
send selector

The compilation of a method with more than 15 arguments is then changed:
- As for temp vectors, the 15th arg array can't be become or read-only, hence the temp vector instructions can be used to access the overflowing arguments through the 15th arg.
- the compiled method header is still marked with 15 arguments

In addition one needs to change CompiledMethod to:
- allow larger frames (instead of 56 we could allow 128 or 256)
- have numArgs answering the right number of methods with many arguments. I think the number of arguments could be in the additional method state in this case as it is very uncommon.

And to change the fall-back of a couple primitives, such as:
- Object>>perform: withArgs:
- Object>>perform: withArgs:inSupedClass:
- BlockClosure>>valueWithArgs:

This design would allow methods to up to 141 arguments.

What do you guys think ?

Tudor Girba-2

Re: Methods with more than 15 args sketch

Hi,

> On Jun 16, 2016, at 7:31 PM, Clément Bera <[hidden email]> wrote:
>
>
>
> On Thu, Jun 16, 2016 at 6:28 PM, Eliot Miranda <[hidden email]> wrote:
>
> Hi Clément,
>
> On Jun 16, 2016, at 1:21 AM, Clément Bera <[hidden email]> wrote:
>
>> Yeah I was wondering too, do we pass all arguments in an array or only the overflowing arguments ?
>
> Definitely only overflowing arguments.
>
>>
>> I don't mind implementing either solution. I would like to know what are the pros and cons. I understand that passing all arguments as an array is simpler to implement and maintain. What are the other advantages and disadvantages ?
>
> My analysis is that handling only overflow arguments provides more graceful degradation, why?
>
> When using this overflow scheme both the send, because of the creation of the argument vector, and argument access in the method, because arguments are indirectly accessed through the array, are slower. If all arguments are passed in the array then there is a big step down in performance from 14 to 15 arguments. But if only arguments greater than the 14th are passed in the array, fewer arguments have to be consed into the array, and arguments 1 through 14 can still be accessed directly.
>
> But the killer is disambiguating 1 argument methods. If all arguments are passed by the array then a 1 argument method may either by a 1 argument method or a greater than 14 argument method, and that must be disambiguated, slowing down or increasing the size of the very common case of a 1 argument method. If only arguments 25 and above are sent we only have to disambiguate the uncommon case of a 15 or more argument method.
>
> That second point convinced me.

+1

Doru

>
>
> _,,,^..^,,,_ (phone)
>
>>
>> On Thu, Jun 16, 2016 at 8:36 AM, Nicolas Cellier <[hidden email]> wrote:
>>
>> For my personal use which was essentially calling FFI with more than 15 args, i used a single array for all arguments.
>> This was more simple, and no optimization of the first 15 was needed since most of the time the long method is just a wrapper that passes parameters thru.
>> I don't know if it's the case for other 3rd party code, but it would be worth inquiring...
>>
>> https://github.com/nicolas-cellier-aka-nice/smallapack/wiki/SmallapackSqueak
>> http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-April/102183.html
>> http://bugs.squeak.org/view.php?id=2918
>>
>> The (Old) Compiler code is at
>>
>> http://www.squeaksource.com/Smallapack.html
>> Smallapack-Compiler.trunk-nice.6.mcz
>>
>>
>>
>> 2016-06-16 8:10 GMT+02:00 Clément Bera <[hidden email]>:
>>
>> Hi everyone.
>>
>> It seems that some people are struggling with the fact that methods in Pharo (and other Smalltalk on top of Cog) cannot have more than 15 arguments. Typically the problem arises while generating Smalltalk code or porting code from other Smalltalks.
>>
>> I have been thinking for a while about this problem. In this mail I write a small sketch to solve it, it's something that could go to production very quickly and that requires almost only image-side changes. Eliot has already reviewed and approved the sketch, but I''d like to know if someone is strongly against that change.
>>
>> The generic idea is to change the send calling convention at the bytecode level, using a temp vector to pass overflowing arguments.
>>
>> The normal calling convention in the Smalltalk bytecode is as follows:
>>
>> push receiver
>> push arg 1
>> push arg 2
>> ....
>> push arg N
>> send selector
>>
>> N is limited to 15 arguments due compiled method header & bytecode encoding.
>>
>> In the new design, if the send has less than 15 arguments, the calling convention remains the same. Over 15 arguments, the overflowing arguments are passed in a temp vector in a similar way to the closure temp vectors.
>>
>> The convention will look like that:
>>
>> push receiver
>> push arg 1
>> push arg 2
>> ....
>> push arg N
>> popIntoArray N-15 values
>> send selector
>>
>> The compilation of a method with more than 15 arguments is then changed:
>> - As for temp vectors, the 15th arg array can't be become or read-only, hence the temp vector instructions can be used to access the overflowing arguments through the 15th arg.
>> - the compiled method header is still marked with 15 arguments
>>
>> In addition one needs to change CompiledMethod to:
>> - allow larger frames (instead of 56 we could allow 128 or 256)
>> - have numArgs answering the right number of methods with many arguments. I think the number of arguments could be in the additional method state in this case as it is very uncommon.
>>
>> And to change the fall-back of a couple primitives, such as:
>> - Object>>perform: withArgs:
>> - Object>>perform: withArgs:inSupedClass:
>> - BlockClosure>>valueWithArgs:
>>
>> This design would allow methods to up to 141 arguments.
>>
>> What do you guys think ?
>>
>>
>>
>>
>
>

--
www.tudorgirba.com
www.feenk.com

"From an abstract enough point of view, any two things are similar."

Sean P. DeNigris

Re: Methods with more than 15 args sketch

Administrator

In reply to this post by timrowledge

tim Rowledge wrote

Nononono.
Bad design to use huge parameter lists

One of my favorite things about Smalltalk is what I understand to be a fundamental principle: to trust users with as much power as possible, not to place limits to prevent them from doing things that don't seem like a good idea like most systems.

Cheers,
Sean

Clément Béra

Re: [Pharo-dev] [Vm-dev] Methods with more than 15 args sketch

In reply to this post by Clément Béra

Hi,

I think there was a misunderstanding Tim. The idea is not necessarily to let developers write code with this many arguments, the IDE could actually enforces the programmer not to write methods with too many arguments. It's really about non programmers, like code generating tools such as SmaCC.

In Java for example, the "Clean code" code convention limits the number of arguments per method to 3, the "Code complete" code convention limits it to 7, but Java can compile methods up to 255 arguments for code generators.

If you want to limit the number of arguments the programmer can write, enforce it in the IDE according to your code convention. Please talk about the maximum number of arguments a developer can write in another thread, this is non related to the implementation discussed here.

As Jan said, there are already too many limitations in Smalltalk to write proper code generators. We've worked on those limitations already:

- the SistaV1 bytecode set will go to production in Pharo 6 (likely Squeak at some point too) and it removes an important part of the limitations (jump sizes up to 65k instructions instead of 1024, ...).

- Spur removed other limitations (methods with up to 32k literals instead of 255, behaviors with up to 65k inst vars instead of 255).

The important limitations remaining are the max frame size (56), which in practice limits the number of temps to around 55, whereas we could have 64 temps or more, and the number of arguments of methods and blocks. This scheme is about solving those problems. There are 0.5% of methods using a large frame so we could grow from 56 to 128 or 256 without any significant problems. For arguments bytecode calling convention looks so much simpler than VM support.

On Mon, Jun 20, 2016 at 8:30 AM, Marcus Denker <[hidden email]> wrote:

> On 19 Jun 2016, at 11:35, Tudor Girba <[hidden email]> wrote:
>
> Hi,
>
> Does anyone want to pick this up on the Pharo image side?
>
> I took a brief look at this and while playing I noticed that the errors when we send more than 15 arguments seem a bit strange. Take a look at this snippet:
> http://ws.stfx.eu/958BXP5GR136
> (you can paste it in Spotter to get the playground)
>
> In summary:
> - If we compile a method with a signature containing more than 15 arguments we get:
> "SyntaxErrorNotification: Too many arguments’”.
> This is good.
>
> - If we compile a method with a message send containing between 16-31 arguments we get:
> "'InMidstOfFileinNotification’”.
> Ok-ish.
>
> - If we compile a method with a message send containing more than 31 arguments we get:
> "'Error: genSend:numArgs: numArgs index 32 is out of range 0 to 31’"
> This is wrong.
>
>
> Did I misunderstand something?
>

The VM does not support it, and as nobody is using it, the error messages are not that perfect.
(to have them nicer, someone would have seen it and be bothered to fix it…)

What Clement proposes is to implement support for more than 15 arguments in the compiler.
(which means that instead of error messages, it would compile, with the idea as he described
in the mail).

Marcus

timrowledge

Re: [Pharo-dev] [Vm-dev] Methods with more than 15 args sketch

> On 20-06-2016, at 12:17 AM, Clément Bera <[hidden email]> wrote:
>
> I think there was a misunderstanding Tim. The idea is not necessarily to let developers write code with this many arguments, the IDE could actually enforces the programmer not to write methods with too many arguments. It's really about non programmers, like code generating tools such as SmaCC.

Excellent point, nicely made. You have my permission to proceed :-J

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: REP: Randomly Execute Programmers