Variable names / inline JS: proposals of stricter method syntax

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Variable names / inline JS: proposals of stricter method syntax

Herby Vojčík
Hi, I'd like to propose two alternatives to inline JS and variable
naming (they are not entirely unrelated):

Proposal 1.
  - Let inline JS statement occur only in context of Smalltalk
statements (as a member of "method statement sequence" or "block
statement sequence"). In particular, it should be not allowed inside
expressions, and
  - let names of variables (args, temps, block args, block temps,
unknowns/globals) be unique over the whole text of the method (none of
them can produce name clash)

This goes with GH-18 issue and can help solve GH-191 issue as well.
Plus, it helps making more optimized inlining in compiler.

Proposal 2.
  - Let inline JS statement occur only in context of Smalltalk statement
in a main method code (as a member of "method staement sequence"). In
particular, it should not be allowed inside blocks not expressions, and
  - deny names of global/unknown variables which conflict with
"smalltalk" variables (args, temps, block args, block temps).

This may also help in the same issues, though a bit differently.

Is one of these acceptable for amber?

Herby
Reply | Threaded
Open this post in threaded view
|

Re: Variable names / inline JS: proposals of stricter method syntax

Nicolas Petton
I fully agree :) A few changes in the parser and compiler should do the trick.

Nico

2012/5/9 Herby Vojčík <[hidden email]>
Hi, I'd like to propose two alternatives to inline JS and variable naming (they are not entirely unrelated):

Proposal 1.
 - Let inline JS statement occur only in context of Smalltalk statements (as a member of "method statement sequence" or "block statement sequence"). In particular, it should be not allowed inside expressions, and
 - let names of variables (args, temps, block args, block temps, unknowns/globals) be unique over the whole text of the method (none of them can produce name clash)

This goes with GH-18 issue and can help solve GH-191 issue as well. Plus, it helps making more optimized inlining in compiler.

Proposal 2.
 - Let inline JS statement occur only in context of Smalltalk statement in a main method code (as a member of "method staement sequence"). In particular, it should not be allowed inside blocks not expressions, and
 - deny names of global/unknown variables which conflict with "smalltalk" variables (args, temps, block args, block temps).

This may also help in the same issues, though a bit differently.

Is one of these acceptable for amber?

Herby

Reply | Threaded
Open this post in threaded view
|

Re: Variable names / inline JS: proposals of stricter method syntax

Herby Vojčík


nicolas petton wrote:
> I fully agree :) A few changes in the parser and compiler should do the
> trick.

Which one? I like the first, it's cleaner.

Herby

> Nico
>
> 2012/5/9 Herby Vojčík <[hidden email] <mailto:[hidden email]>>
>
>     Hi, I'd like to propose two alternatives to inline JS and variable
>     naming (they are not entirely unrelated):
>
>     Proposal 1.
>       - Let inline JS statement occur only in context of Smalltalk
>     statements (as a member of "method statement sequence" or "block
>     statement sequence"). In particular, it should be not allowed inside
>     expressions, and
>       - let names of variables (args, temps, block args, block temps,
>     unknowns/globals) be unique over the whole text of the method (none
>     of them can produce name clash)
>
>     This goes with GH-18 issue and can help solve GH-191 issue as well.
>     Plus, it helps making more optimized inlining in compiler.
>
>     Proposal 2.
>       - Let inline JS statement occur only in context of Smalltalk
>     statement in a main method code (as a member of "method staement
>     sequence"). In particular, it should not be allowed inside blocks
>     not expressions, and
>       - deny names of global/unknown variables which conflict with
>     "smalltalk" variables (args, temps, block args, block temps).
>
>     This may also help in the same issues, though a bit differently.
>
>     Is one of these acceptable for amber?
>
>     Herby
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Variable names / inline JS: proposals of stricter method syntax

Nicolas Petton
Yeah, I meant the first one. Now what do you mean by unique over the whole text of the method?

Nico

2012/5/10 Herby Vojčík <[hidden email]>


nicolas petton wrote:
I fully agree :) A few changes in the parser and compiler should do the
trick.

Which one? I like the first, it's cleaner.

Herby

Nico

2012/5/9 Herby Vojčík <[hidden email] <mailto:[hidden email]>>


   Hi, I'd like to propose two alternatives to inline JS and variable
   naming (they are not entirely unrelated):

   Proposal 1.
     - Let inline JS statement occur only in context of Smalltalk
   statements (as a member of "method statement sequence" or "block
   statement sequence"). In particular, it should be not allowed inside
   expressions, and
     - let names of variables (args, temps, block args, block temps,
   unknowns/globals) be unique over the whole text of the method (none
   of them can produce name clash)

   This goes with GH-18 issue and can help solve GH-191 issue as well.
   Plus, it helps making more optimized inlining in compiler.

   Proposal 2.
     - Let inline JS statement occur only in context of Smalltalk
   statement in a main method code (as a member of "method staement
   sequence"). In particular, it should not be allowed inside blocks
   not expressions, and
     - deny names of global/unknown variables which conflict with
   "smalltalk" variables (args, temps, block args, block temps).

   This may also help in the same issues, though a bit differently.

   Is one of these acceptable for amber?

   Herby



Reply | Threaded
Open this post in threaded view
|

Re: Variable names / inline JS: proposals of stricter method syntax

Herby Vojčík


nicolas petton wrote:
> Yeah, I meant the first one. Now what do you mean by unique over the
> whole text of the method?

Just the "does not clash with any other type of the variable having the
same name (including unknowns)".

Herby

>
> Nico
>
> 2012/5/10 Herby Vojčík <[hidden email] <mailto:[hidden email]>>
>
>
>
>     nicolas petton wrote:
>
>         I fully agree :) A few changes in the parser and compiler should
>         do the
>         trick.
>
>
>     Which one? I like the first, it's cleaner.
>
>     Herby
>
>         Nico
>
>         2012/5/9 Herby Vojčík <[hidden email]
>         <mailto:[hidden email]> <mailto:[hidden email]
>         <mailto:[hidden email]>>>
>
>
>             Hi, I'd like to propose two alternatives to inline JS and
>         variable
>             naming (they are not entirely unrelated):
>
>             Proposal 1.
>               - Let inline JS statement occur only in context of Smalltalk
>             statements (as a member of "method statement sequence" or "block
>             statement sequence"). In particular, it should be not
>         allowed inside
>             expressions, and
>               - let names of variables (args, temps, block args, block
>         temps,
>             unknowns/globals) be unique over the whole text of the
>         method (none
>             of them can produce name clash)
>
>             This goes with GH-18 issue and can help solve GH-191 issue
>         as well.
>             Plus, it helps making more optimized inlining in compiler.
>
>             Proposal 2.
>               - Let inline JS statement occur only in context of Smalltalk
>             statement in a main method code (as a member of "method staement
>             sequence"). In particular, it should not be allowed inside
>         blocks
>             not expressions, and
>               - deny names of global/unknown variables which conflict with
>         "smalltalk" variables (args, temps, block args, block temps).
>
>             This may also help in the same issues, though a bit differently.
>
>             Is one of these acceptable for amber?
>
>             Herby
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Variable names / inline JS: proposals of stricter method syntax

Nicolas Petton
Yeah, what could be good is to:

- rename all temps/args to $n
- keep track of the temps/arg names in the CompiledMethod metadata

Nico

2012/5/11 Herby Vojčík <[hidden email]>


nicolas petton wrote:
Yeah, I meant the first one. Now what do you mean by unique over the
whole text of the method?

Just the "does not clash with any other type of the variable having the same name (including unknowns)".

Herby


Nico

2012/5/10 Herby Vojčík <[hidden email] <mailto:[hidden email]>>




   nicolas petton wrote:

       I fully agree :) A few changes in the parser and compiler should
       do the
       trick.


   Which one? I like the first, it's cleaner.

   Herby

       Nico

       2012/5/9 Herby Vojčík <[hidden email]
       <mailto:[hidden email]> <mailto:[hidden email]

       <mailto:[hidden email]>>>


           Hi, I'd like to propose two alternatives to inline JS and
       variable
           naming (they are not entirely unrelated):

           Proposal 1.
             - Let inline JS statement occur only in context of Smalltalk
           statements (as a member of "method statement sequence" or "block
           statement sequence"). In particular, it should be not
       allowed inside
           expressions, and
             - let names of variables (args, temps, block args, block
       temps,
           unknowns/globals) be unique over the whole text of the
       method (none
           of them can produce name clash)

           This goes with GH-18 issue and can help solve GH-191 issue
       as well.
           Plus, it helps making more optimized inlining in compiler.

           Proposal 2.
             - Let inline JS statement occur only in context of Smalltalk
           statement in a main method code (as a member of "method staement
           sequence"). In particular, it should not be allowed inside
       blocks
           not expressions, and
             - deny names of global/unknown variables which conflict with
       "smalltalk" variables (args, temps, block args, block temps).

           This may also help in the same issues, though a bit differently.

           Is one of these acceptable for amber?

           Herby




Reply | Threaded
Open this post in threaded view
|

Re: Variable names / inline JS: proposals of stricter method syntax

Herby Vojčík
nicolas petton wrote:
> Yeah, what could be good is to:
>
> - rename all temps/args to $n
You can't do this in method - inline JS needs original names for
interoperability. It is possible in block - but I use $n (where
n=0,1,...) in ImpCodeGenerator for other purposes... to retain
redability of compiled method, I'd rename them so that they retain their
name, like rename all of them for single block to $noriginalName, where
n is common for that block. Or something like that.

> - keep track of the temps/arg names in the CompiledMethod metadata
Maybe. I have no opinion here.

> Nico

Herby

> 2012/5/11 Herby Vojčík <[hidden email] <mailto:[hidden email]>>
>
>
>
>     nicolas petton wrote:
>
>         Yeah, I meant the first one. Now what do you mean by unique over the
>         whole text of the method?
>
>
>     Just the "does not clash with any other type of the variable having
>     the same name (including unknowns)".
>
>     Herby
>
>
>         Nico