Named Paramters

classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Named Paramters

Soni L.
Could add f{} as sugar for f({}), and make engines optimize f{}? (no positional arguments though)

On 31/07/15 12:00 PM, Michał Wadas wrote:
Proposal that do not conflict with minimifiers:

- Functions have optional named parameters in any place of argument
definition. Optionality is defined by presence of hash character at
beginning of parameter name. Optional parameters CAN be placed after
rest parameter. These parameters can be accessed by name or by
position:

```
function foo(bar, #qaz, boo) {
return [bar, qaz, boo];
}
foo(1,2,3); // [1,2,3]
foo(#qaz: 3, 4, 1); // [4,3,1] or [4,1,undefined] or throw?

function faz(bar, ...baz, #qoo) {
return [bar, ...baz, qoo];
}
faz(1,2,3,4,#qoo:5); // [1,2,3,4,5]

function print(...toPrint, #delimiter=',', newLine='\n') {
console.log(toPrint.join(delimiter)+newLine);
}
let delimiter = ':';
print(1, 2, 3, 4, 5,#{delimiter}); // prints '1:2:3:4:5\n'

```

Possible solutions for nonexistant optional argument (eg. foo(#nope:null) ):
- throw (probably the worst solution )
- define `arguments[Symbol.optionals]` object (great for passing
optional arguments)
- allow syntax for "rest optional parameters"
- ignore

Some problems:
- probably this syntax can not be transpiled in general case
- there is no intuitive behavior for ` print (1,2, #delimiter:' ',
#{delimiter})`
- how will `.apply` work? Third argument with optional arguments?
`Symbol.optionals`  property on second argument (good for
seaminglessly passing `arguments`, but it doesn't sound like good idea
for arrays)?.
-

Any thoughts?
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

-- 
Disclaimer: these emails are public and can be accessed from <TODO: get a non-DHCP IP and put it here>. If you do not agree with this, DO NOT REPLY.

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
joe
Reply | Threaded
Open this post in threaded view
|

Re: Named Paramters

joe
In principle, I agree with Bucara re: the ({}) syntax.  Unfortunately this is often too slow to use in practice.  Everyone keeps hoping browser vendors will come up with a way to optimize out small object allocations, but I think that's a pipe dream, because we do have a language that handles fine-grained allocation well: Python.

Python combines reference counting with a cyclic garbage collector.  This allows it to amortize the GC cost; most objects (especially small use cases like this one) are destroyed by reference counting.  There is, however, a downside: speed.  In the case of JS, if one is careful, makes use of object caches and thus manually controls his memory use, one can virtually eliminate the overhead from traditional collectors.  One cannot avoid the overhead from reference counting in Python, however.

Collecting many small, heap-allocated objects is just a hard problem to solve, and will always have costs.  In the end, I think we will have to find some way for garbage-collected languages to accommodate some sort of stack allocation.  There are languages that experiment with them (one of my old college professors wrote a really cool one), but the idea is still relatively undeveloped. 

Joe

On Fri, Jul 31, 2015 at 8:31 AM, Soni L. <[hidden email]> wrote:
Could add f{} as sugar for f({}), and make engines optimize f{}? (no positional arguments though)

On 31/07/15 12:00 PM, Michał Wadas wrote:
Proposal that do not conflict with minimifiers:

- Functions have optional named parameters in any place of argument
definition. Optionality is defined by presence of hash character at
beginning of parameter name. Optional parameters CAN be placed after
rest parameter. These parameters can be accessed by name or by
position:

```
function foo(bar, #qaz, boo) {
return [bar, qaz, boo];
}
foo(1,2,3); // [1,2,3]
foo(#qaz: 3, 4, 1); // [4,3,1] or [4,1,undefined] or throw?

function faz(bar, ...baz, #qoo) {
return [bar, ...baz, qoo];
}
faz(1,2,3,4,#qoo:5); // [1,2,3,4,5]

function print(...toPrint, #delimiter=',', newLine='\n') {
console.log(toPrint.join(delimiter)+newLine);
}
let delimiter = ':';
print(1, 2, 3, 4, 5,#{delimiter}); // prints '1:2:3:4:5\n'

```

Possible solutions for nonexistant optional argument (eg. foo(#nope:null) ):
- throw (probably the worst solution )
- define `arguments[Symbol.optionals]` object (great for passing
optional arguments)
- allow syntax for "rest optional parameters"
- ignore

Some problems:
- probably this syntax can not be transpiled in general case
- there is no intuitive behavior for ` print (1,2, #delimiter:' ',
#{delimiter})`
- how will `.apply` work? Third argument with optional arguments?
`Symbol.optionals`  property on second argument (good for
seaminglessly passing `arguments`, but it doesn't sound like good idea
for arrays)?.
-

Any thoughts?
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

-- 
Disclaimer: these emails are public and can be accessed from <TODO: get a non-DHCP IP and put it here>. If you do not agree with this, DO NOT REPLY.

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Named Paramters

Soni L.
Engines could inline and infer lifetimes, use stack allocation when possible, etc. Kinda like how LuaJIT is so fast.

Just because they don't yet doesn't mean we should hold back features which would work better if they did.

Plus, you don't /need/ to use "garbage collectible objects" for it. In theory (and in practice) your internal bytecode could have something like this:

function f(x) { return x.y; }

FUNCTION "f"
ARG "x" NOGC ; = basically doesn't have to be a "GC object"
RET x.y

f({y=3})

SET (temp1) {y=3} NOGC
CALL "f" (temp1)
FREE (temp1)

You know f takes a NOGC argument, you can create a NOGC object. You could even inline both the call and the object access, actually.

On 31/07/15 01:48 PM, joe wrote:
In principle, I agree with Bucara re: the ({}) syntax.  Unfortunately this is often too slow to use in practice.  Everyone keeps hoping browser vendors will come up with a way to optimize out small object allocations, but I think that's a pipe dream, because we do have a language that handles fine-grained allocation well: Python.

Python combines reference counting with a cyclic garbage collector.  This allows it to amortize the GC cost; most objects (especially small use cases like this one) are destroyed by reference counting.  There is, however, a downside: speed.  In the case of JS, if one is careful, makes use of object caches and thus manually controls his memory use, one can virtually eliminate the overhead from traditional collectors.  One cannot avoid the overhead from reference counting in Python, however.

Collecting many small, heap-allocated objects is just a hard problem to solve, and will always have costs.  In the end, I think we will have to find some way for garbage-collected languages to accommodate some sort of stack allocation.  There are languages that experiment with them (one of my old college professors wrote a really cool one), but the idea is still relatively undeveloped. 

Joe

On Fri, Jul 31, 2015 at 8:31 AM, Soni L. <[hidden email]> wrote:
Could add f{} as sugar for f({}), and make engines optimize f{}? (no positional arguments though)

On 31/07/15 12:00 PM, Michał Wadas wrote:
Proposal that do not conflict with minimifiers:

- Functions have optional named parameters in any place of argument
definition. Optionality is defined by presence of hash character at
beginning of parameter name. Optional parameters CAN be placed after
rest parameter. These parameters can be accessed by name or by
position:

```
function foo(bar, #qaz, boo) {
return [bar, qaz, boo];
}
foo(1,2,3); // [1,2,3]
foo(#qaz: 3, 4, 1); // [4,3,1] or [4,1,undefined] or throw?

function faz(bar, ...baz, #qoo) {
return [bar, ...baz, qoo];
}
faz(1,2,3,4,#qoo:5); // [1,2,3,4,5]

function print(...toPrint, #delimiter=',', newLine='\n') {
console.log(toPrint.join(delimiter)+newLine);
}
let delimiter = ':';
print(1, 2, 3, 4, 5,#{delimiter}); // prints '1:2:3:4:5\n'

```

Possible solutions for nonexistant optional argument (eg. foo(#nope:null) ):
- throw (probably the worst solution )
- define `arguments[Symbol.optionals]` object (great for passing
optional arguments)
- allow syntax for "rest optional parameters"
- ignore

Some problems:
- probably this syntax can not be transpiled in general case
- there is no intuitive behavior for ` print (1,2, #delimiter:' ',
#{delimiter})`
- how will `.apply` work? Third argument with optional arguments?
`Symbol.optionals`  property on second argument (good for
seaminglessly passing `arguments`, but it doesn't sound like good idea
for arrays)?.
-

Any thoughts?
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

-- 
Disclaimer: these emails are public and can be accessed from <TODO: get a non-DHCP IP and put it here>. If you do not agree with this, DO NOT REPLY.

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



-- 
Disclaimer: these emails are public and can be accessed from <TODO: get a non-DHCP IP and put it here>. If you do not agree with this, DO NOT REPLY.

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
12