User perception on backward compatibility

Hello! I think the next big task will be to list and try to reduce incompatibilities compared to 1.8. For the record, here’s what I found in GNU Dico; it’s interesting to see how its maintainer feels about backward compatibility in Guile: http://mail.gnu.org.ua/archives/html/public/bug-dico/th

Re: User perception on backward compatibility

() l...@gnu.org (Ludovic Courtès) () Thu, 21 Jan 2010 11:54:51 +0100 I think the next big task will be to list and try to reduce incompatibilities compared to 1.8. Yes, please. At the moment, i would ask you to look at the guile-user message w/ subject "(define ((f a) b) ...)". thi

Re: User perception on backward compatibility

Hi, Thien-Thi Nguyen writes: > At the moment, i would ask you to look at the guile-user message > w/ subject "(define ((f a) b) ...)". I didn’t reply on the grounds that Andy may have his views on this. :-) Thanks, Ludo’.

Re: User perception on backward compatibility

> From: Ludovic Courtès > > Hello! > > I think the next big task will be to list and try to reduce > incompatibilities compared to 1.8. > > For the record, here’s what I found in GNU Dico; it’s interesting to see > how its maintainer feels about backward compatibility in Guile: > > http://m

Re: User perception on backward compatibility

Hi Mike, Mike Gran writes: > Guile's API has always fairly incompatibly from revision to > revision. Each rev always requires a significant rewrite of the glue > code in Guile-using projects. s/revision/major version/. Fortunately, major versions are pretty rare, but I get your point, of cou

Re: User perception on backward compatibility

Mike Gran ha escrit: > Maybe we need a gnulib-like project for guile ;-) Oh, no. That'd be an overkill, really :^) But retaining the old interfaces for at least a couple of revisions, since introduction of the new ones, will be very helpful (the current practice of issuing deprecation warnings i

Re: User perception on backward compatibility

Thien-Thi Nguyen: I think the next big task will be to list and try to reduce incompatibilities compared to 1.8. Yes, please. At the moment, i would ask you to look at the guile-user message w/ subject "(define ((f a) b) ...)". I agree about this. IMO it's very elegant, and also (proba

Re: User perception on backward compatibility

l...@gnu.org (Ludovic Courtès) writes: > Hi, > > Thien-Thi Nguyen writes: > >> At the moment, i would ask you to look at the guile-user message >> w/ subject "(define ((f a) b) ...)". > > I didn’t reply on the grounds that Andy may have his views on this. :-) I think it just needs a bit of defi

Re: rfc: (add-hook 'before-save-hook 'delete-trailing-whitespace)

l...@gnu.org (Ludovic Courtès) writes: > (using ‘git blame’ becomes almost useless). Wouldn't `git blame -w' solve that problem? Neil

Re: rfc: (add-hook 'before-save-hook 'delete-trailing-whitespace)

Hi, Neil Jerram writes: > l...@gnu.org (Ludovic Courtès) writes: > >> (using ‘git blame’ becomes almost useless). > > Wouldn't `git blame -w' solve that problem? Hmm, possibly, yes (I didn’t know this option). Thanks, Ludo’.

Re: rfc: (add-hook 'before-save-hook 'delete-trailing-whitespace)

Thien-Thi Nguyen writes: > The above form lives in my Emacs init flow, causing trailing whitespace to be > deleted on `save-buffer' (C-x C-s). For many projects (but not Guile) this > DTRT, because trailing whitespace is not tolerated. Jim Meyering gives a > nice rationale in