Ein LISP, Ein standard!

File: swipl.png (18KB, 170x140px) Image search: [Google]

18KB, 170x140px

Install Prolog.

Who the fuck still uses lisp?
I'm reading mailing list stuff from before I was born and people were still fighting over dialects.

Also, I don't know people can call common lisp a beautiful language, it looks like a fucking hackjob.

File: 1492261269450s.jpg (6KB, 242x250px) Image search: [Google]

6KB, 242x250px

>>60764863

Already happened. Meet ANSI Common Lisp:

https://en.wikipedia.org/wiki/Common_Lisp

There are many Common Lisp implementations. I recommend Steelbank Common Lisp because it is compiled and therefor quite fast: http://sbcl.org/

>>60765015
CL IS a disgusting hackjob, but very useful
Scheme is beautiful, but would require you to implement almost everything you'll need

>>60764863
Want a standardized functional language?
Use SML.

>>60765015

I use Picolisp daily, because compiled lisps are something that shouldn't exist.


Just dont look at the language page tho. some fag killed it by (((designing))) it for free.

that so many dialects can coexist speaks to the meta power of what lisp actually is
get stuffed faggot

scheme master race though

R7RS?

>>60765015
>>60765364
what is actually so bad about Common Lisp? I write it daily.

>>60767323

Its a standard that bases itself around the kludge known as macro.

>>60767263
Would archive.org have a better version of the page?

>>60767346
Is there any Lisp without macros? Can't think of one.

>>60767369

Maybe, check circa 2014.
Design wise it was flawless, very simple and succinct.
Cant even understand why Alex would change it, guess germans being unable to say no is actually true.

>>60764863
But there IS only one relevant Lisp: it's called Racket.

>>60767374

Picolisp doesnt need macros because its fully interpreted(and fast due to how simple it is)

>>60767472
I took a 30s glance at it. It's shit. Why are you trying to sell it to us?

File: lisp.png (110KB, 991x772px) Image search: [Google]

110KB, 991x772px

>>60767419
That it?

I don't get what's so good about macros can't you just make a function that does the same thing as a macro?

>>60767490

A simple but powerful lisp.
Forget the page, it will just make you disgusted.
Read this instead
>https://github.com/tj64/picolisp-works/blob/master/editor.pdf?raw=true

>>60767508

Something like that, but the CSS was different.

Can someone sell lisp to me?
I'm a giant C89 zealot and I'd love to branch out with a different programming paradigm.

File: 1480913277970.jpg (13KB, 366x329px) Image search: [Google]

13KB, 366x329px

>>60767539
>I don't understand macros waaaaaahhhh
kys

>>60767539
Macros let you read arguments passed in unevaluated. In other languages this would be like passing in an AST as an argument, and processing that AST to generate a different source code out of it.

>>60767649
I still don't get it maybe I should just kill myself like >>60767639 says

>>60767581

Man, its kinda hard it to put.
Imagine if in C you could make a function that wrote the function you wanted in the end, with less verbosity sometimes.
Thats is basically the advantage of a lisp then you realize you can do all sorts of magic with that concept.

>>60767683

Macros are used because the basis of lisp(code is data/data is code) is lost in the process of compiling.

>>60767581
Have you used Yacc?

>Way too many dialects. Just standardize on one.
Yeah like they could take all the common features and standardize them into a new lisp. Maybe they could call it "common lisp", I dunno, name needs work.

daily reminder that the only scheme programmers are either cloistered academics or NEETs
>kys

>>60767748
>Imagine if in C you could make a function that wrote the function you wanted in the end, with less verbosity sometimes.
So it's a declarative language?
Or are you describing combining data and code to create closures?

>>60767818

Data and code, and not necessarily only at compile time.

>>60767836
>>60767836
You're describing closures, where you create functions that return more functions.
Javascript does this, and it's a widely celebrated feature for it.

What makes this different?

>>60767813
Can confirm, I'm a neet and all I do is shill for Lisp / make trivial programs in it.

there's really 3 that matter: CL, R5RS and later and Clojure

>>60767862

Not necessarily because in lisp there would be no difference if it were code to be executed or data.
For example take this

(let fn '(min max)
    ((rand fn) (1 2 3) ) )

or something like that.

>>60764863
>When are you LISPers going to knock it off with the Tower of Babel shit? Way too many dialects. Just standardize on one.
You have actually unknowingly realized the core reason why LISP is never going to catch on. It's so easy to roll your own lisp that everybody just does that as a learning opportunity instead of doing something useful with a standard implementation.

Speaking of standards, I'm pretty sure that Clojure is more popular than either Common Lisp or...what are we up to now, three?...different Scheme implementations, and that should tell you something.

It also doesn't help that LISP predates most of what our industry knows about parsing, and essentially asks you to give it damn near an abstract syntax tree in s-expression format. Fuck that noise, the compiler should be helping us here.

If you're desperate to learn a functional language, you're much better served by the ML family, such as OCaml or F#. Or Clojure I suppose, if you're desperate for (((parenthesis))).

>>60767862
Closures are not functions that can return functions; what you're referring to is treating functions as first class citizens. A closure would be a function with it's own environment. Here's some examples in Common Lisp:

(let ((count 0))
  (defun closure-counter ()
    (incf count)))

(closure-counter)
  => 1
(closure-counter)
  => 2

(defun not-a-closure ()
  (lambda (y)
    (+ 10 y)))

(funcall (not-a-closure) 1)
  => 11
(funcall (not-a-closure 2) 2)
  => 12

Notice how the counter retains its environment after being called multiple times; this is an example of a closure. Now look at the second function "not-a-closure" which simple returns an anonymous function whose purpose is to add 10 to whatever you give it; this is an example of treating functions as first class citizens.

lmao @ lisp
>>60768302

>>60768216
And what would be an application of it? Safer code by containing the whole state within a function?

>>60767649
So you can use it to change the syntax of the language, but whatever you can do with a macro, can be implemented without changing the language.
Can I see an example of a macro taking advantage of not evaluating the code for something else? Or is changing the syntax really that helpful.

>>60768216
isn't one of the advantages of purely functional code being stateless?
how would one construct the same example in Scheme?

>>60768415
I wouldn't say closures produce safer code, but they're certainly a useful abstraction to have; closures are applicable over a wide domain of problems. I'm going to use another simple example here to help demonstrate this.

(defun bank-account (balance)
  #'(lambda (action amount)
      (case action
        (deposit (setf balance (+ balance amount)))
        (withdraw (setf balance (- balance amount))))))
(defvar account (bank-account 100))
(funcall account 'widthdraw 10)
  => 90
(funcall account 'deposit 5)
  => 95

This example I've stolen out of PAIP since it was the first example that really gave me that "Aha!" moment for understanding closures.

>>60768580
I think there's been a bit of confusion in the flow of the thread. Macros and closures are not the same thing. Closures are functions with some private state, they can be done in most(any?) lexically scoped language with first class functions.

On the other hand I know of no other language family with Lisp style macros. At the core of running Lisp code is the read-eval cycle, code is read, parsed into an AST, and then evaluated. A macro is essentially a hook into the read stage of the compiler, they're not textual transformations a-la C macros, but work by manipulating the AST before it is executed.

Here are a couple of very simple examples of macros that could not be implemented in the same way as a function.
The first creates an alias to an already existing function. If this were written as a function the user would need to provide as arguments quoted symbols to stop them from being evaluated. This is annoying so a macro is used to remove the need for quotes, since macros do not evaluate anything.
The second I pulled from my WM config, it takes as argument a lisp form that presumably manipulates the window layout in someway. The macro records the focused frame before body is evaluated, and then restores that focus after body has been run. This is achieved through the common patten of splicing a given form into the middle of a let form (@ is used to splice a list).

(defmacro alias (to fn)
  `(setf (fdefinition ',to) #',fn))

(defmacro with-frame-remain (&body body)
  "Return focus to initial frame after evaluating body"
  `(let ((frame (this-frame)))
     ,@body
     (focus-frame (current-group) frame)))
 

>>60767263
could you explain why you would use Picolisp (or NewLisp) rather than a regular Lisp dialect? I dont understand what lisp-like scripting languages have to offer except less than a full Lisp experience

traditional Lisps are held back by being based on cons cells which are linked lists. Clojure is based on immutable data structures, so instead of processing everything as a List you have sequences which are the default underlying structure which all container types are based on, so you can use a unified set of functions that work on arrays, lists, maps all as the same thing underneath. Because these data structures are immutable this allows you to use pure functional programming techniques on data that will never change. Clojure is the only Lisp dialect everyone should be using now, everything else is obsolete

>>60767323
>I write it daily.
For what field?

>>60764989
is it true I can make a prolog-like usub-language in lisp?

>>60770247
What exactly is wrong with the cons cell, in your view? All you've said is typical Clojure evangelism without any details. Never mind the fact that proper introspection is impossible when half the functions calls are foreign and it's all too eager to have you come face to face with that reality by vomiting JVM stack traces.

Common Lisp has had generic sequences, arrays, and hash maps for decades. it's not a matter of performance either because Clojure is typically slower than SBCL CL.

>>60768849
>Common Lisp
>purely functional
lmao, everyone know common lisp is multi paradigm with lots of imperativity
that's why I like it, because it can be functional, i.e not a one trick pony like haskell.

>>60770404
I'm not an expert, but I dont think you can covert a list to an array in CL because they are implemented differently. Traditional lists are implemented on primitive hardware functions and the language itself then bootstraps on top of that by being written in Lisp itself based on these primitive functions

>>60770622
Are you drunk?

>>60769444
StumpWM?

>>60770720
Are you butthurt because I proved Clojure is better?

>>60768849
>>60770549
Closures are an essential part of non-trivial functional programming, you can use them in Scheme and Haskell too.
They're not so much a feature as a natural side effect of the way expressions are evaluated in a lexical environment.

So yes, it's possible to create something akin to simple objects in a purely functional language. Adding something like inheritance is much more complicated of course, but it can be done.
This returns a list of three methods, check, insert, and withdraw, all using the same internal state. Typically you'd supplement this with a macro to assign those functions to actual names.

 
(defun new-account (initial-balance)
  (let ((balance initial-balance))
    (list (lambda () balance)
          (lambda (x) (incf balance x))
          (lambda (x) (decf balance x)))))

>>60770622
(coerce list 'vector)

>>60770769
>closures in haskell
I really doubt it.
You can't change state in the wheres.

>>60770764
He probably asked that question because your comment was nearly incoherent, and to the extent is was not meaningless babble, didn't even rise to the level of being wrong.

>>60770824
Consider currying.
There are also mutable 'cells' (although they're usually bad form), even if data mutation is not part of the language.

>>60770856
thats what I thought, hes butthurt so hes trying to do damage control with ad hominem

>>60765015
Clojure is pretty big right now

>>60764863
I need help someone knows how to track a cell phone is extremely important, this thief not only has my cell phone but other important things

>>60767323
I didn't say bad.
It's ugly, probably because it was the compromise between a few dialects, which makes it a hack job, as it was hacked together.
It does not mean it's broken or unusable
Now I'll go sit in the corner and sulk because you get to write in it daily while I write in tcl

>>60771552
What did you do to be condemned to writing in tcl of all things?

I've had one experience with it, never again.

>>60764863
It's called scheme.

It has the same issue but it works by revision compatibility and the languages are basically just small libraries along with interpreters/compilers.