The Idea of Lisp

Post by rntz » Fri, Dec 16, 2016, 10:57 PM UTC

btilly wrote: post #239

pg314 wrote: post #140

Earlier quoted context omitted.

Here's an account by McCarthy of the early history: http://www-formal.stanford.edu/jmc/history/lisp/lisp.html

That is the account that I had read before. It only talks about Steve Russell's first implementation and makes it sound like a mechanical transform into reality of a theoretical implementation. However Wikipedia says that there is a second, and the person that I was responding to indicated that Steve Russell had to create a garbage collector to make it work. Those are things that I had not previously heard, and I'm c…

Post by clarkd99 » Fri, Dec 16, 2016, 11:17 PM UTC

DonaldFisk wrote: post #212

clarkd99 wrote: post #171

Earlier quoted context omitted.

David Clark is like John Smith and no, I am not any famous person but I have been around the micro computer world for a very long time (1975). My website is www.rccconsulting.com where you will find an essay on the data structure I mentioned here called SLIST and some documentation and high level design for the system/language I am currently developing called MAX. Users do care more about response times (as you say)…

There's already a language called Max: https://cycling74.com/products/max/#.WFRNp-wWVpg Your SLIST sounds similar to data structures which go by various names in different languages, e.g. list in Python or ArrayList in Java. Common Lisp vectors support that functionality too. Your VCHAR presumably works in a similar way? I agree ASCIZ is a very inefficient way of representing strings, unless they're guaranteed to be…

Post by cesarbs » Fri, Dec 16, 2016, 11:24 PM UTC

pjlegato wrote: post #238

mbrock wrote: post #128

Earlier quoted context omitted.

I don't think actual Lisp programmers share this obsession with purity and ideal forms. It's more something that shows up in blog posts about Lisp by people who probably don't actually use it. The title of this one is telling: it's about "the idea of Lisp." On the other hand, if you look at, say, ANSI Common Lisp, it's not at all some kind of perfectionistic attempt at divine elegance. It's a pragmatic compromise res…

ANSI Common Lisp is rather a design-by-committee monstrosity which was forced on the unwilling Lisp vendors by the Defense Department. Most of the feature set was designed via backroom political horse trading ("We'll let you include pet feature X if you support us for our pet feature Y".) There is no coherent overall plan or design to it at all. (Source: personal communication from a member of the committee that desi…

Post by vertex-four » Fri, Dec 16, 2016, 11:29 PM UTC

virtualwhys wrote: post #226

vertex-four wrote: post #201

Earlier quoted context omitted.

Isn't that a tuple containing a unit, and therefore not empty?

It's the closest you can get in Scala to represent an empty value whose type is `Tuple`.

    trait Foo {
        type ErrorType;
        fn bar() -> Result;
    }

    struct Abc{}
    impl Foo for Abc {
        type ErrorType = ();
        fn bar() -> Result {
            Err(()) // oops, we don't want to be able to do that!
        }
    }

    enum Void{}
    struct Xyz{}
    impl Foo for Xyz {
        type ErrorType = Void;
        fn bar() -> Result {
            // No way to create a Void, so the only thing we can return is an Ok
            Ok(1)
        }
    }

    fn baz(f: F) {
        match f.bar() {
            Ok(v) => println!("{}", v),
            Err(e) => panic!("{}", e)
        };
    }
    ...
    baz(Xyz); // The compiler can notice that f.bar() can never return a Result::Err, so strip off the match and assume it's a Result::Ok

Post by kerneis » Fri, Dec 16, 2016, 11:44 PM UTC

shakna wrote: post #215

ehsanu1 wrote: post #205

Earlier quoted context omitted.

Do you happen to have a link to your thesis?

Unfortunately not. I had to surrender publishing rights, and the university only publishes about 10 submissions a yeaar... So unlikely to appear anytime soon.