Yes for me, just one comment: I'm a bit nervous about getting too
inspired by C++ syntax. With every new standard round it's looking
more like control character soup. Vern, I'm not sure what you had in
mind here ... but perhaps instead of something very close to C++, like
I was thinking a
Sounds like a way forward then to both address the current concern,
and improve this overall. Does this work for everybody?
Sounds good to me. I intend to add captures for `when` too, though if
that requires further discussion, perhaps whoever thinks so can start up
a sub-thread. Will now
On 12/11/20 1:47 AM, Robin Sommer wrote:
Sounds like a way forward then to both address the current concern,
and improve this overall. Does this work for everybody?
Yes for me, just one comment: I'm a bit nervous about getting too
inspired by C++ syntax. With every new standard round it's
Sounds like a way forward then to both address the current concern,
and improve this overall. Does this work for everybody?
Robin
On Thu, Dec 10, 2020 at 18:26 +, Johanna Amann wrote:
> I like this idea, including just deprecating the old syntax - that makes it
> explicit what exactly
I like this idea, including just deprecating the old syntax - that makes
it explicit what exactly happens.
Johanna
On 10 Dec 2020, at 18:06, Robin Sommer wrote:
It's interesting how different people have different intuitions on
semantics here. I also see it as consistent with function
It's interesting how different people have different intuitions on
semantics here. I also see it as consistent with function arguments,
that's why I'd be fine it. That said, I was also thinking along the
same lines of adding explicit capture specifications: deprecate the
current, capture-spec-less
There's also some weirdness with the current implementation:
Urp. Yeah, things get wonky in the current implementation when the
original outer function exits. (Your example works as expected if we
move the `zeek_init` statements into `demo`.) There’s a bunch of code
in that case to salvage
for sure on my wishlist is consideration for some deprecation-path,
differentiating-syntax (maybe event just temporary), or other
warning/notice that can help users along instead of potentially
breaking their code outright.
Good point. Seems a natural way to do this is to add C++-style []
There's also some weirdness with the current implementation:
This outputs 4 & 5 like i'd expect:
function demo(): function()
{
local i = 3;
local f = function() { ++i;print i; };
return f;
}
event zeek_init()
{
local d = demo();
d();
d();
}
but this
On 9 Dec 2020, at 22:28, Vern Paxson wrote:
I agree with Johanna that whatever is done, it would be best if it
were consistent, and not vary with the type of the captured variable.
It already varies with type of variable for assignments and function
call parameters. Thus I’m puzzled at the
On 12/9/20 2:28 PM, Vern Paxson wrote:
It already varies with type of variable for assignments and function
call parameters. Thus I’m puzzled at the desire for deep-copy over
shallow-copy, given that Zeek is already primarily shallow-copy.
Access to the variable here is so natural (in the
On Wed, Dec 9, 2020 at 2:29 PM Vern Paxson wrote:
> It already varies with type of variable for assignments and function
> call parameters. Thus I’m puzzled at the desire for deep-copy over
> shallow-copy, given that Zeek is already primarily shallow-copy.
Same for me: wondering what's
I agree with Johanna that whatever is done, it would be best if it
were consistent, and not vary with the type of the captured variable.
It already varies with type of variable for assignments and function
call parameters. Thus I’m puzzled at the desire for deep-copy over
shallow-copy, given
I agree with Johanna that whatever is done, it would be best if it were
consistent, and not vary with the type of the captured variable.
IIRC, in the ‘70s, it was up to FORTRAN compiler writers whether arguments
passed to procedures and functions were passed by value or by reference, and
some
My proposal is to change the semantics to instead be shallow-copying,
which means that atomic values are copied, but aggregate values
(tables, records, and vectors) are shared. With this change, the
above code would print `3`. However, this code would still print `5`:
I for one don’t
On 12/9/20 11:10 AM, Vern Paxson wrote:
For the script optimization/compilation work I’ve been doing, I’ve
been looking into what it will take to compile lambdas (anonymous
functions).
I think the current functionality would be better, since it's how I'd
expect it to behave (which probably
16 matches
Mail list logo
