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. <fakedme+es at gmail.com 
> <mailto:fakedme+es at gmail.com>> 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
>>     es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
>>     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
>     es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
>     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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150731/11ec08d3/attachment.html>