Deprecate PASM1 compiler and PDB_compile function

[coke]

+1 from me. What happened to this compiler, ripping out all it's functionally and replacing it with an exception, doesn't really satisfy the deprecation policy, but then again keeping in a feature that doesn't work for the sake of keeping it not working doesn't really do so either.

I don't think we've really given it enough thought, but "features" that didn't work at the time that the deprecation policy was adopted should really be grandfathered in as being "experimental" features. They didn't work, there wasn't an expectation that they would "continue" to work, etc. Better to just remove this and be done with it.

[coke]

A reasonable response would be to immediately deprecate this compiler. Near as I can tell, it's completely untested, and documented only in passing in a chapter of the draft book.

[coke]

NotFound suggested on IRC that we simply delete this compiler, as it is untested and broken. I agree.

If it /never/ worked, there's no point in keeping it; easiest way to check this (given lack of tests, see TT #672), is to verify that it also failed in Parrot 1.0.0; I think if we do that, then we can safely remove it now.

[NotFound]

Tested with  https://svn.parrot.org/parrot/tags/RELEASE_1_0_0 and it segfaults the same way.

[NotFound]

I suggest that together with the PASM1 pseudo compiler we also delete the function PDB_compiler declared in include/parrot/debugger.h whose only usages are to implement PASM1 and the debugger comand eval, which also doesn't work. And make that command just emit an "unimplemented" message.

[NotFound]

In yesterday's #ps it has been decide to deprecate this functionality and throw exceptions in attempts of usage. Deprecation note added and code fixes done in r40408

[coke]

Removing the implementation of something entirely and throwing an exception when its used isn't deprecation.

We should either:

1) leave it alone until post 2.0 on the off chance that someone was using it in a way that worked for them (even though no one has been able to provide code that might demonstrate its usage, I'm willing to believe it exists.)

Or

2) delete it entirely, on the assumption that it never worked.

Or

3) emit a warning when it is used, but otherwise leave the implementation alone. This can be tied to parrot's warning feature, as deprecated opcodes do.

The current solution, removing the guts and throwing an exception, means that anyone who was potentially using it can't; This has effectively already removed the feature from parrot, and if we're going to do that, let's just do it.

If instead we're trying to warn people, #3 is preferred.

[whiteknight]

Replying to coke:

Removing the implementation of something entirely and throwing an exception when its used isn't deprecation. We should either: 1) leave it alone until post 2.0 on the off chance that someone was using it in a way that worked for them (even though no one has been able to provide code that might demonstrate its usage, I'm willing to believe it exists.) Or 2) delete it entirely, on the assumption that it never worked. Or 3) emit a warning when it is used, but otherwise leave the implementation alone. This can be tied to parrot's warning feature, as deprecated opcodes do. The current solution, removing the guts and throwing an exception, means that anyone who was potentially using it can't; This has effectively already removed the feature from parrot, and if we're going to do that, let's just do it. If instead we're trying to warn people, #3 is preferred.