Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon. Entire thread

newLISP the true champion of homoiconicity

Name: Anonymous 2012-11-10 10:11

Can your Lisp do this, /prog/?

(define (plus-minus a b)
  (begin
    (setf (nth '(1 2 0) plus-minus) (if (= (nth '(1 2 0) plus-minus) -) + -))
    (+ a b)))

(plus-minus 10 2)
8
(plus-minus 10 2)
12

newLISP treats code literally as data unlike Common Lisp or Scheme.

Name: Anonymous 2012-11-12 7:28

Macros are a poor man's Fexprs.

http://en.wikipedia.org/wiki/Fexpr#Mainstream_use_and_deprecation

At the 1980 Conference on Lisp and Functional Programming, Kent Pitman presented a paper "Special Forms in Lisp" in which he discussed the advantages and disadvantages of macros and fexprs, and ultimately condemned fexprs. His central objection was that, in a Lisp dialect that allows fexprs, static analysis cannot determine generally whether an operator represents an ordinary function or a fexpr — therefore, static analysis cannot determine whether or not the operands will be evaluated. In particular, the compiler cannot tell whether a subexpression can be safely optimized, since the subexpression might be treated as unevaluated data at run-time.

tl;dr version:

Le jew PITMAN condemns fexprs because he cannot his way into static analysis. But being Lisp is all about direct manipulation of the AST, who the fuck cares about Le static analysis.

Name: Anonymous 2012-11-12 7:43

>>41
Lispers have historically strived to make their Jewish Kabbalah magickz both efficient and versatile, and both the intent and the knowledge required to do so is what has set them apart from the scripting languages ``BDFL''s who designed pretty languages with shit semantics and performance.

Name: >>40 2012-11-12 16:17

My quest for macro satori has finally made me insane.  I no longer distinguish between reality and imagination, or between compile-time and run-time.

Name: Anonymous 2012-11-12 19:44

>>42
Should we believe that, le goog programmateurs will come with über-engineered v8.

Name: Anonymous 2012-11-12 22:50

>>43
doing something at compile time is just an optimization of doing it at run time. Both yield the same behavior so they cannot be distinguished.

Name: 2012-11-13 3:35

Name: Anonymous 2012-11-13 11:48

>>45
doing something at compile time is just an optimization of doing it at run time. Both yield the same behavior so they cannot be distinguished.
Please give me a reference with lots and lots of Lisp macro examples with as many interactions between compile- and run-time as possible.

Name: Anonymous 2012-11-13 12:24

>>47

Well, I've been thinking about your dilemma, so I've put together a test.


mac.lisp:
(defmacro confusing (a)
  (print (list "is this compile or run time? " a))
  a)


(defun client-fun (a b c)
  (+ (confusing a) (confusing b) (confusing c)))



[1]> (load 'mac.lisp)
;; Loading file mac.lisp ...
("is this compile or run time? " A)
("is this compile or run time? " B)
("is this compile or run time? " C)
;; Loaded file mac.lisp
T
[2]> (client-fun 1 2 3)
6
[3]>



Looks like compile time in this case. If the macro expansion function had no side effects, then the compile time macro expansion could be seen as constant folding, since all macros are invoked on constant ast literals typed into the program. But in this case the macro causes a side effect, so its evaluation time is significant. When this will happen really depends on the lisp that you are using. First class macro expansions must happen at run time.

Name: Anonymous 2012-11-13 13:02

>>1
Dynamic scoping is shit.
Lexical scoping is superior.

Name: Anonymous 2012-11-13 13:14

if it's not sweet.js, it's wrong

Name: Anonymous 2012-11-13 13:43

/polecat kebabs/

Name: Anonymous 2012-11-13 13:56

>>49
You can implement lexical scoping in dynamically scoped Lisp. The reverse, however, is not possible.

Name: Anonymous 2012-11-13 14:00

>>52
Dynamically scoped lisp (or, for that matter, any language) sucks dicks at optimization.

Name: Anonymous 2012-11-13 14:14

>>55
nice dubs bro

Name: Anonymous 2012-11-13 14:21

>>53
Depends on the implementation. And what ``optimization'' are we talking about here?

Name: Anonymous 2012-11-13 15:03

>>52
Implement lexical-lambda and lexical-let, then.

Name: Anonymous 2012-11-13 23:21

Name: Anonymous 2012-11-14 0:19

>>1-57
lambda fucking nerdulus.

Name: Anonymous 2012-11-14 5:05

>>56
lexical-let can be implemented using lexical-lambda.
lexical-lambda can be implemented as a tuple together with a reference to the parent activation frame in which the lambda is instantiated.

dynamic scope can be implemented as a hash table of stacks or a stack of hash tables.

Name: Anonymous 2012-11-14 9:14

>>59
reference to the parent activation frame in which the lambda is instantiated.
And how are you going to get that?

Name: Anonymous 2012-11-14 9:55

>>60
he just told you how.. isn't it obvious?

Name: Anonymous 2012-11-14 13:47

>>61
That needs interpreter/compiler hacks, the same way dynamic-scoping-in-lexical-scoped-language needs hacks.

Name: Anonymous 2012-11-15 2:23

>>62
It's lexical scope is more predicable than dynamic scoping. The relationship to the parents is fixed at compile time because the function definitions cannot move around. They have a nested grouping that is fixed and defined for the source file. With dynamic scoping, the parent relationship is dynamic and determined by the state of the function all stack. So the program must be prepared for many different cases when looking up the value of a variable in a parent frame.
Newer Posts
Don't change these.
Name: Email:
Entire Thread Thread List
All trademarks and copyrights on this site are owned by their respective parties. All comments and posts are the responsibility of their own posters.
- Tinychan + 2ch Mode -