
Portacle – A Portable Common Lisp Development Environment - AlexeyBrin
https://shinmera.github.io/portacle/
======
vespakoen
I tried to install this on OSX (10.12.1), it doesn't seem to handle tar.xz
files well, when extracted using the (default) "Archive Utility", it produces
a ".cpgz" file, which, when extracted, produces a ".tar.xz" file again.

I ended up extracting it using the "xz" utility

    
    
        brew install xz
        xz -d ./mac-portacle.tar.xz
    

Opening the Portacle.app file didn't work, starting it from the terminal gave
me the following:

    
    
        dyld: Symbol not found: _iconv
          Referenced from: /usr/lib/libcups.2.dylib
          Expected in: /Users/koen/Downloads/portacle//usr/mac/lib//libiconv.2.dylib
         in /usr/lib/libcups.2.dylib
        /Users/koen/Downloads/portacle//emacs/mac/emacs.sh: line 51: 44458 Abort trap: 6               "$SCRIPT/bin/emacs" --name Portacle -T Portacle -q -l "$ROOT/config/emacs-init.el" "$@"

~~~
alawrence
I had a similar problem and reported here:
[https://github.com/Shinmera/portacle/issues/22](https://github.com/Shinmera/portacle/issues/22)

From the author's response, it sounds like building from source may work. I
plan on trying later.

------
tempodox
This is cool!

Myself, I'm more of a vim than an emacs animal, so I use the “slimv” plugin,
the vim sibling of “slime”. With a little glue of my own making, it lets me
start the Lisp machine (SBCL) from inside vim, and then I can macroexpand,
disassemble, evaluate, compile... without ever leaving the editor. Practically
turns the terminal into a complete IDE.

------
dimitar
It seems like a good companion for Practical Common Lisp

------
codr4life
It was sooooo about time someone pulled the best of the magic forest together
in a nice package. Thank you!

------
lliamander
I've gotten pretty comfortable with emacs on account of doing Erlang
development for work for the past 5 months. This may be gateway for me to
start actually learning/using Lisp (at least for personal development).

------
proaralyst
I keep hearing about the elegance of Lisps, but as someone who learned
functional programming in ML, I can't get past the lack of currying. Coupling
that with dynamic typing and I feel that I've lost much of what makes
Haskell/ML great: programming by composition with strong compile-time
guarantees of correctness. Am I missing something?

Edit: to be clear, I'm referring to a lack of automatic currying.

~~~
0PingWithJesus
I'm not sure I understand what you mean when you say there's no currying in
common lisp? If you write functions that are curried then you'll have
currying. Am I missing something?

~~~
proaralyst
Sorry, currying by default. In the ML-inspired languages, unless a function
takes a tuple of its arguments it's curried. This doesn't seem to be the case
in any of the Lisps I've looked at. You can certainly curry the functions
yourself but the language doesn't seem to make that easy.

~~~
cronjobber
I'd count ubiquitous currying a design mistake in a dynamically typed
language. All your "wrong number of arguments" errors get caught late.

(But the real problem with common lisp is that its version of (+ 2) is the
ridiculously verbose (LAMBDA (x) (+ 2 x)) — far too many anonymous functions
end up with more boilerplate than content. A decent reader macro might go a
long way towards curing curry envy. If I remember correctly, it's [+ 2 _] in
Paul Graham's Arc, not bad.)

~~~
mtraven
In Clojure it's #(+ 2 %), pretty compact if cryptic. Actually no reason you
couldn't make a reader macro in CL to look similar.

~~~
jdminhbg
Slightly less cryptic would be (partial + 2).

~~~
topkekz
Partial application and currying are two different things.

~~~
jdminhbg
That's correct, I'm just responding to the specific case here.

