On Wed, 2012-12-05 at 17:45 +0800, Daniel Hartwig wrote: > On 5 December 2012 16:48, Nala Ginrut <nalagin...@gmail.com> wrote: > >> Is there some advantage to using the GOOPS classes rather than > >> equivalent predicates, which are more universal? Of course, the order > >> of the tests matters highly in both cases. > >> > > > > GOOPS classes covered all the possible types in Guile, and it's easy to > > detect the type of a datum with class-of. I just choose the simplest way > > which I can imagined. > > Predicates cover the same or a greater range of types, in more detail. > Consider application-specific types: > - a non-GOOPS extension will provide a predicate, but no specific GOOPS class; > - a GOOPS extension will typically provide both. > > If the colouring is to be made extensible (as it should be), a system > based on GOOPS class will be insufficient for these extra types. > Further, suppose a user wants to colour the same type differently > depending on it's content (such as short vs. long strings, or strings > matching some pattern). >
OK, I understand it now. And I'm going to write an more extensible type-checker. Nevertheless, maybe I should do some work to give the users chance to define his/her own color-scheme in '~/.guile'. But it maybe not so easy, I've no idea about it yet. So I'll do the type-checker first. > > > >> > >> There is already a guile-lib module (ansi term-color) that has a > >> particular syntax and defines the codes. It would be excellent to > >> make use of it here, or at least share the syntax and avoid some > >> duplication. > >> > > > > The code segment of the color is not so big, so I write my own. > > And it's not easy to do a quick hack with mixing other guy's code. > > For a quick hack, and it's simple, so I have no time to care about > > reusing other's work. > > Please consider to at least adjust your syntax to be compatible … > > > I don't think it's proper to use (ansi term-color) > > purposely, since it's not in Guile. > > … or target this work at extending guile-lib; as a pure-scheme module, > it certainly falls within the scope. I understand you are keen to > have this integrated in to Guile proper. > I can understand this too. So your suggestion is to write a (term ansi-color) compatible interface. I think it's easy to do. But I'm afraid that Guile don't integrate (term ansi-color). Or I should copy (term ansi-color) into colorized.scm? It's not a big one, but is it proper? Anyway, (ice-9 colorized) contains ansi-color procedures could be worthy of the name. What if I send three patches eventually? 1. optinal-repl-printer 2. colorized.scm 3. ansi-color.scm I just want to make sure colorized-repl feature work successfully. > > Wrong again. I forget add 'before-print-hook' and *unspecified* > > situation. > > With the alternate (and preferred, IMO) patch I sent, the custom > print procedure should not contain those parts anyway. You can > presume that an the before-print-hook has been called, and > unspecified value has already been ignored. > > Anyway, looks like a good start to such a feature, though I am > surprised to see the structure is very different to pretty-print ! :-) > > Regards >
