Practical Common Lisp is disorganized shit.

So is Common Lisp.

If it ain't Scheme, it's shit.

As much as I dislike both CL and Scheme, at least CL has a fucking standard library. Scheme is the most niche things I've ever seen.

>>2
Scheme cant into first-class environment.

>>3
Because changing scheme distributions is something that happens all the time. Just use Racket and quit crying already.

>>5
Racket is bloated shit. What happened to minimalistic MIT Scheme?

>>6
>>3 stopped using it because it didn't have a good library and everyone just gave up, because it was over, scheme was finished.

>>7
At least it had not syntax-transformer crap.

>>8
syntax-to-syntax functions are so hard to understand
Please stick to Python, friend, it seems you are not ready for the big time.

>>9
Python, like Scheme, has no real macros. CL is the only manly language today.

Common Lisp: defmacro
---------------
Scheme/Racket: begin-for-syntax syntax-e syntax->datum syntax->list syntax-property #' (void) quote-syntax datum->syntax syntax-parameter-value syntax-rule raise-syntax-error internal-definition-context? syntax-parameterize make-set!-transformer prop:set!-transformer free-identifier=? syntax-local-value/immediate syntax-local-transforming-module-provides? syntax-local-module-defined-identifiers syntax-local-module-required-identifiers make-require-transformer (require (lib "stxparam.ss" "mzlib")) syntax? (require mzlib/defmacro) define-macro syntax-local-lift-expression (require racket/stxparam-exptime) make-rename-transformer syntax-local-require-certifier make-parameter-rename-transformer syntax-local-value define-syntax-parameter make-provide-transformer syntax-local-provide-certifier syntax-source local-expand/capture-lifts local-transformer-expand/capture-lifts syntax-local-lift-values-expression syntax-local-lift-module-end-declaration syntax-local-lift-require syntax-local-lift-provide syntax-local-name syntax-local-context syntax-local-phase-level syntax-local-module-exports syntax-local-get-shadower syntax-local-certifier syntax-transforming? syntax-local-introduce make-syntax-introducer exn:fail:syntax make-syntax-delta-introducer syntax-local-make-delta-introducer syntax-case define-syntax syntax-rules with-syntax syntax-position syntax-line syntax-column ...

>>10
CL is full of bloat and legacy and it still can't manage to get macros right. You have swallowed Paul Graham's load and begged for more but he's already moved on to Arc (implemented in Racket by the way). Meanwhile you are stuck longing for more loads but lisp is dry and used up and has a headache, you've got nothing but a parched throat from screaming at the sky but no one is there to hear it.

>>12
Macro in LISP.

(defmacro aif (cond then else)
  `(let ((it ,cond))
     (if it ,then ,else)))

"Macro" in Scheme/Racket.

#lang racket
(require racket/stxparam)
 
(define-syntax-parameter it (lambda (stx) (raise-syntax-error 'anaphora "missed context" stx)))
 
(define-syntax-rule (aif cond then else)
  (let ([temp cond])
    (syntax-parameterize ([it (make-rename-transformer #`temp)])
                         (if temp then else))))

>>13
introducing identifiers in a macro that are used without being introduced in the code a programmer types
This has not been debunked as the sheer idiocy it really is. It should be easy to do things right and it should require being explicit to do things in a broken and retarded style to support legacy fags who cannot accept the present, nevermind the future.

>>14
Your definition of "right" is misdefined. "The right" should be "what programmer wants". I frequently want leaks to simplify interface. You want just shit.

(require mzlib/defmacro)

>>16
Although define-macro is non-hygienic, it is still restricted by Racket’s phase separation rules. This means that a macro cannot access run-time bindings, because it is executed in the syntax-expansion phase. Translating code that involves define-macro or defmacro from an implementation without this restriction usually implies separating macro related functionality into a begin-for-syntax or a module (that will be imported with require-for-syntax) and properly distinguishing syntactic information from run-time information.

>>15
It is not clear to me how your objection is justified by your code example. Can you elaborate?

>>18
>>11

The Symta guy is back.

>>17
This means that a macro cannot access run-time bindings
Ahh, I think this is probably your main problem. Interesting. I guess it is a good thing that CL exists for you, then.

>>21
You can't access run-time bindings in CL either. A macro function (either directly written and set or bound in the macro-function namespace or as generated by defmacro, which does the same) just takes in a list (represented as if one were to quote the code, or more precisely, the output given by the reader, which may include some objects generated at read-time) and an environment (generated by the compiler, contents is implementation-defined). The macro function is supposed to return the processed function body with the macro expanded, which is then passed to the compiler to further expand or compile. Nowhere here says anything about being able to change run-time bindings, as that obviously only exists at the run-time. The environment may contain lexically accessible bindings, but I don't think you can portably access them, you can however, check if local/lexical macros are bound within the scope of the macro being expanded as well as a few other things. However, if you don't mind writing slightly unportable code, I did write some de-facto portable (working across most major CL implementations I had my hands of, such as SBCL, ClozureCL, CLISP, ECL, some of the commercial ones, ...) macros which access all kinds of environment information, including lexically-bound variables. If you actually want to change values of the variables at runtime, that's not something a macro can or should be able to do (except maybe expand code that does it), and in that case CL is not for you, you should be using some ancient interpreted LISP which supports FEXPRs(not Common Lisp or Scheme, although technically it's not hard to implement them in CL at the cost of making slow-as-mollasses code for anything which doesn't have a fast interpreter), or some resurrected version of these ancient LISPs such as newLISP.

>>22
So, the famous ``accessing run-time bindings'' capability of CL macros so much loved by the ``in Lisp'' guy is just the ability to inspect the current environment's bindings at expansion time?
If so, Racket can too, with identifier-binding.

why aren't macros first-class?

>>24
Fexprs are hard/impossible to statically analyze.

Have you read your The Theory of Fexprs is Trivial today?

>>26

i've heard of it but haven't read it, only a summary of the argument. in fact i only learned what fexprs are yesterday, so it's weird to see them mentioned on /prog/

there seems to be a lot of debate on them on lambda the ultimate, eg
http://lambda-the-ultimate.org/node/3640

>>27
It will never go anywhere. Those who care about performance will always produce programs that can be reasonably compiled. Those who care about fexprs can write an interpreter any time they like.

This argument is like saying that I am unreasonably restricted by a law requiring people to drive on a particular side of the street. In practice, such freedoms make it extremely difficult to accomplish anything. In those instances where such regulation is prohibitive, we can eliminate them easily enough (e.g. parking lots).

fexprs are like turning lexical lisps into C++. In C++ you only think you know what a statement like x = a + b equals at a glance, until you have to look up the definitions of a and b, and then find out whether someone ``cleverly'' redefined + for such objects. This is unmaintainable garbage of the highest order.

You see that commented very plainly at the LtU thread:
(define (foo f)
  (f (+ 2 3)))
Seems like you know what this does, right? But, whoops! You can't! Because (+ 2 3) isn't 5 all the time. In defense, one poster says:
Have fexprs but just make sure it isn't too hard to write code in a style that makes it trivially apparent to a compiler that the hard / impossible cases won't show up.
And now we have all kinds of fucking garbage keywords and syntax as compiler hints.

No thank you, Bjarne.

In before someone posts a macro to shut someone up... oh wait that already happened.

>>28
garbage keywords and syntax as compiler hints
Welcome to Common Lisp.

>>23
Nope. Racket wont allow me to do:

(setq x 123)
(defmacro () (incf x))

Racket must be shit. I want the fucking counter!

>>31
(defmacro y () (incf x))
self fix

Are there a way to implement following custom-defun macro in Racket?

(defparameter *current-function* nil)

(defmacro custom-defun (name args &rest body &environment env)
  (let ((*current-function* name))
    `(defun ,name ,args
       ,@(mapcar (lambda (x) (sb-cltl2:macroexpand-all x env)) body))))

(defmacro this-function ()
  `',*current-function*)

(custom-defun yoba () (this-function))
(yoba)

god lisp is ugly as fuck

>>34
Thou shalt not take the name of the LORD thy God in vain.

>>35
s/God/LISP/ftfy

>>36
Lisp is shit.

>>35
Thou caca

>>28

i'm pretty ignorant about this stuff but isn't some sort of tracing JIT possible?

another q: is adding new definitions of + for certain types really that bad? (eg, a and b are Points containing x,y,z co-ords). is it better to always have a new name for that operation like (add-points a b) ?

Here, try this:

(defun symbol-count (obj lst)
  (if (null lst)
      nil
      (let ((i 0))
    (dolist (elm lst)
      (if (eql elm obj)
          (incf i))))))
Glad it helped!

>>28
This argument is like saying that I am unreasonably restricted by a law requiring people to drive on a particular side of the street.
You're. The Right Thing would be to give every driver his personal road.

>>28
I bet you're one of the people who always write things like (matrix-add A B) instead of (+ A B). I hope you die in a fucking fire you cock sucking piece of shit.

>>28
You can define generic functions in CL which would let you do something like that. They'd still be much faster than fexpr's which would only work (at a reasonable speed) in an interpreter.