August 1998 - XEmacs-Beta - XEmacs Mailing List Archives

Re: Macros: Scheme vs Common Lisp 26 years, 3 months

Michael Sperber

>>>>> "Holger" == Holger Schauer <schauer(a)coling.uni-freiburg.de> writes: >>>>> "MS" == Michael Sperber schrieb am 22 Aug 1998 16:12:54 +0200: MS> (define-syntax foo (syntax-rules () ((foo) bar))) MS> BAR always refers to the binding of BAR lexically visible in the MS> macro definition. Holger> Hmm. Holger> (setq bar 23) Holger> (defmacro foo () bar) Holger> (foo) => 23 Holger> (let ((bar 42)) (foo)) => 23 Holger> (setq bar 57) Holger> (foo) => 23 Holger> (let ((bar 42)) (foo)) => 57 Holger> So, what do you want ? That foo always refers to 23 regardless whether Holger> I have changed the value of bar in the mean time ? No. I think the problem is that many C and Common Lisp programmers confuse the concepts of "binding" and "assignment." Binding a value to a name means creating a new association between the name and the value. Assigning a value to a name means changing the value an already-existing binding. These are two very different things. Sadly, in C it's possible to create bindings without values, and in Common Lisp, assignment (via setq) may create the binding if it doesn't exist yet. Thus, in your example, (setq bar 23) [if done in fresh CL session] creates a binding which associates 23 with BAR, and: (setq bar 57) modifies the binding created previously. Your example evaluates BAR at macro-definition time which surely is not what you intended. (I.e., (foo) expands to 23, regardless.) What I want is: (setq 23) (defmacro foo () 'bar) (foo) => 23 (let ((bar 42)) (foo)) => 23 [note: CL actually yields 42] (setq bar 57) (foo) => 57 (let ((bar 42)) (foo)) => 57 [note: CL actually yields 42] Note that this is exactly what actually *would* happen if you wrote: (defun foo () bar) instead of the defmacro. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

2 participants
1 comments

[Richard Stallman <rms@santafe.edu>] Emacs 20.3 26 years, 3 months

William M. Perry

Anybody got details on the 'new redisplay code' he's talking about? -Bill P.

2 participants
1 comments

Re: Macros: Scheme vs Common Lisp 26 years, 3 months

Holger Schauer

>>>>"MS" == Michael Sperber schrieb am 24 Aug 1998 11:14:43 +0200: MS> Thus, in your example, MS> (setq bar 23) MS> [if done in fresh CL session] MS> creates a binding which associates 23 with BAR, and: MS> (setq bar 57) MS> modifies the binding created previously. I knew that already, thanks ;-) MS> Your example evaluates BAR at macro-definition time which surely MS> is not what you intended. (I.e., (foo) expands to 23, MS> regardless.) What I want is: MS> (setq 23) MS> (defmacro foo () 'bar) MS> (foo) => 23 MS> (let ((bar 42)) (foo)) => 23 [note: CL actually yields 42] MS> (setq bar 57) MS> (foo) => 57 MS> (let ((bar 42)) (foo)) => 57 [note: CL actually yields 42] But exactly this behaviour is what you get when you use (defmacro foo () bar) instead of (defmacro foo () 'bar): USER(2): (setq bar 23) 23 USER(9): (defmacro foo () bar) FOO USER(10): (foo) 23 USER(11): (let ((bar 42)) (foo)) 23 USER(12): (setq bar 57) 57 USER(13): (let ((bar 42)) (foo)) 57 USER(14): MS> Note that this is exactly what actually *would* happen if you MS> wrote: (defun foo () bar) instead of the defmacro. Yes. And that's why I was so surprised that you would want it otherwise (which I now see you don't). My point: yes, one can do what you want to do, also with Common Lisp. Your point (to which I agree): things can get somewhat hairy underway. Holger -- --- http://www.coling.uni-freiburg.de/~schauer --- ">grep schauer passwd >schauer:x:1075:1075:Holger Schauer, 2790:/home/schauer:/usr/bin/xemacs" "Das ist nur eine Shell. Bedenklich waere, wenn Dein LILO /vmunix.el bootet." -- Kristian und Holger in de.comp.os.linux.misc

1 participants
0 comments

initial frame display problem with beta54 on NT 26 years, 3 months

John Morey

I did a native build of beta54 on NT-4.0. I sometimes have a display problem with the toolbar in the initial frame. It is easy for me to reproduce because my initial XEmacs frames always come up in the same place. How to reproduce: 1) start xemacs 2) start the task manager 3) set the task manager to "always on top" 4) move the task manager window so that the upper left hand corner covers the text "Print" in the toolbar print button. Resize the task manager window to the right so that it extends off the edge of the XEmacs frame. 5) kill the current xemacs and restart 6) most of the toolbar area on the left will display what ever is behind it on the desktop and ther will be about a button and one half ("open" and 1/2 of "dired") displayed on the right hand side of the toolbar. -- John Morey

1 participants
0 comments

Re: X-error in get_mouse_position 26 years, 3 months

Gunnar Evermann

Didier Verna <verna(a)inf.enst.fr> writes: > Gunnar Evermann <Gunnar.Evermann(a)nats.informatik.uni-hamburg.de> writes: > > > but, how??? x_any_window_to_frame doesn't cut it. In a vanilla XEmacs, > > if the pointer is in the *scratch* buffer I need to traverse some > > steps down the Window hierarchy before I get the frame from > > x_any_window_to_frame. For the child_window returned by XQueryPointer > > I only get NIL :-( > > I don't understand this. OK, I'll try again: First, I give *my* interpretation of how x_get_mouse_position() works (this could be totally wrong): 1) call XQueryPointer to find out over which Window (if any) the pointer currently is. ('child_window') 2) call XTranslateCoordinates() with this Window as the destination window. 'If the coordinates are contained in a mapped child of dest_w, that child is returned to child_window.' (quote from man page) 3) repeat 2) until it returns None. 4) call x_any_window_to_frame with the previous window and store the frame in an Lisp_Object. 5) get the coordinates from XTranslateCoordinates() with the frame's text widget as the destination window. The problem is that XQueryPointer can return a window that results in a Bad Window on the first call to 2). Jan suggested to move the call to x_any_window_to_frame between 1) and 2). This sounds reasonable but doesn't work. In all my tests x_any_window_to_frame(d, child_window) returns NIL at this point. If I call x_any_window_to_frame after each iteration, I only get the frame after at least two iterations of the loop. I used a freshly started XEmacs (with toolbar and scrollbars) displaying only the *scratch* buffer. The Pointer was over the text in that buffer. The above loop did 5 iterations in this case. > Another solution to this problem is to enclose the call to > XQueryPointer in an ephemeral error handler that would basically do nothing. I don't understand this :-) more precisely I have no idea how to do that. (maybe using this error_expected stuff?). Please note that the error happens in a call to XTranslateCoordinates(). Gunnar (who should really read those damned X manuals...)

1 participants
0 comments

sound-load-alist references nonexistent files 26 years, 3 months

giacomo boffi

(insert (pp sound-load-alist)) ((load-sound-file "drum-beep" 'drum) (load-sound-file "quiet-beep" 'quiet) (load-sound-file "bass-snap" 'bass 80) (load-sound-file "whip" 'whip 70) (load-sound-file "cuckoo" 'cuckoo) (load-sound-file "yeep" 'yeep) (load-sound-file "hype" 'hype 100)) most of these files are not in default-sound-directory, i.e., /usr/local/lib/xemacs-21.2-b1/packages/etc/sounds/

1 participants
0 comments

Re: Macros: Scheme vs Common Lisp 26 years, 3 months

Holger Schauer

>>>>"MS" == Michael Sperber schrieb am 22 Aug 1998 16:12:54 +0200: MS> (define-syntax foo (syntax-rules () ((foo) bar))) MS> BAR always refers to the binding of BAR lexically visible in the MS> macro definition. Hmm. (setq bar 23) (defmacro foo () bar) (foo) => 23 (let ((bar 42)) (foo)) => 23 (setq bar 57) (foo) => 23 (let ((bar 42)) (foo)) => 57 So, what do you want ? That foo always refers to 23 regardless whether I have changed the value of bar in the mean time ? This seems counter-intuitive to me. It also means that there would be a difference between the use of macros and functions (i.e. using functions instead of macros in the above example yields the same behaviour wrt. to the variable bindings).To me that would mean that one would save some trouble somewhere but introduce trouble at another place. But maybe your experience tells you that solving the first problem (i.e. using the "correct" lexical bindings) is worth the costs. YMMV as they say. Holger -- --- http://www.coling.uni-freiburg.de/~schauer --- ">grep schauer passwd >schauer:x:1075:1075:Holger Schauer, 2790:/home/schauer:/usr/bin/xemacs" "Das ist nur eine Shell. Bedenklich waere, wenn Dein LILO /vmunix.el bootet." -- Kristian und Holger in de.comp.os.linux.misc

1 participants
0 comments

Re: Some of Will Clinger's Publications 26 years, 3 months

Holger Schauer

>>>>"KMH" == Karl M Hegbloom schrieb am 21 Aug 1998 10:31:55 -0700: >> http://www.ccs.neu.edu/home/will/papers.html KMH> There's a good paper about hygenic macros available here. It's KMH> in .tex... the "acmconf" file that it needs to be latexed was KMH> easy to find using altavista. :-) Could you provide a PostScript version somewhere so that not all of us have to find the style-file as well ? Holger -- --- http://www.coling.uni-freiburg.de/~schauer --- ">grep schauer passwd >schauer:x:1075:1075:Holger Schauer, 2790:/home/schauer:/usr/bin/xemacs" "Das ist nur eine Shell. Bedenklich waere, wenn Dein LILO /vmunix.el bootet." -- Kristian und Holger in de.comp.os.linux.misc

1 participants
0 comments

Re: Macros: Scheme vs Common Lisp 26 years, 3 months

Michael Sperber

>>>>> "Clemens" == Clemens Heitzinger <cheitzin(a)rainbow.studorg.tuwien.ac.at> writes: Clemens> sperber(a)Informatik.Uni-Tuebingen.De (Michael Sperber [Mr. Preprocessor]) writes: >> Even then, it's not clear what you're trying to do. It looks just >> like some syntactic sugar around renaming variables. Clemens> Fresh uninterned symbols are made and bound to prevent unintended Clemens> variable capture. According to the HyperSpec (see make-symbol), Clemens> (eq (make-symbol "foo") (make-symbol "foo")) Clemens> => nil Clemens> What do you mean, "syntactic sugar"? Are macros syntactic sugar? No, but you're creating syntactic sugar around the explicit use of MAKE-SYMBOL. You're not describing a new approach, but rather new notation for an old approach. >> Hygiene, however, means that variables in macros obey the same scoping >> rules as the rest of the language. WITH-HYGIENIC-VARIABLES gives you >> no help whatsoever referring to lexical bindings of the macro. CL Clemens> What help do you mean? >> macros are not hygienic, period. Clemens> Nobody claimed that. I wanted to make the point that it is quite easy Clemens> to define hygienic macros in CL. And I made the point that what you're talking about is not hygiene. You still need explicit annotations to prevent variable capture, at definitions *and* uses. This is tedious and error-prone. You're doing nothing to respect the binding rules of the underlying language. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

1 participants
0 comments

Re: session managment usage string 26 years, 3 months

Didier Verna

Glynn Clements <glynn(a)sensei.co.uk> writes: > Using the WM_COMMAND property for session management is deprecated > according to the X11R6.3 copy of the ICCCM (it is described in > Appendix C: Obsolete Session Manager Conventions). The `proper' > session management protocol is described in the `SMlib' document. I didn't know about this one. Thanks for the hint.

1 participants
0 comments

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

XEmacs-Beta August 1998