What is the best way to navigate #ifdef and #endif in C program
in [Lisp]
|
Prev: +++ NFL Jerseys On Sale at www.ajerseys.com
Next: ===Christian Louboutin - www.vipchristianlouboutin.com
From: Thomas A. Russ on 4 Aug 2010 14:30 Elena <egarrulo(a)gmail.com> writes: > On Aug 4, 10:27��am, p...(a)informatimago.com (Pascal J. Bourguignon) > wrote: > > This is the reason why there is no point asking whether there is a > > feature X in CL. ��You can always add any feature to the language, > > thanks to its macros or reader macros, and metalinguistic abilities in > > general. > > Can macros really add features or can they just add syntactic sugar? A > custom "case" statement is just syntactic sugar, tail call > optimization is a feature. Sure, by your example of a feature, macros can be written which do that. Tail call optimization is a transformation of a program. Lisp macros in their general form perform source code transformations (i.e., program transformations), so you could write a macro that can rewrite a tail-recursive program into an equivalent iterative program. At a more fundamental philosophical level it is harder to answer, since it begs the question of when some piece of functionality becomes a feature rather than syntactic sugar. So, would you consider the LOOP macro as implementing a feature or would that be syntactic sugar. What about CLOS? Ultimately all computer programs are reduced to a sequence of machine instructions. So one could consider the entire superstructure of higher level programming languages "syntactic sugar" on top of that underlying set of machine instructions.... -- Thomas A. Russ, USC/Information Sciences Institute
From: Rob Warnock on 4 Aug 2010 20:18 josephoswald+gg(a)gmail.com <josephoswald(a)gmail.com> wrote: +--------------- | Another way to "#ifdef out" out a single form is | #+(or) or #-(and) | But these are trickier to work with. +--------------- My preference [following a long-ago hint from Erik Naggum] is to always use only the AND flavors, because then the "+" and "-" mean "Yes, read this" and "No, ignore this", respectively: > (list #+(and) (list "This gets read" "and so does this.") #-(and) (list "This is ignored" "also ignored")) (("This gets read" "and so does this.")) > But YMMV. Others prefer using only the OR flavors, with "+" meaning "Ignore this" and "-" meaning "Don't ignore". Whichever style you prefer, do only use *one* flavor in your code, for two reasons: - It's less confusing to your readers. Yes, they might have to figure out which style you're using once, at the beginning, but they won't have to work to decode each and every use! - Using only one flavor, it's easy to switch back and forth between "enabled" and "disabled" by changing only one character. -Rob ----- Rob Warnock <rpw3(a)rpw3.org> 627 26th Avenue <URL:http://rpw3.org/> San Mateo, CA 94403 (650)572-2607
From: Emmy Noether on 5 Aug 2010 14:00 On Aug 3, 9:45 pm, Fren Zeee <frenz...(a)gmail.com> wrote: > On Aug 2, 5:31 pm, "Daniel (Youngwhan)" <breadn...(a)gmail.com> wrote: > > > > > Hi, > > > If there is curly brace, it is easy to navigate between them by M-C-f > > and M-C-b in c-mode. > > > However, I cannot find a way to navigate in like curly brace when it > > comes to #ifdef, #else, and #endif. > > > For example, if there is a code like this: > > > #ifdef A_DEFINED > > (...100 lines) > > #else > > (... 500 lines) > > #endif > > > , is there a easy way to move the cursor from #endif to #ifdef or > > #else and vice versa? > > > Daniel > > You might get better luck posting in a C group also. > > I use #ifdef ... #endif often also to comment out blocks of code > during debugging. > > My question to CLISP/ELISP/scheme people is > > If there is a wrapper do nothing type function in elisp/clisp/scheme > which can have the same effect as commenting out. > > This is because I dont like to do comment-region/uncomment-region in > emacs. > > These three lispy languages dont seem to have comment block construct > like C ie /* and */ I would remove a function block by wrapping in one of man conditionals like (cond (f (comment-out-block)) ) the short circuit evaluation would not even process it. I plan to test this idea in the future.
From: Elena on 5 Aug 2010 15:04 On 4 Ago, 17:09, Peter Keller <psil...(a)cs.wisc.edu> wrote: > Specifically:http://letoverlambda.com/index.cl/guest/chap5.html#sec_4 > > Would show you how to write a macro such that it adds Scheme's tail call > optimized "named let" into Common Lisp. This goes beyond the concept > of syntactic sugar and enters the domain of pure code transformation. Indeed, code transformation is what sets CL's macros apart. However, TCO is much more than that. Read here: http://stackoverflow.com/questions/2181852/tail-call-elimination-in-clojure However, TCO could also just not be possible in CL because of its design: http://www.cliki.net/Tail%20Recursion
From: Elena on 5 Aug 2010 15:08
Moreover, full escaping continuations (a la Scheme) are likely to be out of reach. And that can make sense, too. I once asked on comp.lang.scheme how to guarantee release of resources and basically Schemers answered you can't guarantee anything like that when continuation come into the picture. |