Smalltalk › Amber Smalltalk

Unknown variables

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

5 messages Options

Herby Vojčík

Unknown variables

Hello,

I see unknown variable as a bit of a problem (unknown variables are
console and z and partially also Capitalized and Array from this code:
foo: x
|y|
y:=42.
console log: (z:=x+y).
^Capitalized with: Array new
).

This produces roughly:
function foo(x) {var y=nil;
y=42;
send((console == null ? nil : console), "_log_", [z=x+y]);
return (send((smalltalk.Capitalized || Capitalized), "_with_",
[send((smalltalk.Array || Array), "_new", [])]);
}

You see console and z are used as-is (sanitized when used as a
receiver), capitalized ones are used primarily as smalltalk classes but
allow fallback (BTW, not sanitized).

I'd propose ban unknown variables and require explicit importing them
into method, by simple (ab)use of <inlineJs> facility:

foo:x
|y|
<console;z;Capitalized>

y:=42.
console log: (z:=x+y).
^Capitalized with: Array new

which would produce:

function(x) {var y=nil;
// will use console, z and Capitalized as globals
// rest is error when camelCase and class in PascalCase
// the code _can_ in fact be generated, it needs to be no special:
;{console;z;Capitalized}
y=42;
send((console == null ? nil : console), "_log_", [z=x+y]);
return (Capitalized == null ? nil : Capitalized), "_with_",
[send(smalltalk.Array, "_new", [])]);
}

That is, if code inside <> contains _only_ list of identifiers separated
by semicolon, it hints the compiler which variables from outer world to
use (and reject others).

The question is, would amber users be willing to adopt this restriction
(and also, do you see it as good thing at all (I see))?

Herby

Herby Vojčík

Re: Unknown variables

Herby Vojčík wrote:

> which would produce:
>
> function(x) {var y=nil;
> // will use console, z and Capitalized as globals
> // rest is error when camelCase and class in PascalCase
> // the code _can_ in fact be generated, it needs to be no special:
> ;{console;z;Capitalized}
> y=42;
> send((console == null ? nil : console), "_log_", [z=x+y]);
> return (Capitalized == null ? nil : Capitalized), "_with_",

I missed the "send" after return
> [send(smalltalk.Array, "_new", [])]);
> }

Nicolas Petton

Re: Unknown variables

In reply to this post by Herby Vojčík

Herby Vojčík <[hidden email]> writes:

Hi!

IMHO it's fine the way it is, as it allows you to seemlessly send
messages to JavaScript objects without any additional effort.

I very much like the fact that you can do `console log: hello` or even
`window document inspect`. It just works.

Now, what do others think about it?

BTW, the IDE will warn you about unknown variables.

Cheers,
Nico

> Hello,
>
> I see unknown variable as a bit of a problem (unknown variables are
> console and z and partially also Capitalized and Array from this code:
> foo: x
> |y|
> y:=42.
> console log: (z:=x+y).
> ^Capitalized with: Array new
> ).
>
> This produces roughly:
> function foo(x) {var y=nil;
> y=42;
> send((console == null ? nil : console), "_log_", [z=x+y]);
> return (send((smalltalk.Capitalized || Capitalized), "_with_",
> [send((smalltalk.Array || Array), "_new", [])]);
> }
>
> You see console and z are used as-is (sanitized when used as a
> receiver), capitalized ones are used primarily as smalltalk classes
> but allow fallback (BTW, not sanitized).
>
> I'd propose ban unknown variables and require explicit importing them
> into method, by simple (ab)use of <inlineJs> facility:
>
> foo:x
> |y|
> <console;z;Capitalized>
>
> y:=42.
> console log: (z:=x+y).
> ^Capitalized with: Array new
>
> which would produce:
>
> function(x) {var y=nil;
> // will use console, z and Capitalized as globals
> // rest is error when camelCase and class in PascalCase
> // the code _can_ in fact be generated, it needs to be no special:
> ;{console;z;Capitalized}
> y=42;
> send((console == null ? nil : console), "_log_", [z=x+y]);
> return (Capitalized == null ? nil : Capitalized), "_with_",
> [send(smalltalk.Array, "_new", [])]);
> }
>
> That is, if code inside <> contains _only_ list of identifiers
> separated by semicolon, it hints the compiler which variables from
> outer world to use (and reject others).
>
> The question is, would amber users be willing to adopt this
> restriction (and also, do you see it as good thing at all (I see))?
>
> Herby

Andrew McQuiggin

Re: Unknown variables

I do like how it works currently.

But it took me some time to discover what is possible and the correct usage. For example, the need to use local rather than instance variables when passing parameters from Smalltalk to Javascript. Examples on the wiki would make it easier to pick up.

To try it out for myself I built a simple example of manipulating the Simile Timeline. It was easy (and fun), once I understood the usage.

Andrew

On May 3, 2012 4:57 PM, "Nicolas Petton" <[hidden email]> wrote:

Herby Vojčík <[hidden email]> writes:

Hi!

IMHO it's fine the way it is, as it allows you to seemlessly send
messages to JavaScript objects without any additional effort.

I very much like the fact that you can do `console log: hello` or even
`window document inspect`. It just works.

Now, what do others think about it?

BTW, the IDE will warn you about unknown variables.

Cheers,
Nico

> Hello,
>
> I see unknown variable as a bit of a problem (unknown variables are
> console and z and partially also Capitalized and Array from this code:
> foo: x
> |y|
> y:=42.
> console log: (z:=x+y).
> ^Capitalized with: Array new
> ).
>
> This produces roughly:
> function foo(x) {var y=nil;
> y=42;
> send((console == null ? nil : console), "_log_", [z=x+y]);
> return (send((smalltalk.Capitalized || Capitalized), "_with_",
> [send((smalltalk.Array || Array), "_new", [])]);
> }
>
> You see console and z are used as-is (sanitized when used as a
> receiver), capitalized ones are used primarily as smalltalk classes
> but allow fallback (BTW, not sanitized).
>
> I'd propose ban unknown variables and require explicit importing them
> into method, by simple (ab)use of <inlineJs> facility:
>
> foo:x
> |y|
> <console;z;Capitalized>
>
> y:=42.
> console log: (z:=x+y).
> ^Capitalized with: Array new
>
> which would produce:
>
> function(x) {var y=nil;
> // will use console, z and Capitalized as globals
> // rest is error when camelCase and class in PascalCase
> // the code _can_ in fact be generated, it needs to be no special:
> ;{console;z;Capitalized}
> y=42;
> send((console == null ? nil : console), "_log_", [z=x+y]);
> return (Capitalized == null ? nil : Capitalized), "_with_",
> [send(smalltalk.Array, "_new", [])]);
> }
>
> That is, if code inside <> contains _only_ list of identifiers
> separated by semicolon, it hints the compiler which variables from
> outer world to use (and reject others).
>
> The question is, would amber users be willing to adopt this
> restriction (and also, do you see it as good thing at all (I see))?
>
> Herby

Herby Vojčík

Re: Unknown variables

Andrew McQuiggin wrote:
> I do like how it works currently.
>
> But it took me some time to discover what is possible and the correct
> usage. For example, the need to use local rather than instance variables
> when passing parameters from Smalltalk to Javascript. Examples on the
> wiki would make it easier to pick up.

This is dangerous. This in other words says "I learned to use inline JS
in such a way that it is tighly coupled with existing way of how
Compiler produces code". It is, more or less, like using unpublished
API. If it is gets spread, the implementation details needs to be
defined as the part of the language (and fixes the implementation of
that particular part in the certain state).

What are the rules for "well-behaved JS" to interact ST and vice-versa?
I don't think it should be "use any implementation detail you find useful".

> To try it out for myself I built a simple example of manipulating the
> Simile Timeline. It was easy (and fun), once I understood the usage.
>
> Andrew
>
> On May 3, 2012 4:57 PM, "Nicolas Petton" <[hidden email]
> <mailto:[hidden email]>> wrote:
>
> Herby Vojčík <[hidden email] <mailto:[hidden email]>> writes:
>
> Hi!
>
> IMHO it's fine the way it is, as it allows you to seemlessly send
> messages to JavaScript objects without any additional effort.
>
> I very much like the fact that you can do `console log: hello` or even
> `window document inspect`. It just works.
>
> Now, what do others think about it?
>
>
> BTW, the IDE will warn you about unknown variables.
>
> Cheers,
> Nico
>
> > Hello,
> >
> > I see unknown variable as a bit of a problem (unknown variables are
> > console and z and partially also Capitalized and Array from this
> code:
> > foo: x
> > |y|
> > y:=42.
> > console log: (z:=x+y).
> > ^Capitalized with: Array new
> > ).
> >
> > This produces roughly:
> > function foo(x) {var y=nil;
> > y=42;
> > send((console == null ? nil : console), "_log_", [z=x+y]);
> > return (send((smalltalk.Capitalized || Capitalized), "_with_",
> > [send((smalltalk.Array || Array), "_new", [])]);
> > }
> >
> > You see console and z are used as-is (sanitized when used as a
> > receiver), capitalized ones are used primarily as smalltalk classes
> > but allow fallback (BTW, not sanitized).
> >
> > I'd propose ban unknown variables and require explicit importing them
> > into method, by simple (ab)use of <inlineJs> facility:
> >
> > foo:x
> > |y|
> > <console;z;Capitalized>
> >
> > y:=42.
> > console log: (z:=x+y).
> > ^Capitalized with: Array new
> >
> > which would produce:
> >
> > function(x) {var y=nil;
> > // will use console, z and Capitalized as globals
> > // rest is error when camelCase and class in PascalCase
> > // the code _can_ in fact be generated, it needs to be no special:
> > ;{console;z;Capitalized}
> > y=42;
> > send((console == null ? nil : console), "_log_", [z=x+y]);
> > return (Capitalized == null ? nil : Capitalized), "_with_",
> > [send(smalltalk.Array, "_new", [])]);
> > }
> >
> > That is, if code inside <> contains _only_ list of identifiers
> > separated by semicolon, it hints the compiler which variables from
> > outer world to use (and reject others).
> >
> > The question is, would amber users be willing to adopt this
> > restriction (and also, do you see it as good thing at all (I see))?
> >
> > Herby
>