Vigil: A programming language with eternal moral vigilance
github.com
github.com
I should note that an ordinary contract system does not delete your code...
[1] http://en.wikipedia.org/wiki/Eiffel_(programming_language)#D...
[2] http://www.eecs.northwestern.edu/~robby/pubs/papers/ho-contr...
Much to my dismay.
Implore asserts that a test passes (prototypically on a passed in parameter), but if that test fails the blame is on the calling function.
Swear on the other hand will assign blame to the current function if the test fails.
It would still be compliant with the standard.
But only user code is required to be well-formed and have defined behavior, system headers could just as well be written in Forth as long as the actual behavior under the compiler they come with is correct.
To understand this better, realize that, ultimately, a standard is a contract. A standard says, in part, "If you refrain from doing these things, the system promises to do these things and not do these other things here."
"Undefined behavior", then, is invoked by code that strays from the standard by doing things the standard makes no guarantees about, like casting a value of type pointer-to-double to type pointer-to-char and dereferencing the result; the behavior of the compiler and the code the compiler emits is then undefined, which is to say its behavior is not guaranteed by the standard.
And, yes, a conformant C compiler is perfectly within its rights to delete code that it can tell invokes undefined behavior.
He is not accusing the compilers of executing undefined behavior. He is accusing them of exploiting undefined behavior to "optimize" code.
His points are:
1. Current compilers will perform optimizations based on undefined behavior. That is, during the optimization phase, they will say "Aha! That's not defined! I'll instead do this much, much faster thing as an optimization."
2. Lots of real code has undefined behavior.
3. The programs that result from these codes still produce the answers we expect, mostly.
4. If we take point 1 to its logical conclusion, then point 2 means that point 3 will no longer be true. That is, if compilers aggressively and thoroughly sought out to find all instances of undefined behavior in C code, and just optimized it away, many (most?) programs would cease to do much at all.
For example, the result of x+y is undefined for signed integers in C, because we want it to compile it to a minimum number of instructions on every architecture. No instructions to check for overflow and branching afterwards. No error correction instructions on architectures where semantics differ to the language semantics.
If it does overflow, it's either a target-specific hand optimization or a programmer error, but that varies on a program-by-program basis, hence GCC having -fwrapv, -ftrapv, and the default of "I don't do that, optimize accordingly".
I consider that an example of "Maximally Redundant MRAS Acronym Syndrome".
http://www.newscientist.com/article/mg19025562.700-feedback....
http://www.reddit.com/r/haskell/comments/145gw8/warning_easy...
This project clearly needs to be amended to integrate with version control.
Or perhaps justified in deleting you instead, as it is you who has sinned, not the source code.
...
Certainly this approach leads to a more pure universe, but, I suspect, a rather sparsely populated one.
(Eliezer, do me a favor and keep munificent away from AI development....)
Good thing I haven't installed Vigil or this error could pose a problem for me.
This is now my new favorite phrase.
In order for the human to produce a valid function that human must mentally execute the code s/he is writing. If that code is flawed then the mental compiler should delete the sinful code from the programmer's memory before it ever makes it to digital form.
If vigil merely deletes the code then it's acting like the human's brain, and forces the human to try again. But it does not eradicate the source of the sin. It acts as a tool for the human rather than a universal enforcer of good morals.
Note that one can lie as to one's sinfulness. Rather than lie about implores and swears a function can deceive by stating none at all (or just weak ones). This is like pleading the fifth. This is like not promising to not do something bad and therefore not being dishonest if you do do something bad.
Should flaws in vigil cause vigil to delete itself? Or should the inherent flaws in vigil cause it to delete the programmer who made vigil? If vigil can not catch all sins, as it currently cannot, should it therefore delete both itself and it's author immediately? If it does any less than this then it falls short of being an enforcer of pure morality, instead settling on a subset deemed of utmost importance.
Or is it a Hobbesian sovereign?
1. It is wrong not to punish immoral code. 2. You cannot punish all immoral code without a solution to the Halting Problem. 3. You cannot solve the Halting Problem.
∴ Vigil must delete itself. QED.
[The Hobbesian rebuttal]
1. We give up all other rights in order to protect our code from immorality - among these are any right to a solution to the halting problem.
2. As socially contracted sovereign, Vigil is exists only to enforce morality upon our code.
3. Nothing can have a nature contrary to what is necessary for it's existence.
4. Deleting itself would be contrary to the social contract which is necessary for its existence. Hence, it is absurd.
RAA: Vigil cannot delete itself.But, remember, Vigil only holds you to the oaths you yourself have sworn. If Vigil swears to punish a function, then it should be punished for failing to do so. But if it's given no oath to that effect, then it's off the hook.
You may reasonably ask yourself, "well, what oaths does Vigil swear to uphold?" The answer is a frightening "none", since Vigil is not currently written in Vigil (nor is the README, which is in Markdown, a decidedly sinful format).
I don't think you can have turtles all the way down.
[1] https://news.ycombinator.com/item?id=5001504 (full disclosure: I'm the submitter of this link)
Otherwise, the original code could just totally disappear after multiple runs. What good is non-buggy code if it does nothing? Failure to perform the user's requirement at all is also a bug. Not having the original code that you can at least edit to fix is rather pointless, especially when vigil doesn't indicate the callers of the offending functions, because next time you run vigil, those will get deleted. Besides, if foo()'s failure is completely due to bar()'s failure to fulfill its 'swear', it's foo()'s failure is not really its bug.
On a serious note, what you're thinking of is contracts, like so[0]
Macros would be deviating from core JS too much to fit with CoffeeScript's goal. Just happens that the compiler is nicely hackable to allow for these projects.
Not to say I object to the idea of an expanded CoffeeScript, just that it should be a fork.
http://disnetdev.com/blog/2012/10/14/hygienic-macros-for-jav...
and http://brendaneich.github.com/Strange-Loop-2012/#/40 http://www.infoq.com/presentations/State-JavaScript
I believe this would make it no different from an 'assert'.
In my opinion, deleting code is fine...however you should 1) be warned that it will happen in the near future if you do nothing about it and 2) it should be tied to some version control system (e.g. GitHub) where it pushes the deletes (maybe even creating a branch and remerging it so the changes are clear) so that code can be recovered if need be.
Vigil can maybe even have some logic built in if you revert deleted code it gets "angrier" and starts more aggressively purging code in the future :P
This idea seems actually quite awesome for a competition. Its truly a dungeon-crawler of programming.
Suggested extra hard-mode for short competitions: deletes all code.
Too easy: then it's obvious you have to rewrite it. Hard mode is it replaces random tiny expressions with syntactically similar but semantically different ones... sometimes.
Vigil reminds me a little bit of Intercal, with its "Programmer is insufficiently polite" errors.
Sounds like an exactly half bad idea, actually.
1. Parse the code into an AST (to strip away any pre-parse differences, like formatting or syntactic sugar usage), then hash that AST (recursively--replace any non-primitive function references with hashes of their own current ASTs)
2. Run unit tests, fuzz, etc--taking the AST hashes of each function of the testing code as well (though using symbolic, rather than "hard", references to the implementation-code, so it can change without making the test's hash change)
3. If a piece of code fails a test, add the pair (test AST hash, code AST hash) to some database (preferably an online, global database).
4. From then on, before anything is allowed to be compiled, perform a lookup in said database, and refuse to compile anything if the database finds any known (test, failed code) pairs in your code.
---
The interesting thing is that this system is very conservative--if a piece of code depended on by the code you wrote changes, then your code is given another chance (because maybe your code was just failing because it was expecting something of that other code, and that other code was wrong, and then it was fixed.)
Likewise, if you change the requirements, your code must be re-evaluated for conformance--code shouldn't be barred because it fails a "wrong test" like assert_equal(add_two_plus_two(), 5);.
But on the other hand, if you add tests, the old barrings based on previous tests stay in effect as well--this actually incentivizes breaking unit tests into small, orthogonal functions that pass or fail separately.
I don't think there would actually be any problem doing real development under this "restriction". In practice, given the way we currently do software engineering, it would only catch problems within your own project that had been seen+caught before--because those would be the only tests you had included.
In theory, though, you could also import, say, a global "test set"--basically, AST hashes for every test of the current stable branch of all major open source projects, or something similar--and check your code against that as well, just in case you happened to write, say, an incorrect date-handling function that someone else had ever written in an AST-identical way.
Consider this: you've got some script that does a sequence of operations using the standard tools. Somewhere you change between imagemagick and graphicsmagick and some image doesn't get made thanks to syntax differences; after this you've used some clever shell filename expansion expression or regex to move/delete files, but the missing image changed your working context enough that suddenly you're in $HOME doing an rm -rf .! The environment is just too fragile and powerful to completely automate everything you might need without setting up enough safety mechanisms, confirmations, and sanity checks to largely nullify the value of scripting as a nearly zero development programming toolchain.
But if shell code were trivially spec'd for pre-/post- conditions and misbehaving code gets noisily deleted (noisily so everything isn't packed away into code versioning purgatory by cascading failures when a tool like rename is accidentally uninstalled)---especially if the shell of pre-and post conditions were left around stub code... Imagine the beauty of your scripts directory!
Replacing some slain block of code is trivial since the tools you need are already mostly written, and you've done something close to what you need before---plus the whole point of shell scripting is that it should be effortless and fast to produce.
If you've built a massive, multi-purpose utility, it deserves to live only as long as it runs flawlessly---after which, you should slice it down or replace it with an inevitably more reliable equivalent that was written for the same purpose years (or decades) ago.
Best of all the conditions that deleted your broken cruft even remind you exactly what you needed to do when you're re-implementing something, but often without pre-studying the entire system to ascertain what world state you are getting and what you need to produce. Brilliant!
This may have started out somewhat tongue-in-cheek (since most programming environments are at least somewhat stable and feature significant error detection and recovery facilities), but I think there's some dead serious application in the quick-and-dirty, often unchecked and fluid environment of traditional shell scripting. The more I think about it, the more I'm amazed my quarter million keystrokes of live scripts woven into my every task on my Linux desktop haven't produced more catastrophes (or any meaningful accidental data loss) or left a trail of silent failures for me to find only long after the causal bugs had manifested.
Somewhat?
Shit, I probably should have read the rules before I entered.
"Harry James Potter-Evans-Verres!
Harry James Potter-Evans-Verres!
HARRY JAMES POTTER-EVANS-VERRES!":)
Even the implementation looks like it's just custom error text for `assert`.
"If an oath is broken, the offending function (the caller in the case of implore and the callee in the case of swear) will be duly punished. ... it will be deleted from your source code"
Hahah, awesome.
Outsource-proof.
It's more like the feudal lords obligation to his vassal - that he provide them with the use of the fief and protect them from others. If the function is the fief, then you provide the use of it only to those other functions that will swear fealty to you.
25% Writing code 10% Reading the traceback documentation 40% Writing the README 20% Browsing a thesaurus for the best words 5% Cursing after Vigil deleted part of the example
I tell you what, trying to get this thing to self-host is... tricky.
Seriously, this is some Imperium of Man PL research.
illa 'quis et me' inquit 'miseram et te perdidit, Orpheu,
quis tantus furor? en iterum crudelia retro
fata vocant, conditque natantia lumina somnus.
iamque vale: feror ingenti circumdata nocte
invalidasque tibi tendens, heu non tua, palmas.'
dixit et ex oculis subito, ceu fumus in auras
commixtus tenuis, fugit diversa, neque illum
prensantem nequiquam umbras et multa volentem
dicere praeterea vidit; nec portitor Orci
amplius obiectam passus transire paludem.