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

Quick Compiler Question

Name: Anonymous 2010-02-27 9:06

So I was thinking about C programs a short while ago, and a problem occurred to me.

Let's say that I have a function in which, say, we define a variable. It might look something like this:

int dicks (int cocks)
{
    int wangs;
    /* Do stuff to wangs and cocks here */
    return wangs;
}


Looking at int wangs; it seems that the compiler translates that line into "allocate space for an integer and return a pointer to it." If this is a case, is the compiler setting aside space for a new integer every time I run the function, or does it optimize by assuming that I'm only going to have one instance of it and just set aside space for a single int?

Whatever the answer to that previous question is, how would the compiler handle a recursive function? How would


Never mind, I'm an idiot. I forgot about registers and the stack for a second. I revoke my previous questions.

NEW QUESTION: What is the point of tail-call optimization? If all it does is convert recursive functions into iterative ones, why not just program them that way in the first place?

Name: Anonymous 2010-02-27 12:55

>>11
I think they should add define-syntax-rule to r7rs. For small examples, like yours, they make the code much less crufty.

>>13
I'd say that syntax-case would suffice for your definition, although it returns a "syntax object" instead of a plain expression; the only real difference is some additional lexical information. If you are wanting something more CL-like, perhaps Syntactic Closures or Explicit Renaming macros?

syntactic-closures:
(define-syntax swap!
  (sc-macro-transformer
   (lambda (form environment)
     (let ((a (close-syntax (cadr form) environment))
           (b (close-syntax (caddr form) environment)))
       `(let ((temp ,a))
          (set! ,a ,b)
          (set! ,b temp))))))


explicit renaming:
(define-syntax swap!
  (er-macro-transformer
   (lambda (form rename compare)
     (let ((a (cadr form))
           (b (caddr form))
           (temp (rename 'temp)))
       `(,(rename 'let) ((,temp ,a))
            (,(rename 'set!) ,a ,b)
            (,(rename 'set!) ,b ,temp))))))

Neither of these are standardised, and unlikely to be unless they change the mechanism for defining macro transformers.

this is a non-problem in Lisp-n's
I'll need to look at that paper, but I'm not convinced that there are no problems with low-level macros just because you have n namespaces. There is still the issue of shadowing builtins (you can in CL, right?), and other functions and the CL solution seems to be "don't do it, bad little lisper".

btw, what is the equivalent of make-variable-transformer in CL? It allows for identifers that may or may not be in the CAR position to be macros.
Example:
(define-syntax define-list-macro
   (syntax-rules ()
     [(_ name value)
      (begin
        (define tmp value)
        (define-syntax name
          (make-variable-transformer
            (lambda (stx)
              (syntax-case stx (len set!)
                [(x len)             #'(length tmp)]
                [(set! x v)          #'(set! tmp v)]
                [(x e* (... ...))    #'(tmp e* (... ...))]
                [x (identifier? #'x) #'tmp])))))]))

(define-list-macro foo (list 1 2 3))

(printf "~s ~s\n" foo (foo len)) ;=> (1 2 3) 3

(set! foo (list 2 3))

(printf "~s ~s\n" foo (foo len)) ;=> (2 3) 2

(foo 1 2 3) ;=> &assertion in apply: (2 3) not a procedure.



Example shamelessly taken from http://groups.google.com/group/comp.lang.scheme/browse_thread/thread/96b07d431f1a66de/fb7f559e2f7b5243?#fb7f559e2f7b5243

Newer Posts
Don't change these.
Name: Email:
Entire Thread Thread List