This idea has been bouncing around in my head for a while. I'd like to propose an annual contest called

Archaic Code Contest in Common Lisp

I propose that it be held every October. The task for the contest will be released on the first of October and the deadline for entries is the last day of October. The goal of the contest is fun which is achieved by limiting the programming constructs to "Archaic" functions like CAR and CDR and perhaps only lists as data structures.

The first step is to define the allowable Common Lisp data structures, conditionals, iterative functions and access functions. Generally, I think data structures should be limited to lists. Macros should *not* be allowed because then people would just Greenspun "Modern" Common Lisp functions. Simple conditionals like IF are allowed, but I'm not sure COND is "Archaic" enough. What about iteration, should DOLIST be allowed or only recursion? Basically, I want to limit the allowable forms to the bare minimum "Archaic" forms while still enabling interesting problems to be solved. I'm going to do a little more research into what qualifies as an "Archaic" form.

Once we've hashed out what are the allowable forms, we can start discussing the types of problems to pose for the contest. Looking forward to everyone's thoughts. I'll try to collect my thoughts more, incorporating any ideas from responses, and follow this post up in a few days with better defined rules for the contest.

I once saw a CL tutorial (but it was in Brazilian Portuguese) in which there was some interesting exercises similar in idea to this contest. It allowed you to use only defun, if, zerop, 1+, 1-, cons, car and cdr, and told you to define all common operations with integers and rationals (+, -, *, /). The functions cons, car and cdr was only used when defining rationals. The result, off course, isn't fast, but it works.They were interesting exercises, it is nice to do abstractions, but doing big things this way might be just painful.

If you really want to do this right, you should limit yourself to the fundamental forms defined in "Recursive Functions of Symbolic Expressions and Their Computation by Machine." This was THE original paper that defined Lisp, written by John McCarthy in 1960. Of course, using those fundamental forms you can define all of modern Lisp (which was sort of the point of the whole paper ).

So is it trivial to create an environment where you don't have the possibility of cheating? From what I understand you could add what you wanted to make available to a package and just tell people not to use anything outside of it. Seems like it should be ok to create macros. If you have someone with a cpan / asdf approach to everything, even defining their own fundamental macros could be a liberating experience. I am pretty sure I couldn't create 'loop' from scratch anytime soon.

findinglisp wrote:If you really want to do this right, you should limit yourself to the fundamental forms defined in "Recursive Functions of Symbolic Expressions and Their Computation by Machine." This was THE original paper that defined Lisp, written by John McCarthy in 1960. Of course, using those fundamental forms you can define all of modern Lisp (which was sort of the point of the whole paper ).

findinglisp wrote:If you really want to do this right, you should limit yourself to the fundamental forms defined in "Recursive Functions of Symbolic Expressions and Their Computation by Machine." This was THE original paper that defined Lisp, written by John McCarthy in 1960. Of course, using those fundamental forms you can define all of modern Lisp (which was sort of the point of the whole paper ).

Thanks for the reference. This is what I was thinking of. I'm going to go through it and compare what's defined with what is in CL.

jrigler wrote:So is it trivial to create an environment where you don't have the possibility of cheating? From what I understand you could add what you wanted to make available to a package and just tell people not to use anything outside of it. Seems like it should be ok to create macros. If you have someone with a cpan / asdf approach to everything, even defining their own fundamental macros could be a liberating experience. I am pretty sure I couldn't create 'loop' from scratch anytime soon.

It is not trivial. I think this would be a secondary benefit of the contest, trying to create an environment that would not allow cheating. It could be the basis for deploying a "secured" REPL. Based on the discussions I've seen related to creating a limited environment in CL, the consensus seems to be you cannot rely on packages, you have to intercept and validate all commands. I've not looked into this in detail, but did recognize it as an issue.

The "secured" REPL concept has spawned a second contest idea, to break the "secured" REPL. That might be much more interesting. The contest could be in 2 parts. In the first part, a team defines a "secured" REPL with a specified set of operations. In the second part, the adversary team tries to break out of the "secured" REPL. Initially, stick with one implementation, then down the road try the contest on multiple implementations.

gugamilare wrote:They were interesting exercises, it is nice to do abstractions, but doing big things this way might be just painful.

The idea is that the challenge would be just big enough to be interesting/entertaining/thought provoking, but not so big as to be painful.

tayssir wrote:Maybe you can get unofficial style points for using the old formatting style.

findinglisp wrote:If you really want to do this right, you should limit yourself to the fundamental forms defined in "Recursive Functions of Symbolic Expressions and Their Computation by Machine." This was THE original paper that defined Lisp, written by John McCarthy in 1960. Of course, using those fundamental forms you can define all of modern Lisp (which was sort of the point of the whole paper ).

Thanks for the reference. This is what I was thinking of. I'm going to go through it and compare what's defined with what is in CL.

jrigler wrote:So is it trivial to create an environment where you don't have the possibility of cheating? From what I understand you could add what you wanted to make available to a package and just tell people not to use anything outside of it. Seems like it should be ok to create macros. If you have someone with a cpan / asdf approach to everything, even defining their own fundamental macros could be a liberating experience. I am pretty sure I couldn't create 'loop' from scratch anytime soon.

It is not trivial. I think this would be a secondary benefit of the contest, trying to create an environment that would not allow cheating. It could be the basis for deploying a "secured" REPL. Based on the discussions I've seen related to creating a limited environment in CL, the consensus seems to be you cannot rely on packages, you have to intercept and validate all commands. I've not looked into this in detail, but did recognize it as an issue.

Why isn't telling everyone to use only the symbols of a particular package safe? I can't think of a single example, unless, of course, this package provides functions like intern, *package*, read, eval, ... So, if the symbols of a package are carefully defined, I don't see why it wouldn't be safe.