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

[Clément Bera]

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 <marcus.denker at inria.fr>
wrote:

>
> > On 19 Jun 2016, at 11:35, Tudor Girba <tudor at tudorgirba.com> 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160620/665afdee/attachment.htm