Funny characters inference

Aggressive Type Inference
In talking with people at last year's Python Conference (IPC7), I mentioned the possibility of writing a Python compiler... in Python. Not content to stop there, I suggested that the idea could be taken further, to translate Python code into Perl.
[...]
What does this have to do with type inference? The translated Perl code must have the $@%&* type specifiers on all Perl variables.
Can we look at this as a constructive proof that funny characters are (mostly) not needed by compiler, and are there only to please the programmers?

I decided against posting this in the thread that mentioned ugly syntax (not of Python), as it was pretty long and losing focus already.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

SNAFU

The translated Perl code must have the $@%&* type specifiers on all Perl variables.

At first I thought this was an expression of frustration, but now I see that it's just Perl.

Perl and its sigils

In some contexts, though, aren't they necessary? There are many examples of where both $foo and @foo are valid expressions which produce different results.

This observation isn't intended as an exoneration of Perl; instead it just serves as a reminder that the sigils do carry some significane to the compiler; and just aren't there to serve as a butt-ugly form of language-enforced Hungarian notation. :)

Yes, I believe they're a form

Yes, I believe they're a form of type specifier - you might call inferring their presence "type inference", if I may coin a phrase.

Haskell

We can have the same thing in Haskell using type-classes without having to specify the expected context, if the type inferencer can verify that it's unambiguous. A good example is this:

[Haskell-cafe] Perl-ish =~ operator