Chris Kohlhepp

you can get even more 'real' and run it natively if you compile it for yourself on a jailbroken device. I'm working on this for arm64 (newer devices) and someone accomplished it ~5 years ago: https://chriskohlhepp.wordpress.com/linux-on-iphone/emacs-ocaml-on-ipa…

Author here again: and thank you Tom for your feedback. I'm not the author of Screamer so am not going to defend it's runtime properties. These were not of interest to me and yes I could recode much of what I did in C++ which I am more familiar with than Prolog. I work in low latency trading, so I am happy to take any challenge from Prolog in C++. Bummer would be that I could not publish my solution. The reason Screamer is in there is to allow the problem to be expressed declaratively in terms of universal quantification. See also https://chriskohlhepp.wordpress.com/reasoning-systems/specification-dr…

I was poking around for a GitHub page, a mail address, or a comment feature, but gave up more quickly than you did :-) In the end I now left a comment at the overview post for this series of blog posts at https://chriskohlhepp.wordpress.com/2016/12/06/cryptanalysis-with-lisp… because comments seem to be disabled on the featured post itself.

I don't own any ios device and support for it isn't merged in the repository yet. There are a few git repositories (a bit dated though), regarding building ECL with iPhone[1], and there is a project by Kris Kohlhepp[2] – I've wrote to him recently with the question about patches. If anyone has iOS and will submit a proper PR with some notes about building I'll gladly accept it :-) [1] https://github.com/search?utf8=%E2%9C%93&q=ecl+iphone&type=Rep… [2] https://chriskohlhepp.wordpress.com/embeddable-common-lisp-on-iphone/ BTW, ECL has also (untested, but integrated) ports for NaCL and pNaCL, which should run cross-platform.

> Unfortunately, LISP doesn't quite match [the Von Neumann] architecture, so it has traditionally performed poorly compared to C. Exactly. It has traditionally performed poorly compared to C, but this hasn't been the case for a lot of time. There's a number of misconceptions about what is and what is not a lisp. First of all, a lisp doesn't have to be interpreted or run in a virtual machine. While this is true for a lot of lisps, Common Lisp performs what you could call just-in-time compilation: you can even inspect the compiled code of a function by calling the `disassemble' macro on it, and optimize it based on the disassembly. A lisp doesn't have to be dynamically typed. There are many examples of statically typed lisps (Shen, Dylan, Typed Racket, Lux), and in other dynamically typed lisps such as Common Lisp you can add type annotations as needed to optimize functions. A lisp doesn't have to be garbage collected. It certainly is more convenient to have GC when you have such a dynamic language or want to program in a functional style; however, this is not required. Carp and GOAL[0] do not use garbage collection, and in Common Lisp you can generally give hints to the garbage collector to to make it run where you need it to. A lisp doesn't have to be functional! While lisps usually advocate a functional style to varying degrees (mutation in Scheme is usually marked with a ! in the name of the function (set!) but normally discouraged, Clojure is immutable by default…

This article covers setting up Common Lisp with GADTs and exhaustive pattern-matching checks. https://chriskohlhepp.wordpress.com/metacircular-adventures-in-functio… > We note that we get a non-exhaustive match warning at compile time, not run time. This is the behaviour we would expect for example from OCaml. Indeed, in our little game we might change the simple use of keyword symbols to algebraic data types and thus add compiler hosted verification of our pattern matches. To bring our exploration of the meta-circular abstraction to a full circle: Abstract data-types are an ideal medium in which to represent Abstract Syntax Trees or ASTs. Indeed the whole of Lisp syntax is itself fundamentally an Abstract Syntax Tree. So let’s see if we can represent trees using the cl-algebraic-datatype package. That would amount to an Abstract Syntax Tree represented inside an Abstract Syntax Tree. We will close with that that little teaser.