Hi Tels On Thu, 2011-03-24 at 14:52 -0400, Tels wrote: > On Mon, March 21, 2011 6:09 pm, Ron Savage wrote: > > Hi Tels > > > > I'm copying others in this reply. > > Ido this too, if I forgot someone, apologies, I am on a somewhat-crappy > webmail interface :)
Understand. I have problems with mailing list emails - when I click on reply and it defaults to sending to the individual rather than the list. > > On Mon, 2011-03-21 at 16:10 -0400, Tels wrote: > >> Sorry, > >> > >> I only got a few emails which are probably not in order, so I haven't > >> read > >> everything. But I'll reply anyway :) > >> > >> On Sat, March 19, 2011 7:16 pm, Ron Savage wrote: > >> > Hi Shlomi > >> > > >> > Let me say things in different words. > >> > > >> > Our primary goal is ensuring the future of the module, right? > >> > > >> > To me, this implies any of these items /might/ be jettisoned: > >> > > >> > o Pure-Perl > >> > >> This would be only a choice of speed (e.g. you could have a transparent > >> XS > >> module, or C::Inline). However, when Pure-Perl works, why throw it away? > > > > Shlomi Fish describes his position here, together with my (initial) > > reply: > > > > http://community.livejournal.com/shlomif_tech/57021.html > > > > > >> > o Current parser > >> > >> The parser might not be the best, but what exactly are your problems > >> with it? > > > > Maintenance. > > That is indeed a point - however, I am not actually sure how much > maintainance the current parser needs. For me (and other's bugreports seem > to confirm this), the layouter would need a LOT more work than the parser. Ok. That's important information. My view is that whoever takes over maintenance needs to understand the parser to understand how the input is stored in RAM and whether or not a different structure in RAM is required, before being able to use that to drive the layouter. Hence I started with a discussion of the parser and its potential replacements. Perhaps that approach is not necessary to work on the layouter. > >> > o Current input format > >> > >> If you throw away the Graph::Easy input format, you will have killed the > >> module's spirit. The *entire* point of Graph::Easy is the > >> easy-to-write-easy-to-read input format. Everything else is just to keep > >> it being useful. > > > > Understood. The aim is to support some simple syntax, but (from my point > > of view) not necessarily the current syntax. > > I'd like to object that the syntax is of course nec. Now, that doesn't > mean that everything is perfect, or some subtle changes could/should be > made, but your sentence "not necessarily the current syntax" sends shivers > down my spine along the "we replace it with XML" variant. So, no, the > current syntax is important. Not every bit and detail of it, but the > spirit. He he he. Good point. I can assure you I'm not suggesting change for the sake of it. And you won't catch me recommending XML in a situation like this. Many years ago there was a wave of XML fanaticism, and it was over-used horribly. XML is marvellous in some situations, but not everywhere. Having to fire up an XML parser to read a config file of 4 or 5 lines is madness. > If someone is interested, I could type a few words of the design choices? Great! > (Also, I should add that an equal well important part of Graph::Easy is > "conversion". Having it act as a converter is very important. And an > intermidiate format is important for this, too, because all the other > formats are so incompatible with each other. Having the "easy" syntax of > graph::easy as the interm. format simplifies things - like you can have a > 2-step conversion from any format to any other. Without that, you would > need to go "graphviz => graph-easy => intermidiate => graphml" and that > would just make things worse. That, however, implies that the current > syntax MUST support the features it does now, as most of them are present > in one or more other formats and are required for conversion between > formats). More good points, especially re conversion. I was thinking of Grapy::Easy's own format. I did not mean to imply support should be dropped for any other format. In a perfect world (joke) the other packages would adopt G::E's syntax. The fancy approach would be to have the initial parse recognize the format (via file suffix, command line option, syntax) and then switch to a format-specific parser. A plug-able system would be ideal for handling various formats, with G::E's intrinsic format being the heart of the system, a bit like SQL Fairy http://sqlfairy.sourceforge.net/ > >> > So, I'd like the discussion to focus on choosing the best tools to > >> > support the module. > >> > > >> > Thus, I'm saying the current input format, e.g., is not driving the > >> > discussion, but rather the search for tools is. > >> > > >> > That in turn means that if a different parser is chosen, then changing > >> > the input format would be a consequence (i.e. not a driver) of that > >> > choice. > >> > >> Why then not write your very own module, where you have the choice of > >> your > >> own format, own parser and own language? I mean, you might as well use > >> graphviz, it is written in C, has a different parser AND a different > >> input > >> format? > > > > Good point. > > > > And if that were to happen, I for one would certainly want to maintain > > the great spirit of Graph::Easy's design. > > > >> Sorry, but I don't understand the force behind this at all. > > I can just repeat this question: I don't understand why you would f.i. > change the parser (that is ok, whatever parses best is choosen) AND change > the input format AND at the same time claim "I for one would certainly > want to maintain the great spirit of Graph::Easy's design"? > > I mean, wouldn't that throw away the current design? (maybe its a language > barrier thing :) Not at all. Let me ask: What is the current design? o Various input formats (implying converter). o Layouter. o Output formatting options. o Etc. None of that should change. Having 1 or more parsers is fundamental, but that doesn't mean the /current/ parser has to be kept forever... > So to summarize: If you write a new parser in C, or whatever, and it is > 99% compatible, fine, be my guest. But if you change the language, you > just have created yet-another-graph-description-language and this doesn't > have much to do with Graph::Easy anymore (or so I think from what little I > know :) It's true it'd be another one, although very similar to the current one I'd say. The point is to use what people have learned, to invent a new wheel, which will be even more round than the previous wheel :). For example, Perl is not going to stay with V 5 forever, is it? -- Ron Savage http://savage.net.au/ Ph: 0421 920 622
