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. <[email protected]
<mailto:[email protected]>> 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
[email protected] <mailto:[email protected]>
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
[email protected] <mailto:[email protected]>
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
[email protected]
https://mail.mozilla.org/listinfo/es-discuss