Re: Proposed feature: die on compile with undefined functions

>
> I don't really understand how this relates to his proposal... he wanted
> a flag to assert that un-qualified functions like "max(...)" were
> defined in scope at compile time, which would include lexical subs in
> addition to current-package subs.  I also suspect the goal was to not
> need to bulk up the code with defensive constructs, and just get to use
> the language like normal with an extra layer of strictness.
>
> Sub::StrictDecl can do it, so the only question is whether it can be
> done better (allowing subs in the same file to be used out-of-order) and
> whether it could/should be available as a core feature.
>

Because it's easy to die if you have a way of forcing the resolution to
compile time and knowing that runtime resolution isn't desired. And we
already have such functionality.

❯ perl -E'use warnings FATAL => "all"; say Foo::; say 42'
Bareword "Foo::" refers to nonexistent package at -e line 1.

That dies if the package doesn't exist at compile time. Moveover,
"Foo::bar" will check that the *symbol* bar is defined.

❯ perl -E'use strict; use warnings FATAL => "all"; Foo::bar; say 42';
Bareword "Foo::bar" not allowed while "strict subs" in use at -e line 1.
Execution of -e aborted due to compilation errors.

So we already have the ability to test for nonexistent packages missing
symbols. And we do this, or something like that, for constant folding.

❯ perl -E"package Foo; use strict; use warnings; use constant BAR => 42;
package main; say 5; say Foo::BAR()"

You can see in the above we have constant folding across packages. Now if
you undefine the constant, you can see what I understand is the OP's exact
problem again...

❯ perl -E"package Foo; use strict; use warnings; package main; say 5; say
Foo::BAR()"
5
Undefined subroutine &Foo::BAR called at -e line 1.

There it be. Now you print 5, and you have a runtime error. But, if,

* We can resolve package names in compile time.
* We can obviously resolve symbols in compile time.
* And we can fold constants (0-arity functions)

Why can't we just expose an operator that forces those semantics visible
elsewhere. Added benefits,

1. Foo::->BAR() is a stricter way of referencing a constant/function. If
the constant is removed as the OP desires, you get a strict violation. No
more need to test that the function exists. Insanity that's everywhere at
big perl cOmpany: writing constants, and testing the constant's existence
in the test suite. Now if it compiles, you're good and it becomes a style
violation to reference a constant any other way.
2. Currently we have no way to pass arguments to functions. Despite being
able to resolve a symbol to a function `Foo::bar` in compile time, we can't
provide arguments to functions bar. But you could with `::->` because that
tells you the thing to the left is a package that must exist, and the thing
to the right is a function symbol which should be provided with arguments.


--
Evan Carroll - [email protected]
System Lord of the Internets
web: http://www.evancarroll.com
ph: 281.901.0011 <+1-281-901-0011>