"C-like" syntax for Lisp in less than 100 lines of code
in [Lisp]
|
From: Tim Bradshaw on 24 Apr 2010 13:02 On 2010-04-24 10:47:36 +0100, Frank Buss said: > Python has some list processing primitives: But aren't its lists actually dynamically-resized arrays rather than linked lists? Those are very different things.
From: Jorge Gajon on 24 Apr 2010 13:36 On 2010-04-23, Teemu Likonen <tlikonen(a)iki.fi> wrote: > * 2010-04-23 15:13 (UTC), Jorge Gajon wrote: > >> /"But you said Emacs is more powerful."/ >> >> Yes but I don't need a tetris game, or GNUS, or a web browser, or an >> ultra super duper grand unified debugger (as cool as it is.) > > I believe this is just "psychological bloat". Those parts of Emacs you > don't use are only *.elc files on your hard disks. They are loaded only > when you actually use them. Bot Vim and Emacs are very light-weight > applications compared to other applications. What I'm actually afraid is getting lured into "this new plugin", and then this "other cool plugin", oh! and there's this other one!. It's like reading a wikipedia article and then you read other related article, and then another, and another, and before you realize it, you have 20 tabs open with articles to read. Dangerous stuff. But yes, maybe it's just in mind.
From: Jorge Gajon on 24 Apr 2010 13:46 On 2010-04-23, Peter Keller <psilord(a)merlin.cs.wisc.edu> wrote: > Jorge Gajon <gajon(a)gajon.org> wrote: >> At first I found the exact same bugs you mention, but with the >> modifications that I linked to in the previous message they are fixed. > > Oh, I have the maintainer's email address, maybe I'll forward to him your > link so he can see what's up. > >> Well, one thing is drinking the kool-aid, and other is using what's >> best. I believe Vim's editing model is a big deal to just let it go. > > I thought the same way, but in the end, I realized that both tools > allow me to "do the same things" with the text, so in essence the only > difference was what I was actually typing. > > After a while, I was able to remap quite effectively the higher order text > manipulations my brain wanted to do into different concrete finger movements. > > I thought it'd be horrible to do, and for the first 3 weeks, it was. :) > >> And one thing that I *must* really be able to use is C-X C-N and C-X C-P >> in insert mode. > > Turns out that M-/ is a good enough completion for me that I'm perfectly > happy with it. There are various method of tab completion I haven't all > figured out, but they can provide you with the choices and whatnot. > > As for tags, M-. (if I recall) does something intelligent. SLIME itself > has some acceptable methods to go to a caller or a callee of a function > or identify other entities and their definitions. I've only used it in Lisp > and it worked well for me. > >> Anyway, I have not been able to spend more time with Emacs recently, but >> it is definitely in my to-do list. The problem is that there's not >> enough time available, which is also my concern on walking down this >> path. > > Eh, I say simply start writing code in it and only figure out the things > you absolutely need to figure out because it prevents you from writing > code. 99% of the time whatever I googled had like 4 pages devoted to > how to make emacs do it. Everything else can be put off. :) > > I was annoyed that I had to learn another tool, but my brain surprised > me and remapped everything. I bashed emacs with a stick when I just couldn't > change my behavior. It worked out. > Peter, thank you for your comments, I definitely have to spend more time with trying Emacs. Although SLIME is not indispensable for Common Lisp programming, it sure is a significant advantage. Best regards.
From: Jorge Gajon on 24 Apr 2010 13:53 On 2010-04-24, Pascal J. Bourguignon <pjb(a)informatimago.com> wrote: > Jorge Gajon <gajon(a)gajon.org> writes: > >> On 2010-04-22, Peter Keller <psilord(a)merlin.cs.wisc.edu> wrote: >>> I am a staunch vim user, to say the least. However, after patches I >>> was giving back to various lisp projects were rejected with the reason >>> "format it in SLIME or else". I bit the bullet and simply learned emacs >>> for my Lisp IDE. I'm happy I did this. >>> >> >> Hi Peter, >> >> I'm an avid Vim user as well, and I've been using "Limp" with a few >> modifications�. I've been playing a little bit with Emacs and SLIME, and >> I can clearly see that the Emacs platform is much more powerful and that >> there's nothing like SLIME available to VIM. >> >> However, I've been hesitant to completely immerse myself into Emacs >> mainly because I'm afraid that I will spend endless hours learning and >> customizing it, without gaining a significant advantage over Vim. > > You could. But you wouldn't have to, to benefit from emacs lisp. > Really, I usually don't spend any time on emacs customization, in the > course of a project. On the other hand, I may spend a few minutes to > write project specific emacs lisp functions, to help editing or > generating project specific stuff. > Pascal, when you say "...help editing or generating project specific stuff", do you mean text templates that are expanded in place and you fill the blanks, or do you mean something similar to keyboard macros to avoid repetition, or a combination of them. Or (more exciting), you mean something like CL macros where you call it with some arguments and depending on the arguments it will 'expand' into different source code. Thank you.
From: Pascal J. Bourguignon on 24 Apr 2010 14:23
Jorge Gajon <gajon(a)gajon.org> writes: > On 2010-04-24, Pascal J. Bourguignon <pjb(a)informatimago.com> wrote: >> Jorge Gajon <gajon(a)gajon.org> writes: >> >>> On 2010-04-22, Peter Keller <psilord(a)merlin.cs.wisc.edu> wrote: >>>> I am a staunch vim user, to say the least. However, after patches I >>>> was giving back to various lisp projects were rejected with the reason >>>> "format it in SLIME or else". I bit the bullet and simply learned emacs >>>> for my Lisp IDE. I'm happy I did this. >>>> >>> >>> Hi Peter, >>> >>> I'm an avid Vim user as well, and I've been using "Limp" with a few >>> modifications�. I've been playing a little bit with Emacs and SLIME, and >>> I can clearly see that the Emacs platform is much more powerful and that >>> there's nothing like SLIME available to VIM. >>> >>> However, I've been hesitant to completely immerse myself into Emacs >>> mainly because I'm afraid that I will spend endless hours learning and >>> customizing it, without gaining a significant advantage over Vim. >> >> You could. But you wouldn't have to, to benefit from emacs lisp. >> Really, I usually don't spend any time on emacs customization, in the >> course of a project. On the other hand, I may spend a few minutes to >> write project specific emacs lisp functions, to help editing or >> generating project specific stuff. >> > > Pascal, when you say "...help editing or generating project specific > stuff", do you mean text templates that are expanded in place and you > fill the blanks, or do you mean something similar to keyboard macros to > avoid repetition, or a combination of them. The former. I don't use keyboard macros, since I'm totally at ease with emacs lisp programming, I do what users would do with keyboard macros writing emacs functions. Here are some typical example. - The first would be a command to set different faces to different log level in an application specific log file (which application issued a lot of logs in debugging mode, so that it was really important to be able to distinguish them by color to make sense of them). (defun xxxxxx-log-fontify-buffer () (interactive) (remove-all-properties) (dolines (lstart lend) (goto-char lstart) (when (looking-at "\\(DEBUG\\|INFO\\|NOTICE\\|WARNING\\|ERROR\\) ") (let* ((level (match-string 1)) (face (cond ((string= level "DEBUG") 'xxxxxx-message-level-debug) ((string= level "INFO") 'xxxxxx-message-level-info) ((string= level "NOTICE") 'xxxxxx-message-level-notice) ((string= level "WARNING") 'xxxxxx-message-level-warning) ((string= level "ERROR") 'xxxxxx-message-level-error)))) ;; (message "%S %S %S %S" level face lstart lend) (when face (facemenu-set-face face lstart lend)))))) (This could have been done with normal font-lock keywords, but it was too slow given the size of the log files). Also there's a function that set as an emacs attribute attached to each log line, a log object, identifying the log message in the sources (since there was no identification of the log message other than its pattern, not to affraid the users). So that I could easily jump from the log line to the corresponding source line. - a function that would take a C++ message sending ("member function call"), and transform it into sending a message to a scheduler object with a boost::bind wrapping the original message send. (Transforming the original message send into an asynchronous one). Of course, such a feature would be implemented at the programming language level (ie. with lisp macros), instead of inlining it in the source, but we can use emacs lisp function to "macro expand" the target language. - a funnier set of emacs commands were used to switch between two representations of a function definition in a language where there was no function definition available. Only eval(string) was availble, so that I defined a syntax to define a function, and the function parameters were passed thru global variables like in BASIC, and the function body was stored into a string named by the function. The commands switched between the two forms: function f(input a,inout b,output c){ b=b+1; c=a*2; } <-> a=null; // input of f b=null; // inout of f c=null; // output of f f="b=b+1;c=a*2"; to try to recover some mental sanity... I didn't write the switch for function calls, (ie between f(i,j,k) and a=i;b=j;eval(f);k=c;) but it could have been done with some more syntactic analysis of this dumb language. - finally, one can also quite easily interface with underlying programs, such as debuggers, writing emacs commands to drive the debugger or other programs with a single key. For example, I have: (defun clisp-debug-keys () "Binds locally some keys to send clisp debugger commands to the inferior-lisp <f5> step into <f6> next <f7> step over <f8> continue " (interactive) (macrolet ((cmd (string) `(lambda () (interactive) (comint-send-string (inferior-lisp-proc) ,(format "%s\n" string))))) (local-set-key (kbd "<f5>") (cmd ":s")) (local-set-key (kbd "<f6>") (cmd ":n")) (local-set-key (kbd "<f7>") (cmd ":o")) (local-set-key (kbd "<f8>") (cmd ":c")))) (defun sbcl-debug-keys () "Binds locally some keys to send clisp debugger commands to the inferior-lisp <f5> step into <f6> next <f7> step over <f8> continue " (interactive) (macrolet ((cmd (string) `(lambda () (interactive) (comint-send-string (inferior-lisp-proc) ,(format "%s\n" string))))) (local-set-key (kbd "<f5>") (cmd "step")) (local-set-key (kbd "<f6>") (cmd "next")) (local-set-key (kbd "<f7>") (cmd "over")) (local-set-key (kbd "<f8>") (cmd "out")))) (defun allegro-debug-keys () "Binds locally some keys to send allegro debugger commands to the inferior-lisp <f5> step into <f7> step over <f8> continue " (interactive) (macrolet ((cmd (string) `(lambda () (interactive) (comint-send-string (inferior-lisp-proc) ,(format "%s\n" string))))) (local-set-key (kbd "<f5>") (cmd ":scont 1")) ;; (local-set-key (kbd "<f6>") (cmd )) (local-set-key (kbd "<f7>") (cmd ":sover")) (local-set-key (kbd "<f8>") (cmd ":continue")))) In this specific case of Common Lisp, of course SLIME does it for you already. When I started programming in Lisp, SLIME didn't exist yet. > Or (more exciting), you mean something like CL macros where you call > it with some arguments and depending on the arguments it will 'expand' > into different source code. Also this. For example, you may find in my sources in inferior programming languages, emacs lisp code in comments, that will generate the following inferior language code. Typically for repeatitive stuff. For example: /* (insert-fields '(visible color width height)) */ private $visible=null; public function setVisible($aValue){ $this->visible=$aValue; return($this); } public function getVisible(){ return($this->visible); } private $color=null; public function setColor($aValue){ $this->color=$aValue; return($this); } public function getColor(){ return($this->color); } private $width=null; public function setWidth($aValue){ $this->width=$aValue; return($this); } public function getWidth(){ return($this->width); } private $height=null; public function setHeight($aValue){ $this->height=$aValue; return($this); } public function getHeight(){ return($this->height); } But I may also use the same technique to generate more complex code, for example optimized decision trees (embedded ifs). Notice there's an emacs lisp pre-processor: http://www.xcf.berkeley.edu/~ali/elpp/cgen.el http://www.xcf.berkeley.edu/~ali/elpp/elpp.el http://www.xcf.berkeley.edu/~ali/elpp/elppc.el Basically it allows you to insert elisp in your C code and to autogenerate C code from elisp s-expressions. (I guess you could apply it to other programming languages too). But then your sources wouldn't be C sources, but C+emacs lisp, so it would be harder to commit them in your employer's repositories. Commiting comments with emacs lisp code is already hard enough... -- __Pascal Bourguignon__ |