Some people have suggested putting speakers inside violin cases for exactly this reason -- but I doubt it would work. When a violin is played, the wood vibrates far more than the surrounding air (if it didn't, energy wouldn't be transferred from the violin to the air) so in order to get the same amount of vibration in the instrument, you'd need very loud speakers.
It's funny how commenters keep clinging to Erlang as if I said it was purely functional, when I'm actually talking about writing purely functional Perl (and to the extent that it's possible, C).
Interestingly, C suffers from a somewhat similar ambiguity, where not the results of runtime-at-compile-time but rather type definitions affect the parsing.
In C++, the problem becomes so bad that the language designers capitulated in some instances, and you have to tell the compiler if something is a type or an identifier. Haven't tested this example, but you get the point:
struct test
{
typedef int bar;
};
template <class T> struct foo
{
typename T::bar x; // if you leave off 'typename', it won't compile
};
foo<test> y;
y.x = 5;
What I don't quite understand is why, if it won't compile in the first place (i.e. there is no ambiguity, just correct or incorrect), you need to specify it in the first place. I suspect it somehow makes compiler implementation easier.
It's not about making compiler implementations easier -- it's about protecting template authors against having someone write:
class MyBadClass {
static int bar;
};
foo<MyBadClass> y;
By writing "typename", the template author can indicate that "T::bar" the template author can indicate that "bar" is expected to be a type, not a variable. This is explained in more detail here: http://pages.cs.wisc.edu/~driscoll/typename.html.
Now the parse is ambiguous. While the language could say "you only need to use typename if the declaration would otherwise be ambiguous," it's simpler and more consistent to say "all qualified dependent types must use typename."
...you have to know whether InnerDef is a type or a number. If it's a type, this is a declaration of a pointer y. If it's a number, it's a multiplication which is then discarded.
The problem is that to know whether InnerDef is a type or a number you have to instantiate Template<params>. But C++ templates are Turing-complete: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.14.3...), so performing this instantiation would be undecidable except that C++ defines a recursion depth limit.
the delimitation is not for data (that is closed over like any normal closure), it's for control.
when you apply a reified delimited continuation as a function it returns a value to that call site, to do the same with a traditional continuation you need to apply the reified continuation using call-cc, and it needs to know what to do with this continuation.
There's nothing preventing symbol table modifications done by Perl modules at compile time to be reified into some sort of linkage unit, with which a parser could then statically parse the code.
Similarly it's possible to prove that a certain block of code does nothing but link in such deterministic units, removing the nondeterminism of function prototypes.
Most of the source code out there can be parsed statically without resorting to anything drastic. The semantics of this hypothetical Perl 5 variant do differ, but as a strict subset it will still properly most of the useful code out there.
That's not the point. It is interesting, from a programming language theory perspective, that Perl 5 can not be parsed statically. The person who wrote the proof sketch cares very much about the practical implications of that theoretical result because he's writing Perl parsing libraries.
Also, what you're describing is no longer static parsing.
this is solved ore cleanly with escape continuation/exceptions.
Perl also provides 'last LABEL', which is handy (lets you break out of any level of nesting).
I guess in a language like C where you can have neither and function calls are slow so the 'return' escape continuation is also unusable there is a reason to use goto for this.
