Author: grant

MOSS: A System for Detecting Software Plagiarism

Moss (for a Measure Of Software Similarity) is an automatic system for determining the similarity of C, C++, Java, Pascal, Ada, ML, Lisp, or Scheme programs. To date, the main application of Moss has been in detecting plagiarism in programming classes. Since its development in 1994, Moss has been very effective in this role. The algorithm behind moss is a significant improvement over other cheating detection algorithms (at least, over those known to us).
Moss can currently analyze code written in the following languages:
C, C++, Java, C#, Python, Visual Basic, Javascript, FORTRAN, ML, Haskell, Lisp, Scheme, Pascal, Modula2, Ada, Perl, TCL, Matlab, VHDL, Verilog, Spice, MIPS assembly, a8086 assembly, a8086 assembly, MIPS assembly, HCL2.

Moss was created by Alex Aiken.
(via PLT)

R6RS Steering Committee Replacement Statement of Interest

The following is the statement of interest from my R6RS Steering Committee Replacement voter registration form:

Scheme has not only met, but has far exceeded its goals for academia. With the latitude of problems faced by industrial developers today; now is the time to let Scheme’s light shine in the industry. As a software designer and developer, my interest in this process is that its outcome reflects the needs of “The Working Scheme Programmer”. Ultimately, though, the standardization committee must serve both communities in R7RS.

Until now, the essence of Scheme, “Programming languages should be designed not by piling feature on top of feature…”, has served academia well, but not the industry. Consequently, the community has moved forward independently from the standard. While this is not a problem in and of itself (the SRFIs, for example, have served the community well); incompatible changes have been made between distributions resulting in frustrating incompatibilities. Solutions to standard problems like modules ought not to require any effort to be made portable across different implementations.

The efforts of R6RS, the first step at addressing the needs of both communities, were largely marred by the dissatisfaction with its result. The community simply felt that the report did not hold true to the spirit of Scheme. It is that spirit which will be so important not only to the community, but to the steering committee itself, in moving forward with R7RS.

At one moment in time, Scheme itself was an experiment. Scheme encourages experimentation. Sometimes experiments fail, though, and when they do, it is up to the scientist to learn from the mistake and keep moving forward. The outcome of R6RS can either be used as an excuse for the community to disband, or as a lesson on how to move forward. I choose the latter.

The new steering committee needs to focus on the processes and procedures that allow for both communities to be served in the manner that best realizes the spirit of Scheme; doing so in a manner that honors Scheme’s past, listens to the voice of its community today, and steers diligently towards the future.

If you have an opinion about the future of Scheme then you should register and participate in the process.

How many kinds of Schemers are there?

Since the beginning of my study of Scheme I have tried to understand the community. What I have found is that if one had to define a single trait by which you could make a classification it would come down to whether or not they wanted more than what R5RS defines, or not. A few days ago in this thread on comp.lang.scheme, a poster elaborated on this: 


1. People who prefer R5RS, and think it should not have been extended.
(Felix Winkelmann, maintainer of Chicken)
2. People who like R5RS, dislike R6RS, but think a better standard for
Scheme is possible (Will Clinger, maintainer of Larceny)
3. People who use R6RS as their primary language (Aziz Ghoulum,
maintainer of Ikarus)
4. People who use a particular Scheme implementation (myself, using
PLT)

As he pointed out, that is a non-exhaustive list. A question for the reader:

“What is missing?”

Different approaches to shaping code

It is fun to see how different people solve the same problem in code because you often learn new things in the process. In this thread in comp.lang.scheme, the original poster asked about how to define a particular shape of code, but without using non-hygienic macros. My approach is posted within the thread.
The solution itself is no where near as interesting as how it was reached. Basically I followed the lessons that I have been learning by studying HtDP, and the result was basically that the solution “wrote itself”. Granted, I have not reached a “Design Recipe” for writing macros (I suspect that there is not such a recipe in the book); but the disciplined approach may be followed all the same.
Everyone who wants to become a better programmer should read HtDP!

Mondo Bizarro

In this thread about a closure puzzler Jens posted Eugene Kohlbecker’s mind-bender called Mondo Bizarro. 


;;; Mondo Bizarro

; What does the following program print?
; Why?

(define program (lambda ()
    (let ((y (call-with-current-continuation (lambda (c) c))))
         (display 1)
         (call-with-current-continuation (lambda (c) (y c)))
         (display 2)
         (call-with-current-continuation (lambda (c) (y c)))
         (display 3))))


(program)

Mondo Bizarro seems to have been originally published in ACM SIGPLAN Lisp Pointers, Volume 1, Issue 2 (June-July 1987), located here; but I could not confirm that.

Here is an implementation of it in Java.

(via the PLT Discussion List)