From strandh at labri.fr Thu Sep 1 00:06:40 2005 From: strandh at labri.fr (Robert Strandh) Date: Thu, 1 Sep 2005 02:06:40 +0200 Subject: [climacs-devel] Re: a patch for climacs (mainly regarding COMPLETABLY-PATHNAME) + a gimmick In-Reply-To: <31ffd3c4050831121332bc372c@mail.gmail.com> References: <20050831020555.GA31183@mgr.home> <17173.20856.991601.485894@serveur5.labri.fr> <4315FB0D.5050101@yahoo.com> <31ffd3c4050831121332bc372c@mail.gmail.com> Message-ID: <17174.17936.803433.989285@serveur5.labri.fr> Andy Hefner writes: > Isn't the prevailing bias of the climacs project anti-dired? Not quite. I think a dired-like application is useful, and I think that whenever reasonable, any application should be able to call any other application. However, I think the purpose of something like Climacs is to edit sequences of objects, and then perhaps exploiting the contents in some interesting ways such as indenting Lisp code or getting the documentation of a symbol, etc. I don't quite see the point of storing the contents of a directory as text in a Climacs buffer, and then not edit it. It seems much smarter then to just use the CLIM functionality of PRESENTing the pathnames to a CLIM stream. And I certainly don't see why another application (say an imagine manipulation program) should have to call a text editor in order to do dired-like stuff. Instead, I think dired-like functionality is better put in a separate CLIM pane or CLIM application, callable from both Climacs and from other applications. But, I may be wrong of course. -- Robert Strandh --------------------------------------------------------------------- Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. --------------------------------------------------------------------- From m.retzlaff at gmx.net Thu Sep 1 01:54:58 2005 From: m.retzlaff at gmx.net (Max-Gerd Retzlaff) Date: Thu, 1 Sep 2005 03:54:58 +0200 Subject: [climacs-devel] Re: a patch for climacs (mainly regarding COMPLETABLY-PATHNAME) + a gimmick In-Reply-To: <4315FB0D.5050101@yahoo.com> References: <20050831020555.GA31183@mgr.home> <17173.20856.991601.485894@serveur5.labri.fr> <4315FB0D.5050101@yahoo.com> Message-ID: <20050901015458.GA14365@mgr.home> Hi On Wed, Aug 31, 2005 at 07:46:37PM +0100, John Q Splittist wrote: > Robert Strandh wrote: > > Max-Gerd Retzlaff writes: > > > While we are at PRESENTing pathames: It would nice if in the > > > climacs-info-pane (aka modeline) the name of the buffer would be > > > presented via something like: > > > > > > (let ((name (name buffer)) > > > (filepath (filepath buffer))) > > > (if filepath > > > (with-output-as-presentation (pane filepath 'pathname) > > > (princ name pane)) > > > (princ name pane))) > > > > > > and not printed in this huge FORMAT of CLIMACS-GUI::DISPLAY-INFO. > > > [...] > > (a) have the syntax name given by a call to the syntax (ie. a method > specialised on the syntax and buffer, so, eg. lisp-syntax could add the > package like slime does); and I don't get this. > (b) have the buffer name presented _as_a_buffer_, so we could have > interesting and useful things done when one clicked on it. Oh yes, of course! And than a presentation translator to pathname that has a tester that checks whether the buffer is grafted (if I may use this term in analogy to the use when referred to sheets), that is the FILEPATH slot of the CLIMACS-BUFFER instance contains a pathname. Something like: (define-presentation-translator climacs-buffer-to-pathname-translator (climacs-buffer pathname global-climacs-table :gesture :select :tester ((object) (filepath object)) :tester-definitive t :documentation ((object stream) (format stream "Select pathname ~a" (namestring (filepath object))))) (object) (filepath object)) (This is actually tested code that works as expected.) This is really as the buffer-name, presented as of type CLIMACS-BUFFER, will be selectable as input for FIND-FILE (if is associated with a file) and *also* as input for SWITCH-TO-BUFFER. That's the magic of CLIM. :-) > Other things in the info-pane (it would be nice to abolish all uses of > the word 'mode' from climacs) Well, everyone knows what is meant by "modeline". That's probably not true for "info-pane".. > could also usefully be presented for clicking (toggling modified > status, read only status, auto-fill, overwrite...). Yes, yes. Just click on "overwrite" and it will be toggled.. Also we can use real icons in the "info-pane" and don't have to resort to ASCII to represent the various states. Mhmm. Bye, Max -- Max-Gerd Retzlaff For your amusement: If life is a stage, I want some better lighting. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From m.retzlaff at gmx.net Thu Sep 1 02:15:29 2005 From: m.retzlaff at gmx.net (Max-Gerd Retzlaff) Date: Thu, 1 Sep 2005 04:15:29 +0200 Subject: [climacs-devel] Re: a patch for climacs (mainly regarding COMPLETABLY-PATHNAME) + a gimmick In-Reply-To: <4315FB0D.5050101@yahoo.com> References: <20050831020555.GA31183@mgr.home> <17173.20856.991601.485894@serveur5.labri.fr> <4315FB0D.5050101@yahoo.com> Message-ID: <20050901021529.GB14365@mgr.home> Hello On Wed, Aug 31, 2005 at 07:46:37PM +0100, John Q Splittist wrote: > Have you (MGR) given thought to how your file-selector could become a > Dired application? Or, more modestly, a Bufed for climacs? What is Bufed? But no, I want the File Selector to be a general gadget of McCLIM to ACCEPT PATHNAMES for the appropriate VIEW. (I'm not really sure (yet) whether GADGET-VIEW is the right class to specialize it on.) I don't think that such a thing should be included into Climacs. But, on the other hand, I do not use Dired or even Bufed and therefore I do not know what so special about it. But they should probably be implemented as general CLIM applications/gadgets/whatevers. Bye, Max -- Max-Gerd Retzlaff For your amusement: Having no talent is no longer enough. -- Gore Vidal -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From strandh at labri.fr Thu Sep 1 02:29:04 2005 From: strandh at labri.fr (Robert Strandh) Date: Thu, 1 Sep 2005 04:29:04 +0200 Subject: [climacs-devel] Re: a patch for climacs (mainly regarding COMPLETABLY-PATHNAME) + a gimmick In-Reply-To: <20050901015458.GA14365@mgr.home> References: <20050831020555.GA31183@mgr.home> <17173.20856.991601.485894@serveur5.labri.fr> <4315FB0D.5050101@yahoo.com> <20050901015458.GA14365@mgr.home> Message-ID: <17174.26480.955960.22956@serveur5.labri.fr> Max-Gerd Retzlaff writes: > > (a) have the syntax name given by a call to the syntax (ie. a method > > specialised on the syntax and buffer, so, eg. lisp-syntax could add the > > package like slime does); and > > I don't get this. I think he is saying that, rather than just a string or some other static representation of the name of the syntax, whatever will be displayed should be the result of some arbitrary computation determined by the syntax, which would allow for some syntax modules to add more information to the display. -- Robert Strandh --------------------------------------------------------------------- Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. --------------------------------------------------------------------- From splittist at yahoo.com Thu Sep 1 06:48:12 2005 From: splittist at yahoo.com (John Q Splittist) Date: Thu, 01 Sep 2005 07:48:12 +0100 Subject: [climacs-devel] Re: a patch for climacs (mainly regarding COMPLETABLY-PATHNAME) + a gimmick In-Reply-To: <20050901021529.GB14365@mgr.home> References: <20050831020555.GA31183@mgr.home> <17173.20856.991601.485894@serveur5.labri.fr> <4315FB0D.5050101@yahoo.com> <20050901021529.GB14365@mgr.home> Message-ID: <4316A42C.2070801@yahoo.com> Max-Gerd Retzlaff wrote: > On Wed, Aug 31, 2005 at 07:46:37PM +0100, John Q Splittist wrote: > >>Have you (MGR) given thought to how your file-selector could become a >>Dired application? Or, more modestly, a Bufed for climacs? > > What is Bufed? The buffer editor: C-x C-b in Gnu Emacs. > But no, I want the File Selector to be a general > gadget of McCLIM to ACCEPT PATHNAMES for the appropriate VIEW. Well, yes. But you could use your experience to (a) produce a general file-manager application (perhaps using ESA); and/or (b) parameterise the file-selector so it could become a generalised thing-selector, such as buffers. > I don't think that such a thing should be included into Climacs. Neither do I. > But they should > probably be implemented as general CLIM applications/gadgets/whatevers. Agreed. JQS From dpeschel at eskimo.com Thu Sep 1 16:22:13 2005 From: dpeschel at eskimo.com (Derek Peschel) Date: Thu, 1 Sep 2005 09:22:13 -0700 Subject: [climacs-devel] cl-automton's automaton objects may print incorrect state numbers Message-ID: <20050901092213.A6224@eskimo.com> Do other people see this? With SBCL 0.9.0: * (regexp-automaton (string-regexp "abc")) initial state: 0 state 0 [reject]: a -> 0 state 0 [reject]: b -> 0 state 0 [reject]: c -> 0 state 0 [accept]: All the state numbers are 0 which makes no sense. The automaton itself has the correct structure -- it succeeds with (run ... "abc") and fails with other strings. So I suspect the print-object method. Changing the "b" to a dot corrects the printout of state numbers: * (regexp-automaton (string-regexp "a.c")) initial state: 0 state 0 [reject]: a -> 1 state 1 [reject]: #| range from 0 to +max-char-code+ |# -> 2 state 2 [reject]: c -> 3 state 3 [accept]: No, LISP didn't print the comment. The real printout contains UTF-8 for character 0, dash, character 10FFFF. -- Derek From m.retzlaff at gmx.net Thu Sep 1 17:08:54 2005 From: m.retzlaff at gmx.net (Max-Gerd Retzlaff) Date: Thu, 1 Sep 2005 19:08:54 +0200 Subject: [climacs-devel] Re: a patch for climacs (mainly regarding COMPLETABLY-PATHNAME) + a gimmick In-Reply-To: <4316A42C.2070801@yahoo.com> References: <20050831020555.GA31183@mgr.home> <17173.20856.991601.485894@serveur5.labri.fr> <4315FB0D.5050101@yahoo.com> <20050901021529.GB14365@mgr.home> <4316A42C.2070801@yahoo.com> Message-ID: <20050901170854.GA26901@mgr.home> Hello On Thu, Sep 01, 2005 at 07:48:12AM +0100, John Q Splittist wrote: > Max-Gerd Retzlaff wrote: > > On Wed, Aug 31, 2005 at 07:46:37PM +0100, John Q Splittist wrote: > > > >>Have you (MGR) given thought to how your file-selector could become a > >>Dired application? Well, I have given some thought to this. Basically your Dired for CLIM is just a COM-SHOW-DIRECTORY with a presentation-to-command-translator PATHNAME -> COM-FIND-FILE, and one of PATHNAME -> COM-SHOW-DIRECTORY with a tester for DIRECTORYP. Direct the output to an OPEN-WINDOW-STREAM or make the call inside an ACCEPTING-VALUES with :OWN-WINDOW T. I propose that COM-SHOW-DIRECTORY should become a general PRESENT method for a presentation LIST OF PATHNAMES, as well as the construct (let ((icon (clim-listener::icon-of pathname))) (when icon (clim-listener::draw-icon stream icon :extra-spacing 30))) (princ (clim-listener::pathname-printing-name pathname long-name) stream)) should be CLIM's general PRESENT method for PATHNAME in TEXTUAL-DIALOG-VIEW. (The latter is already defined in file-selector.lisp.) Also, the file-selector should be renamed and become just the general ACCEPT method for PATHNAME in GADGET-VIEW (I'm not completely sure about the right view class, yet. But GADGET-VIEW seems to be right.) (This is also already defined in file-selector.lisp.) There is only a ACCEPT-PRESENT-DEFAULT method missing and things will get really smooth. I'll do that soon (no time right now). (Note: This is not yet completely thought through.) > > But no, I want the File Selector to be a general > > gadget of McCLIM to ACCEPT PATHNAMES for the appropriate VIEW. > > Well, yes. But you could use your experience to (a) produce a general > file-manager application (perhaps using ESA); and/or (b) parameterise > the file-selector so it could become a generalised thing-selector, such > as buffers. Well, the file-selector is acutally really simple! Have a look at it, it's just an ACCEPTING-VALUES dialog with some ACCEPTs, some PRESENTATION-TYPEs and presentation translators. The only complicated thing right now is the construction of the new pane hierarchy (as well as the reconstruction of the formerly hierarchy, if the pathname gadget was embedded), but that's only because WITH-OUTPUT-AS-GADGET doesn't work correctly, *yet*. Bye, Max PS: Should this discussion be on mcclim-devel instead? -- Max-Gerd Retzlaff For your amusement: Left to themselves, things tend to go from bad to worse. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From strandh at labri.fr Thu Sep 1 19:16:17 2005 From: strandh at labri.fr (Robert Strandh) Date: Thu, 1 Sep 2005 21:16:17 +0200 Subject: [climacs-devel] Re: a patch for climacs (mainly regarding COMPLETABLY-PATHNAME) + a gimmick In-Reply-To: <20050901170854.GA26901@mgr.home> References: <20050831020555.GA31183@mgr.home> <17173.20856.991601.485894@serveur5.labri.fr> <4315FB0D.5050101@yahoo.com> <20050901021529.GB14365@mgr.home> <4316A42C.2070801@yahoo.com> <20050901170854.GA26901@mgr.home> Message-ID: <17175.21377.616882.907672@serveur5.labri.fr> Max-Gerd Retzlaff writes: > I propose that COM-SHOW-DIRECTORY should become a general PRESENT method > for a presentation LIST OF PATHNAMES, as well as the construct > > (let ((icon (clim-listener::icon-of pathname))) > (when icon > (clim-listener::draw-icon stream icon :extra-spacing 30))) > (princ (clim-listener::pathname-printing-name pathname long-name) stream)) > > should be CLIM's general PRESENT method for PATHNAME in TEXTUAL-DIALOG-VIEW. > (The latter is already defined in file-selector.lisp.) This code has a problem (aside from the very unfortunate indentation), namely that it assumes that the listener is present. At the moment, I do not think that is a good idea. This is going to be a general problem for other applications as well. We are often going to want code that means "if this package exists and this symbol has a function definition in that package, then call the function with the following arguments" . Perhaps a macro FUNCALL-IN-PACKAGE like this: (funcall-in-package :clim-listener (#:icon-of pathname) (message "sorry...")) > PS: Should this discussion be on mcclim-devel instead? Maybe so, yes. -- Robert Strandh --------------------------------------------------------------------- Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. --------------------------------------------------------------------- From a_bakic at yahoo.com Thu Sep 1 19:38:53 2005 From: a_bakic at yahoo.com (Aleksandar Bakic) Date: Thu, 1 Sep 2005 12:38:53 -0700 (PDT) Subject: [climacs-devel] cl-automton's automaton objects may print incorrect state numbers In-Reply-To: <20050901092213.A6224@eskimo.com> Message-ID: <20050901193853.4255.qmail@web40601.mail.yahoo.com> Hi, If I remember correctly, this state number "feature" is intentional. Please take a look at variables *print-renumerate-states* (setting it to true will fix the first problem) and *do-not-escape* (setting it to nil will solve the other problem). The (indirect) reason for introducing the first variable is automaton-equal, which disregards state numbers. Since my connection to sbcl via slime frequently breaks when I work with Unicode characters, I set *do-not-escape* to nil to get around the problem. Regards, Alex --- Derek Peschel wrote: > Do other people see this? With SBCL 0.9.0: > > * (regexp-automaton (string-regexp "abc")) > initial state: 0 > state 0 [reject]: a -> 0 > state 0 [reject]: b -> 0 > state 0 [reject]: c -> 0 > state 0 [accept]: > > All the state numbers are 0 which makes no sense. The automaton itself > has the correct structure -- it succeeds with (run ... "abc") and fails > with other strings. So I suspect the print-object method. > > Changing the "b" to a dot corrects the printout of state numbers: > > * (regexp-automaton (string-regexp "a.c")) > > initial state: 0 > state 0 [reject]: a -> 1 > state 1 [reject]: #| range from 0 to +max-char-code+ |# -> 2 > state 2 [reject]: c -> 3 > state 3 [accept]: > > No, LISP didn't print the comment. The real printout contains UTF-8 > for character 0, dash, character 10FFFF. > > -- Derek > _______________________________________________ > climacs-devel mailing list > climacs-devel at common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/climacs-devel > ____________________________________________________ Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs From strandh at labri.fr Thu Sep 1 20:47:14 2005 From: strandh at labri.fr (Robert Strandh) Date: Thu, 1 Sep 2005 22:47:14 +0200 Subject: [climacs-devel] Command Tables In-Reply-To: <4314A1D1.8020108@yahoo.com> References: <4314A1D1.8020108@yahoo.com> Message-ID: <17175.26834.16521.808002@serveur5.labri.fr> Hello, John Q Splittist writes: > (Also, could people with furrin' keyboards with :dead--acute, > :dead--tilde etc. please check that I haven't broken the unicode stuff.) Seems to work still. -- Robert Strandh --------------------------------------------------------------------- Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. --------------------------------------------------------------------- From dpeschel at eskimo.com Thu Sep 1 21:51:23 2005 From: dpeschel at eskimo.com (Derek Peschel) Date: Thu, 1 Sep 2005 14:51:23 -0700 Subject: [climacs-devel] cl-automton's automaton objects may print incorrect state numbers In-Reply-To: <20050901193853.4255.qmail@web40601.mail.yahoo.com>; from a_bakic@yahoo.com on Thu, Sep 01, 2005 at 12:38:53PM -0700 References: <20050901092213.A6224@eskimo.com> <20050901193853.4255.qmail@web40601.mail.yahoo.com> Message-ID: <20050901145123.A20083@eskimo.com> On Thu, Sep 01, 2005 at 12:38:53PM -0700, Aleksandar Bakic wrote: > If I remember correctly, this state number "feature" is intentional. Please > take a look at variables *print-renumerate-states* (setting it to true will fix But why does *print-renumerate-states* only suppress some state numbers? In the example with "a.c" the numbers appear. > the first problem) and *do-not-escape* (setting it to nil will solve the other > problem). The (indirect) reason for introducing the first variable is Thanks for the tip about *do-not-escape*. I have indeed seen SBCL start the debugger when printing characters. Slime can't get control and becomes confused. BTW is there a way to tell SBCL about the terminal? (Latin-1, UTF-8 up to a certain limit, Slime connected to Emacs with a given encoding running inside a terminal window with certain settings) It makes more sense to me to have positive variable names, e.g., *escape-unicode-chars* which then would have nil as a default setting and which you would set to t while using Slime. > automaton-equal, which disregards state numbers. Does *print-renumerate-states* affect automaton-equal too? To really test for equality (maybe "isomorphism" is a better word) you need to pair each state in one automaton with a state in the other. So you won't be looking at the individual state numbers, but you will be numbering the pairs, in effect. If the printout (with all state numbers the same) reflects how automaton- equal works, then the printout implies automaton-equal isn't keeping a pair number, and I don't see how it can work reliably. If it is keeping a pair number, then automaton-equal's dump of its arguments should show the pair numbers, and other printouts of individual automata should show the original state numbers. At least that's how I'd do it. If I've missed some part of your reasoning, though, let me know. -- Derek From a_bakic at yahoo.com Thu Sep 1 22:46:33 2005 From: a_bakic at yahoo.com (Aleksandar Bakic) Date: Thu, 1 Sep 2005 15:46:33 -0700 (PDT) Subject: [climacs-devel] cl-automton's automaton objects may print incorrect state numbers In-Reply-To: <20050901145123.A20083@eskimo.com> Message-ID: <20050901224633.9722.qmail@web40609.mail.yahoo.com> > But why does *print-renumerate-states* only suppress some state numbers? > In the example with "a.c" the numbers appear. It does not suppress, it (re)sets state numbers (in a hash-table traversal order). A couple automaton operators set state numbers, which is exercised by "a.c". The question is, do you want to reset state numbers for printing purposes (and perhaps lose debugging information)? > BTW is there a way to tell SBCL about the terminal? (Latin-1, > UTF-8 up to a certain limit, Slime connected to Emacs with a given encoding > running inside a terminal window with certain settings) I have the following line in my ~/.slime.lisp: #+sbcl (setq swank::*coding-system* :utf-8-unix) and this one when I connect from Emacs/SLIME to SBCL: (setq slime-net-coding-system 'utf-8-unix) > It makes more sense to me to have positive variable names, e.g., > *escape-unicode-chars* which then would have nil as a default setting > and which you would set to t while using Slime. I agree; will fix it some time soon. > Does *print-renumerate-states* affect automaton-equal too? To really > test for equality (maybe "isomorphism" is a better word) you need to pair > each state in one automaton with a state in the other. So you won't be > looking at the individual state numbers, but you will be numbering the pairs, > in effect. No, *p-r-s* only affects print-object, but I thought about the issues in combination. The automaton-equal relies on minimize to produce a pair of isomorphic automata as inputs, in case they are equivalent (this is an assumption...; otherwise it would be tough to decide the equivalence; the minimization algorithms are based on that). There is an auxiliary hash table (*state-ht*) which is used for pairing the states themselves, not their numbers (which, in some cases, are never set). Anyway, automaton-equal is used in tests only. Alex ____________________________________________________ Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs From m.retzlaff at gmx.net Fri Sep 2 01:51:25 2005 From: m.retzlaff at gmx.net (Max-Gerd Retzlaff) Date: Fri, 2 Sep 2005 03:51:25 +0200 Subject: discussion moved to mcclim-devel (Re: [climacs-devel] Re: a patch for climacs (mainly regarding COMPLETABLY-PATHNAME) + a gimmick) In-Reply-To: <17175.21377.616882.907672@serveur5.labri.fr> References: <20050831020555.GA31183@mgr.home> <17173.20856.991601.485894@serveur5.labri.fr> <4315FB0D.5050101@yahoo.com> <20050901021529.GB14365@mgr.home> <4316A42C.2070801@yahoo.com> <20050901170854.GA26901@mgr.home> <17175.21377.616882.907672@serveur5.labri.fr> Message-ID: <20050902015125.GB30336@mgr.home> On Thu, Sep 01, 2005 at 09:16:17PM +0200, Robert Strandh wrote: > > PS: Should this discussion be on mcclim-devel instead? > > Maybe so, yes. Done. See: http://news.gmane.org/gmane.lisp.mcclim.devel or: http://common-lisp.net/pipermail/mcclim-devel/2005-September/004256.html if you are interested further on and not (yet) subscribed to mcclim-devel. I'm sorry if this is inconvenient for you. Bye, Max -- Max-Gerd Retzlaff For your amusement: You never learn anything by doing it right. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dpeschel at eskimo.com Fri Sep 2 18:21:02 2005 From: dpeschel at eskimo.com (Derek Peschel) Date: Fri, 2 Sep 2005 11:21:02 -0700 Subject: [climacs-devel] cl-automton's automaton objects may print incorrect state numbers In-Reply-To: <20050901224633.9722.qmail@web40609.mail.yahoo.com>; from a_bakic@yahoo.com on Thu, Sep 01, 2005 at 03:46:33PM -0700 References: <20050901145123.A20083@eskimo.com> <20050901224633.9722.qmail@web40609.mail.yahoo.com> Message-ID: <20050902112102.A9739@eskimo.com> On Thu, Sep 01, 2005 at 03:46:33PM -0700, Aleksandar Bakic wrote: > It does not suppress, it (re)sets state numbers (in a hash-table traversal > order). A couple automaton operators set state numbers, which is exercised by > "a.c". The question is, do you want to reset state numbers for printing > purposes (and perhaps lose debugging information)? That makes sense now, and explains the "re" in the name which I had been wondering about. But how are states connected to each other if not by state numbers? Some kind of transition graph that is not normally printed? After all, in the example of "abc", the automaton obviously knows which state is the current one. -- Derek From a_bakic at yahoo.com Fri Sep 2 19:48:41 2005 From: a_bakic at yahoo.com (Aleksandar Bakic) Date: Fri, 2 Sep 2005 12:48:41 -0700 (PDT) Subject: [climacs-devel] cl-automton's automaton objects may print incorrect state numbers In-Reply-To: <20050902112102.A9739@eskimo.com> Message-ID: <20050902194841.955.qmail@web40614.mail.yahoo.com> > But how are states connected to each other if not by state numbers? > Some kind of transition graph that is not normally printed? Yes, a graph. Each state object has a slot named 'transitions,' which is a hash table containing objects of class transition, and each transition object has a slot named 'to,' which is a state object to which the transition leads. The print-object method does not print unique identifiers of these objects (especially states) unless state numbers are already set or *print-renumerate-states* is true. Alex ____________________________________________________ Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs From dpeschel at eskimo.com Fri Sep 2 20:00:01 2005 From: dpeschel at eskimo.com (Derek Peschel) Date: Fri, 2 Sep 2005 13:00:01 -0700 Subject: [climacs-devel] cl-automton's automaton objects may print incorrect state numbers In-Reply-To: <20050902194841.955.qmail@web40614.mail.yahoo.com>; from a_bakic@yahoo.com on Fri, Sep 02, 2005 at 12:48:41PM -0700 References: <20050902112102.A9739@eskimo.com> <20050902194841.955.qmail@web40614.mail.yahoo.com> Message-ID: <20050902130001.A13609@eskimo.com> On Fri, Sep 02, 2005 at 12:48:41PM -0700, Aleksandar Bakic wrote: > Yes, a graph. [...] > slot named 'to,' which is a state object to which the transition leads. The > print-object method does not print unique identifiers of these objects > (especially states) unless state numbers are already set or > *print-renumerate-states* is true. And what determines whether an individual construction step needs to set the state numbers or not? -- Derek From a_bakic at yahoo.com Fri Sep 2 21:23:31 2005 From: a_bakic at yahoo.com (Aleksandar Bakic) Date: Fri, 2 Sep 2005 14:23:31 -0700 (PDT) Subject: [climacs-devel] cl-automton's automaton objects may print incorrect state numbers In-Reply-To: <20050902130001.A13609@eskimo.com> Message-ID: <20050902212331.52551.qmail@web40606.mail.yahoo.com> > And what determines whether an individual construction step needs to set > the state numbers or not? I suppose, the algorithms themselves. Some automaton operations make use of state numbers, some do not (look at calls to 'num' slot accessor). I haven't analyzed all of the code, lots of it is non-trivial. Alex ____________________________________________________ Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs From splittist at yahoo.com Wed Sep 7 07:56:04 2005 From: splittist at yahoo.com (John Q Splittist) Date: Wed, 07 Sep 2005 08:56:04 +0100 Subject: [climacs-devel] Small patch to commands.lisp Message-ID: <431E9D14.8080008@yahoo.com> Attached is a small patch I needed to make mapping over commands/keystrokes work correctly. JQS -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: commands.patch URL: From csr21 at cam.ac.uk Wed Sep 7 08:15:38 2005 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Wed, 07 Sep 2005 09:15:38 +0100 Subject: [climacs-devel] Small patch to commands.lisp In-Reply-To: <431E9D14.8080008@yahoo.com> (John Q. Splittist's message of "Wed, 07 Sep 2005 08:56:04 +0100") References: <431E9D14.8080008@yahoo.com> Message-ID: John Q Splittist writes: > Attached is a small patch I needed to make mapping over > commands/keystrokes work correctly. Aha, a victim! I wonder if it would be possible to add a test case for the failure you've seen in the Tests/ directory? Not that they're run automatically as yet, but it's a good way both to document the previous problem and to ensure that it doesn't recur... Cheers, Christophe From splittist at yahoo.com Tue Sep 13 08:07:49 2005 From: splittist at yahoo.com (John Q Splittist) Date: Tue, 13 Sep 2005 09:07:49 +0100 Subject: [climacs-devel] Re: Command Tables In-Reply-To: <4314A1D1.8020108@yahoo.com> References: <4314A1D1.8020108@yahoo.com> Message-ID: <432688D5.3050601@yahoo.com> John Q Splittist wrote: > At the moment all the keys-bindings are in the global-climacs-table. It > is intended that they be partitioned among a logical set of tables ... > Your thoughts are requested on such matters! After taking into account all the feedback, I'm going to go with this for experimental purposes: com-browse-url base-table com-eval-expression base-table com-full-redisplay base-table com-set-syntax base-table com-find-file buffer-table com-find-file-read-only buffer-table com-insert-file buffer-table com-load-file buffer-table com-not-modified buffer-table com-revert-buffer buffer-table com-save-buffer buffer-table com-set-visited-file-name buffer-table com-toggle-read-only buffer-table com-write-buffer buffer-table com-capitalize-region case-table com-capitalize-word case-table com-downcase-region case-table com-downcase-word case-table com-upcase-region case-table com-upcase-word case-table com-comment-region comment-table com-uncomment-region comment-table com-backward-delete-object deletion-table com-backward-delete-word deletion-table com-backward-kill-expression deletion-table com-backward-kill-sentence deletion-table com-backward-kill-word deletion-table com-delete-horizontal-space deletion-table com-delete-object deletion-table com-delete-word deletion-table com-just-one-space deletion-table com-kill-expression deletion-table com-kill-line deletion-table com-kill-sentence deletion-table com-kill-word deletion-table com-zap-to-character deletion-table com-zap-to-object deletion-table com-accept-lisp-string development-table com-accept-string development-table com-accept-symbol development-table com-inspect-lex development-table com-inspect-parse development-table com-recompile development-table com-report-profile development-table com-reset-profile development-table com-append-next-kill editing-table com-dabbrev-expand editing-table com-insert-charcode editing-table com-insert-parentheses editing-table com-kill-region editing-table com-open-line editing-table com-redo editing-table com-resize-kill-ring editing-table com-rotate-yank editing-table com-tabify-region editing-table com-toggle-overwrite-mode editing-table com-transpose-lines editing-table com-transpose-objects editing-table com-transpose-words editing-table com-undo editing-table com-untabify-region editing-table com-yank editing-table com-auto-fill-mode fill-table com-fill-paragraph fill-table com-set-fill-column fill-table com-extended-command global-esa-table com-quit global-esa-table com-describe-bindings help-table com-describe-key-briefly help-table com-where-is help-table com-delete-indentation indent-table com-indent-line indent-table com-newline-and-indent indent-table com-count-lines-page info-table com-count-lines-region info-table com-what-cursor-position info-table com-call-last-kbd-macro keyboard-macro-table com-end-kbd-macro keyboard-macro-table com-start-kbd-macro keyboard-macro-table com-eval-defun lisp-table com-package lisp-table com-copy-region marking-table com-exchange-point-and-mark marking-table com-mark-definition marking-table com-mark-expression marking-table com-mark-page marking-table com-mark-paragraph marking-table com-mark-whole-buffer marking-table com-mark-word marking-table com-set-mark marking-table com-toggle-visible-mark marking-table com-back-to-indentation movement-table com-backward-down-list movement-table com-backward-expression movement-table com-backward-list movement-table com-backward-object movement-table com-backward-page movement-table com-backward-paragraph movement-table com-backward-sentence movement-table com-backward-up-list movement-table com-backward-word movement-table com-beginning-of-buffer movement-table com-beginning-of-definition movement-table com-beginning-of-line movement-table com-down-list movement-table com-end-of-buffer movement-table com-end-of-definition movement-table com-end-of-line movement-table com-forward-expression movement-table com-forward-list movement-table com-forward-object movement-table com-forward-page movement-table com-forward-paragraph movement-table com-forward-sentence movement-table com-forward-word movement-table com-goto-line movement-table com-goto-position movement-table com-next-line movement-table com-page-down movement-table com-page-up movement-table com-previous-line movement-table com-up-list movement-table com-kill-buffer pane-table com-switch-to-buffer pane-table com-isearch-backward search-table com-isearch-forward search-table com-query-replace search-table com-regex-search-backward search-table com-regex-search-forward search-table com-self-insert self-insert-table com-decrease-presentation-font-sizes slidemacs-table com-first-talking-point slidemacs-table com-flip-slidemacs-syntax slidemacs-table com-increase-presentation-font-sizes slidemacs-table com-last-talking-point slidemacs-table com-next-talking-point slidemacs-table com-postscript-print-presentation slidemacs-table com-previous-talking-point slidemacs-table com-reveal-text slidemacs-table com-compile-and-load-file swine-table com-compile-definition swine-table com-compile-file swine-table com-edit-definition swine-table com-eval-last-expression swine-table com-eval-region swine-table com-goto-location swine-table com-goto-xref swine-table com-macroexpand-1 swine-table com-macroexpand-all swine-table com-return-from-definition swine-table com-delete-window window-table com-other-window window-table com-scroll-other-window window-table com-scroll-other-window-up window-table com-single-window window-table com-split-window-horizontally window-table com-split-window-vertically window-table JQS From dpeschel at eskimo.com Sat Sep 24 07:44:08 2005 From: dpeschel at eskimo.com (Derek Peschel) Date: Sat, 24 Sep 2005 00:44:08 -0700 Subject: [climacs-devel] cl-automaton -- patch to print minimal forms of regexps Message-ID: <20050924004407.A15787@eskimo.com> The attached code replaces the existing print-object method for regexp objects. I find the existing output too full of distracting backslashes and parentheses. The new output uses the operator precedences from the grammar and hopefully includes the minimum number of parentheses and backslashes. Please share your advice or bug reports. The algorithm works but I had been testing it by passing (string-regexp ...) results to an unparsing function. The function is now a method but I haven't tested that version yet. The comments and formatting aren't done yet. (I'm going on a day trip today, Saturday, and I've run out of time.) In order to get the backslash rules exactly right I need to understand the exact input syntax, which I'm still working on. Alex: I like reading consistently formatted files, and you created the one I'm patching, so if you have a style I'm happy to fit with it. -- Derek -------------- next part -------------- *** regexp.lisp Thu Aug 4 15:07:48 2005 --- regexp.new Sat Sep 24 00:24:26 2005 *************** *** 1,10 **** ;;; -*- mode: lisp -*- ;;; ;;; (c) copyright 2005 by Aleksandar Bakic (a_bakic at yahoo.com) ! ;;; ! ;;; Derived from dk.brics.automaton v1.8.1, (c) 2001-2005 by Anders M?ller ! ;;; - Some comments have been copied verbatim from the original code. ;;; Regular expressions are built from the following abstract syntax: --- 1,18 ---- ;;; -*- mode: lisp -*- ;;; ;;; (c) copyright 2005 by Aleksandar Bakic (a_bakic at yahoo.com) ! ;;; and Derek Peschel (dpeschel at eskimo.com) ! ;;; print-object method and related functions based on code in ! ;;; ! ;;; Ramsey, Norman. Unparsing expressions with prefix and postfix operators. ! ;;; Software -- Practice & Experience, 28(12):1327-1356, October 1998 ! ! ;;; Other contents of this file derived from dk.brics.automaton v1.8.1, ! ;;; (c) 2001-2005 by Anders M?ller - Some comments have been copied verbatim ! ;;; from the original code. ! ! ;;;; Grammar. ;;; Regular expressions are built from the following abstract syntax: *************** *** 55,62 **** --- 63,74 ---- ;;; n and m have the same number of digits, then the conforming ;;; strings must have that length (i.e. prefixed by 0's). + ;;;; Package. + (in-package :automaton) + ;;;; Types, constants, class. + (deftype kind () '(member nil :union :concatenation :intersection :optional :repeat :repeat-min :repeat-minmax :complement :char :char-range :anychar :empty *************** *** 89,94 **** --- 101,108 ---- (flags :initform +all+ :initarg :flags :reader flags :type flags-type) (pos :initform 0 :initarg :pos :accessor pos :type integer))) + ;;;; Equality predicate. + (defun regexp-equal (r1 r2) ; for testing (or (eq r1 r2) (and (eq (kind r1) (kind r2)) *************** *** 103,108 **** --- 117,124 ---- (eql (to r1) (to r2)) (eql (flags r1) (flags r2))))) + ;;;; Type conversion functions. + (defun string-regexp (s &optional fs) "Returns a new regexp object corresponding to regular expression string S. FS is a logior or optional syntax flags." *************** *** 160,237 **** (interval-automaton (minr r) (maxr r) (digits r)))))) (minimize a))) ! (defmethod print-object ((r regexp) s) ! (ecase (kind r) ! (:union ! (princ "(" s) ! (print-object (exp1 r) s) ! (princ "\|" s) ! (print-object (exp2 r) s) ! (princ ")" s)) ! (:concatenation ! (print-object (exp1 r) s) ! (print-object (exp2 r) s)) ! (:intersection ! (princ "(" s) ! (print-object (exp1 r) s) ! (princ "&" s) ! (print-object (exp2 r) s) ! (princ ")" s)) ! (:optional ! (princ "(" s) ! (print-object (exp1 r) s) ! (princ ")?" s)) ! (:repeat ! (princ "(" s) ! (print-object (exp1 r) s) ! (princ ")*" s)) ! (:repeat-min ! (princ "(" s) ! (print-object (exp1 r) s) ! (princ "){" s) ! (princ (minr r) s) ! (princ ",}" s)) ! (:repeat-minmax ! (princ "(" s) ! (print-object (exp1 r) s) ! (princ "){" s) ! (princ (minr r) s) ! (princ "," s) ! (princ (maxr r) s) ! (princ "}" s)) ! (:complement ! (princ "~(" s) ! (print-object (exp1 r) s) ! (princ ")" s)) ! (:char ! (princ "\\" s) ! (princ (c r) s)) ! (:char-range ! (princ "[\\" s) ! (princ (from r) s) ! (princ "-\\" s) ! (princ (to r) s) ! (princ "]" s)) ! (:anychar ! (princ "." s)) ! (:empty ! (princ "#" s)) ! (:string ! (princ "\"" s) ! (princ (s r) s) ! (princ "\"" s)) ! (:anystring ! (princ "@" s)) ! (:automaton ! (princ "<" s) ! (princ (s r) s) ! (princ ">" s)) ! (:interval ! (princ "<" s) ! (format s "~V,'0D" (digits r) (minr r)) ! (princ "-" s) ! (format s "~V,'0D" (digits r) (maxr r)) ! (princ ">" s)))) (defun more (r) (< (pos r) (length (text r)))) --- 176,182 ---- (interval-automaton (minr r) (maxr r) (digits r)))))) (minimize a))) ! ;;;; Parsing methods and helper functions. make-regexp constructor. (defun more (r) (< (pos r) (length (text r)))) *************** *** 420,423 **** (defun parse-char-exp (r) (match r #\\) ! (next r)) \ No newline at end of file --- 365,759 ---- (defun parse-char-exp (r) (match r #\\) ! (next r)) ! ! ;;;; print-object method and helper functions. ! ! ;;; Package-wide information about operators. ! ;;; Keys are: ! ;;; The variants of the "kind" CLOS type (for regexp objects) that act ! ;;; like operators ! ;;; The package-local symbol *max-precedence-operator*, which the unparse1 ! ;;; function returns to itself as a sentinel condition ! ;;; Each key hashes to a second-level hash table. ! ;;; Second-level keys and values are: ! ;;; :printed-representation function taking an AST node and returning ! ;;; a string -- must read node-specific field ! ;;; values, so it can't take a kind ! ;;; *max-precedence-operator* has no printed representation ! ;;; :precedence integer -- the integer "less than" relation ! ;;; is equivalent to the operator "takes ! ;;; precedence over" relation ! ;;; :fixity :prefix or :infix or :postfix only ! ;;; :associativity :left or :right or :none only ! ;;; infix operators, and only they, have associativity entries ! ;;; DOCS other invariants? ! (defparameter *operator-properties* (make-hash-table)) ! ! ;;; Function to declare an infix operator. Takes kind variant symbol, ! ;;; printed-representation function, precedence integer, and asociativity ! ;;; symbol. Updates *operator-properties* as a side effect. Return value ! ;;; should not be used. ! (defun infix-operator (kind print prec assoc) ! (let ((ht (make-hash-table))) ! ;; create secondary hash table ! (setf (gethash :printed-representation ht) print) ! (setf (gethash :precedence ht) prec) ! (setf (gethash :fixity ht) :infix) ! (setf (gethash :associativity ht) assoc) ! (setf (gethash :arity ht) 2) ! ;; add secondary hash table to main hash table ! (setf (gethash kind *operator-properties*) ht))) ! ! ;;; Function to declare a prefix operator. Takes kind variant symbol, ! ;;; printed-representation function, and precedence integer. Updates ! ;;; *operator-properties* as a side effect. Return value should not be used. ! (defun prefix-operator (kind print prec) ! (let ((ht (make-hash-table))) ! ;; create secondary hash table ! (setf (gethash :printed-representation ht) print) ! (setf (gethash :precedence ht) prec) ! (setf (gethash :fixity ht) :prefix) ! ;; (no entry for associativity) ! (setf (gethash :arity ht) 1) ! ;; add secondary hash table to main hash table ! (setf (gethash kind *operator-properties*) ht))) ! ! ;;; Function to declare a postfix operator. Takes kind variant symbol, ! ;;; printed-representation function, and precedence integer. Updates ! ;;; *operator-properties* as a side effect. Return value should not be used. ! (defun postfix-operator (kind print prec) ! (let ((ht (make-hash-table))) ! ;; create secondary hash table ! (setf (gethash :printed-representation ht) print) ! (setf (gethash :precedence ht) prec) ! (setf (gethash :fixity ht) :postfix) ! ;; (no entry for associativity) ! (setf (gethash :arity ht) 1) ! ;; add secondary hash table to main hash table ! (setf (gethash kind *operator-properties*) ht))) ! ! ;;; Printed-representation functions for some operator kinds: ! ! (defun print-repeat-min (node) ! (format nil "{~D,}" (minr node))) ! ! (defun print-repeat-minmax (node) ! (format nil "{~D,~D}" (minr node) (maxr node))) ! ! ;;; All other kinds have anonymous printed-representation functions. ! ! ;;; Contents of *operator-properties*. *min-precedence* is for consistency. ! ;;; *max-precedence* is a property of *max-precedence-operator*. ! (defparameter *min-precedence* 0) ! (infix-operator :union (lambda (node) "|") 1 :right) ! (infix-operator :intersection (lambda (node) "&") 2 :right) ! (infix-operator :concatenation (lambda (node) "") 3 :right) ! (postfix-operator :optional (lambda (node) "?") 4) ! (postfix-operator :repeat (lambda (node) "*") 4) ! (postfix-operator :repeat-min #'print-repeat-min 4) ! (postfix-operator :repeat-minmax #'print-repeat-minmax 4) ! (prefix-operator :complement (lambda (node) "~") 5) ! (defparameter *max-precedence* 6) ! ! ;;; Package-local *max-precedence-operator* and its properties. The symbol ! ;;; value must be given, shouldn't conflict with any other symbol values ! ;;; of hash table keys, and is otherwise important. ! (defvar *max-precedence-operator* t) ! (let ((ht (make-hash-table))) ! ;; create secondary hash table ! ;; (no entry for printed representation) (TO DO done to prevent errors, ! ;; but does it impede debugging?) ! (setf (gethash :precedence ht) *max-precedence*) ! (setf (gethash :fixity ht) :infix) ! (setf (gethash :associativity ht) :nonassoc) ! (setf (gethash :arity ht) 2) ! ;; add secondary hash table to main hash table ! (setf (gethash *max-precedence-operator* *operator-properties*) ht)) ! ! ;;; Predicate to determine if a kind symbol acts like an operator. ! (defun operator-p (kind) ! (multiple-value-bind (ht ht-status) (gethash kind *operator-properties*) ! ht-status)) ! ! ;;; Function to look up the given property of the given kind, or cause ! ;;; an error if the property isn't set. The kind must be an operator. ! (defun get-operator-prop (kind key) ! (multiple-value-bind (ht ht-status) (gethash kind *operator-properties*) ! ;; check that KIND has an entry in first-level hash table ! (if (null ht-status) ! ;; it doesn't -- error ! (error "KIND ~S not in *OPERATOR-PROPERTIES*" kind) ! ;; it does -- the first-level value is the second-level hash table; ! ;; check that KEY has an entry there ! (multiple-value-bind (value value-status) (gethash key ht) ! (if (null value-status) ! ;; it doesn't -- error ! (error "KEY ~S not in ~S's entry in *OPERATOR-PROPERTIES*" ! key kind) ! ;; it does -- return KEY's value ! value))))) ! ! ;;; Function to look up and call the printed-representation function for ! ;;; an AST node. Can't take a kind because the printed-representation ! ;;; function can't take a kind either. The node's kind must be an operator. ! (defun print-operator (node) ! (let ((print-fun (get-operator-prop (kind node) :printed-representation))) ! (funcall print-fun node))) ! ! ;;; Package-wide information about leaves. ! ;;; Keys are: ! ;;; The variants of the "kind" CLOS type (for regexp objects) that act ! ;;; like leaves ! ;;; Each key hashes to a second-level hash table. ! ;;; The only second-level key and value is: ! ;;; :printed-representation function taking an AST node and returning ! ;;; a string -- must read node-specific field ! ;;; values, so it can't take a kind ! (defparameter *leaf-properties* (make-hash-table)) ! ! ;;; Function to declare a leaf type. Takes kind variant symbol and ! ;;; printed-representation function. Updates *leaf-properties* as a ! ;;; side effect. Return value should not be used. ! (defun leaf (kind print) ! (let ((ht (make-hash-table))) ! ;; create secondary hash table ! (setf (gethash :printed-representation ht) print) ! ;; add secondary hash table to main hash table ! (setf (gethash kind *leaf-properties*) ht))) ! ! ;;; Set of characters that don't read as literals and must be printed ! ;;; after a backslash. ! (defparameter *non-literal-chars* "\"#&*." (s node))) ! ! (defun print-interval (node) ! (format nil "<~V,'0D-~V,'0D>" ! (digits node) (minr node) (digits node) (maxr node))) ! ! ;;; All other kinds have anonymous printed-representation functions. ! ! ;;; Contents of *leaf-properties*. ! (leaf :char #'print-char) ! (leaf :char-range #'print-char-range) ! (leaf :anychar (lambda (node) ".")) ! (leaf :empty (lambda (node) "#")) ! (leaf :string #'print-string) ! (leaf :anystring (lambda (node) "@")) ! (leaf :automaton #'print-automaton) ! (leaf :interval #'print-interval) ! ;; TO DO add entry for nil (uninitialized objects) ! ! ;;; Predicate to determine if a kind symbol acts like a leaf. ! (defun leaf-p (kind) ! (multiple-value-bind (ht ht-status) (gethash kind *leaf-properties*) ! ht-status)) ! ! ;;; Function to look up the given property of the given kind, or cause ! ;;; an error if the property isn't set. The kind must be a leaf. ! (defun get-leaf-prop (kind key) ! (multiple-value-bind (ht ht-status) (gethash kind *leaf-properties*) ! ;; check that KIND has an entry in first-level hash table ! (if (null ht-status) ! ;; it doesn't -- error ! (error "KIND ~S not in *LEAF-PROPERTIES*" kind) ! ;; it does -- the first-level value is the second-level hash table; ! ;; check that KEY has an entry there ! (multiple-value-bind (value value-status) (gethash key ht) ! (if (null value-status) ! ;; it doesn't -- error ! (error "KEY ~S not in ~S's entry in *LEAF-PROPERTIES*" ! key kind) ! ;; it does -- return KEY's value ! value))))) ! ! ;;; Function to look up and call the printed-representation function for ! ;;; an AST node. Can't take a kind because the printed-representation ! ;;; function can't take a kind either. The node's kind must be a leaf. ! (defun print-leaf (node) ! (let ((print-fun (get-leaf-prop (kind node) :printed-representation))) ! (funcall print-fun node))) ! ! (defun leaf-to-image (node) ! (list (print-leaf node))) ! ! (defun parenthesize-image (image) ! (list image)) ! ! (defun prefix-image (node image) ! (append (list (print-operator node)) ! image)) ! ! (defun image-infix-image (image1 node image2) ! (append image1 ! (list (print-operator node)) ! image2)) ! ! (defun image-postfix (image node) ! (append image ! (list (print-operator node)))) ! ! ;;; Ramsey's predicate "noparens", but with the sense of the return values ! ;;; flipped to hopefully avoid confusion (p. 14). ! (defun parens-required-p (inner-kind outer-kind direction) ! (let ((inner-prec (get-operator-prop inner-kind :precedence)) ! (inner-fix (get-operator-prop inner-kind :fixity)) ! (outer-prec (get-operator-prop outer-kind :precedence)) ! (outer-fix (get-operator-prop outer-kind :fixity))) ! ! (and (> inner-prec outer-prec) ! ;;(return-from parens-required-p (cons 1 nil))) ! (return-from parens-required-p nil)) ! ! (and (eq inner-fix :postfix) ! (eq direction :left) ! ;;(return-from parens-required-p (cons 2 nil))) ! (return-from parens-required-p nil)) ! ! (and (eq inner-fix :prefix) ! (eq direction :right) ! ;;(return-from parens-required-p (cons 3 nil))) ! (return-from parens-required-p nil)) ! ! (and (eq inner-fix :infix) ! (eq (get-operator-prop inner-kind :associativity) :left) ! (eq direction :left) ! ;;(return-from parens-required-p (cons 4 (not (and (= inner-prec outer-prec) ! ;; (eq outer-fix :infix) ! ;; (eq (get-operator-prop outer-kind :associativity) :left)))))) ! (return-from parens-required-p (not (and (= inner-prec outer-prec) ! (eq outer-fix :infix) ! (eq (get-operator-prop outer-kind :associativity) :left))))) ! ! (and (eq inner-fix :infix) ! (eq (get-operator-prop inner-kind :associativity) :right) ! (eq direction :right) ! ;;(return-from parens-required-p (cons 5 (not (and (= inner-prec outer-prec) ! ;; (eq outer-fix :infix) ! ;; (eq (get-operator-prop outer-kind :associativity) :right)))))) ! (return-from parens-required-p (not (and (= inner-prec outer-prec) ! (eq outer-fix :infix) ! (eq (get-operator-prop outer-kind :associativity) :right))))) ! ! (and (eq direction :nonassoc) ! ;;(return-from parens-required-p (cons 6 (not (eq inner-fix outer-fix))))) ! (return-from parens-required-p (not (eq inner-fix outer-fix)))) ! ! ;;(return-from parens-required-p (cons 7 t)))) ! (return-from parens-required-p t))) ! ! ;;; Ramsey's function "bracket" (p. 15). ! (defun maybe-parenthesize-image (inner-fragment outer-kind direction) ! (let ((inner-kind (car inner-fragment)) ! (image (cdr inner-fragment))) ! (if (parens-required-p inner-kind outer-kind direction) ! (parenthesize-image image) ! image))) ! ! ;;; Helper function to make the case statement in unparse1 smaller. ! ;;; Checks a few invariants also used by the hash-table filling functions. ! (defun fixity-case (kind) ! (if (leaf-p kind) ! ;; leaf ! (if (operator-p kind) ! ;; both -- error ! (error "Argument ~S is both a leaf and an operator" kind) ! ;; leaf only -- by definition, no children ! :leaf) ! ;; not leaf ! (if (operator-p kind) ! ;; operator only ! (get-operator-prop kind :fixity) ! ;; neither -- error ! (error "Argument ~S is neither a leaf nor an operator" kind)))) ! ! ! ;;; Ramsey's function "unparse'" (p. 16). ! ;;; DOCS differences from paper -- This one oesn't handle n-ary or decorated nodes. ! (defun unparse1 (node) ! (let ((op (kind node)) ! (l (exp1 node)) ! (r (exp2 node))) ! (ecase (fixity-case op) ! (:leaf ! (cons *max-precedence-operator* ! (leaf-to-image node))) ! (:prefix ! (cons op ! (prefix-image node ! (maybe-parenthesize-image (unparse1 l) ! op ! :nonassoc)))) ! (:postfix ! (cons op ! (image-postfix (maybe-parenthesize-image (unparse1 l) ! op ! :nonassoc) ! node))) ! (:infix ! (cons op ! (image-infix-image (maybe-parenthesize-image (unparse1 l) ! op ! :left) ! node ! (maybe-parenthesize-image (unparse1 r) ! op ! :right))))))) ! ! ;;; DOCS type string ! ;;; Ramsey's function "flatten" (p. 14). ! (defun image-to-string (image) ! (if (null image) (return-from image-to-string ! "")) ! (if (stringp image) (return-from image-to-string ! image)) ! ;; otherwise, assume image is a cons cell, which could be part of ! ;; a single-level list or a sublist ! (if (stringp (car image)) (return-from image-to-string ! (concatenate 'string ! (car image) ! (image-to-string (cdr image))))) ! ;; the car of image isn't a string, so assume it's a cons cell and ! ;; forms a sublist ! (return-from image-to-string ! (concatenate 'string ! (concatenate 'string ! "(" ! (image-to-string (car image)) ! ")") ! (image-to-string (cdr image))))) ! ! ;;; Ramsey's function "unparse" (p. 15). ! (defun unparse (node) ! (image-to-string (cdr (unparse1 node)))) ! ! (defmethod print-object ((r regexp) s) ! (princ (image-to-string (cdr (unparse1 r))) s) From a_bakic at yahoo.com Sat Sep 24 12:10:46 2005 From: a_bakic at yahoo.com (Aleksandar Bakic) Date: Sat, 24 Sep 2005 05:10:46 -0700 (PDT) Subject: [climacs-devel] cl-automaton -- patch to print minimal forms of regexps In-Reply-To: <20050924004407.A15787@eskimo.com> Message-ID: <20050924121047.99702.qmail@web40603.mail.yahoo.com> > Alex: I like reading consistently formatted files, and you created the > one I'm patching, so if you have a style I'm happy to fit with it. Thanks! As you might guess, I am swamped with other things and it will again take me some time to go through the code. Could you add some unit tests for it? (Perhaps we should add the coverage utility to climacs.) As for the formatting, my two basic rules are: (1) use as few lines of code and comments as possible, and (2) no line should be longer than 80 characters (or 79, whatever looks nice in Emacs). Alex ______________________________________________________ Yahoo! for Good Donate to the Hurricane Katrina relief effort. http://store.yahoo.com/redcross-donate3/ From a_bakic at yahoo.com Sat Sep 24 12:57:09 2005 From: a_bakic at yahoo.com (Aleksandar Bakic) Date: Sat, 24 Sep 2005 05:57:09 -0700 (PDT) Subject: [climacs-devel] cl-automaton -- patch to print minimal forms of regexps In-Reply-To: <20050924004407.A15787@eskimo.com> Message-ID: <20050924125709.71651.qmail@web40624.mail.yahoo.com> BTW, I am not sure if this is of interest to you: have you thought about extending cl-automaton with groupings and/or back-references? In http://jp.franz.com/base/seminar/2004-06-10/Franz-e1.pdf, on page 8 it is claimed that the former is tricky and the latter is difficult for a DFA-based regexp engine. I suppose, the groupings support will be needed soon. Alex __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com From dpeschel at eskimo.com Sat Sep 24 14:57:13 2005 From: dpeschel at eskimo.com (Derek Peschel) Date: Sat, 24 Sep 2005 07:57:13 -0700 Subject: [climacs-devel] cl-automaton -- patch to print minimal forms of regexps In-Reply-To: <20050924125709.71651.qmail@web40624.mail.yahoo.com>; from a_bakic@yahoo.com on Sat, Sep 24, 2005 at 05:57:09AM -0700 References: <20050924004407.A15787@eskimo.com> <20050924125709.71651.qmail@web40624.mail.yahoo.com> Message-ID: <20050924075713.A5054@eskimo.com> On Sat, Sep 24, 2005 at 05:57:09AM -0700, Aleksandar Bakic wrote: > BTW, I am not sure if this is of interest to you: have you thought about > extending cl-automaton with groupings and/or back-references? In Yes, I thought of it as a feature. First I'd like to understand the syntax and write a syntax class for it. Even though that would be a small improvement, it's a feature I've wanted to see for a long time. Right now, for the most part, Automaton has a pleasantly simple syntax. Character classes are the only exception I know about. > http://jp.franz.com/base/seminar/2004-06-10/Franz-e1.pdf, on page 8 it is > claimed that the former is tricky and the latter is difficult for a DFA-based > regexp engine. I don't know how regexp libraries these days are implemented, but some of them use hybrids of DFA and NFA ideas. It might be easiest to change to a pure NFA implementation and then "hybridize" it later. On the other hand, there are a few other regexp libraries in LISP and it might really be easiest to switch to one of them. -- Derek From a_bakic at yahoo.com Sat Sep 24 21:06:57 2005 From: a_bakic at yahoo.com (Aleksandar Bakic) Date: Sat, 24 Sep 2005 14:06:57 -0700 (PDT) Subject: [climacs-devel] cl-automaton -- patch to print minimal forms of regexps In-Reply-To: <20050924075713.A5054@eskimo.com> Message-ID: <20050924210657.40139.qmail@web40608.mail.yahoo.com> > On the other hand, > there are a few other regexp libraries in LISP and it might really be easiest > to switch to one of them. I could not find one supporting Unicode "natively" (in the SBCL sense). On the other hand, I am yet to figure out how to make Climacs work with my keyboard switcher, so that I can try searching for Unicode text... Alex __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com