declare eval() and .eval() to be macro-like, make all-caps #50

Closed
pmichaud opened this Issue Jun 7, 2013 · 12 comments

Comments

Projects
None yet
9 participants
@pmichaud
Member

pmichaud commented Jun 7, 2013

At the YAPC::NA 2013 hackathon, there was discussion of making Cool.eval and eval(...) act more like macros, so they can be detected at compile time and pessimized appropriately.

It was also suggested that they become all-caps ( EVAL and .EVAL), since like MONKEY_TYPING they represent operations that are "special" and perhaps denote extra attention from programmers due to their side effects (some perhaps unwanted, such as security vulnerabilities).

Pm

@cedric-vincent

This comment has been minimized.

Show comment
Hide comment
@cedric-vincent

cedric-vincent Jun 7, 2013

Member

+1 for EVAL in all-caps, since it is really SPECIAL ;)

Member

cedric-vincent commented Jun 7, 2013

+1 for EVAL in all-caps, since it is really SPECIAL ;)

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Jun 7, 2013

+1 for yelling, and maybe it could be dehuffmanised a bit: "EVALUATE". Or is that going too far?

ghost commented Jun 7, 2013

+1 for yelling, and maybe it could be dehuffmanised a bit: "EVALUATE". Or is that going too far?

@perlpilot

This comment has been minimized.

Show comment
Hide comment
@perlpilot

perlpilot Jun 7, 2013

Member

+1 for shouting

Member

perlpilot commented Jun 7, 2013

+1 for shouting

@jnthn

This comment has been minimized.

Show comment
Hide comment
@jnthn

jnthn Jun 7, 2013

Member

I'm not so fond of the uppercasing, but certainly of the macro-ish definition, so we can analyze stuff much better.

Member

jnthn commented Jun 7, 2013

I'm not so fond of the uppercasing, but certainly of the macro-ish definition, so we can analyze stuff much better.

@pmichaud

This comment has been minimized.

Show comment
Hide comment
@pmichaud

pmichaud Jun 7, 2013

Member

Another related possibility is to require that any outer-scoped variables that are to be accessible from an eval (or feed?) have to be explicitly declared with an is eval trait or something like that.

my $a is eval;
my $b;

eval('say $a + 1'); # ok
eval('say $b + 1'); # not ok, $b not declared available

Pm

Member

pmichaud commented Jun 7, 2013

Another related possibility is to require that any outer-scoped variables that are to be accessible from an eval (or feed?) have to be explicitly declared with an is eval trait or something like that.

my $a is eval;
my $b;

eval('say $a + 1'); # ok
eval('say $b + 1'); # not ok, $b not declared available

Pm

@grondilu

This comment has been minimized.

Show comment
Hide comment
@grondilu

grondilu Jun 7, 2013

Contributor

Shouting for this seems a bit weird. Why not keep the current
non-macroish version in lowercase and add an uppercase macro-ish
version?

Contributor

grondilu commented Jun 7, 2013

Shouting for this seems a bit weird. Why not keep the current
non-macroish version in lowercase and add an uppercase macro-ish
version?

@leto

This comment has been minimized.

Show comment
Hide comment
@leto

leto Jun 8, 2013

Member

+1 to making it clear to developers that "eval" is special and care should be taken when using it.

Also, I suggest looking at Eval::Clean and emulating the feature set that it has:

https://github.com/rafl/eval-clean

/cc @rafl

Member

leto commented Jun 8, 2013

+1 to making it clear to developers that "eval" is special and care should be taken when using it.

Also, I suggest looking at Eval::Clean and emulating the feature set that it has:

https://github.com/rafl/eval-clean

/cc @rafl

@pmichaud

This comment has been minimized.

Show comment
Hide comment
@pmichaud

pmichaud Jun 9, 2013

Member

On Fri, Jun 07, 2013 at 03:56:43PM -0700, grondilu wrote:

Shouting for this seems a bit weird. Why not keep the current
non-macroish version in lowercase and add an uppercase macro-ish
version?

...but the whole point is to eliminate the non-macroish version of eval.
A purely runtime eval significantly restricts the types of compile-time
optimizations that can be performed.

I simply added that in the process of making eval() macro-like, it
might also be worthwhile to make it all-caps.

Pm

Member

pmichaud commented Jun 9, 2013

On Fri, Jun 07, 2013 at 03:56:43PM -0700, grondilu wrote:

Shouting for this seems a bit weird. Why not keep the current
non-macroish version in lowercase and add an uppercase macro-ish
version?

...but the whole point is to eliminate the non-macroish version of eval.
A purely runtime eval significantly restricts the types of compile-time
optimizations that can be performed.

I simply added that in the process of making eval() macro-like, it
might also be worthwhile to make it all-caps.

Pm

@diakopter

This comment has been minimized.

Show comment
Hide comment
@diakopter

diakopter Sep 19, 2013

Member

EVAL(+1) also..

Member

diakopter commented Sep 19, 2013

EVAL(+1) also..

@diakopter

This comment has been minimized.

Show comment
Hide comment
@diakopter

diakopter Sep 19, 2013

Member

<< bump >>

Member

diakopter commented Sep 19, 2013

<< bump >>

@mathw

This comment has been minimized.

Show comment
Hide comment
@mathw

mathw Sep 19, 2013

eval is very special, so having it in all-caps would be consistent with some other special things. Heck, even the metaclass stuff is in uppercase - .WHAT, .HOW etc. EVAL definitely fits for me into the 'strange stuff happening here' category of operations, alongside BEGIN, INIT, CATCH and so forth.

mathw commented Sep 19, 2013

eval is very special, so having it in all-caps would be consistent with some other special things. Heck, even the metaclass stuff is in uppercase - .WHAT, .HOW etc. EVAL definitely fits for me into the 'strange stuff happening here' category of operations, alongside BEGIN, INIT, CATCH and so forth.

@supernovus

This comment has been minimized.

Show comment
Hide comment
@supernovus

supernovus Sep 30, 2013

Member

+1 to EVAL

Member

supernovus commented Sep 30, 2013

+1 to EVAL

@TimToady TimToady closed this in 0b7df09 Dec 29, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment