[Lemon-devel] [Lemon-user] GraphReader

Alpár Jüttner alpar at cs.elte.hu
Sun Jan 20 18:46:16 CET 2008 

Hi,

> The current lemon reader uses the next format to read the unknown tokens:
> Well formed expression with the next parses
>    (), [], {}, //
> Well formed string literal with escape processing
>    "(.|\")*", '(.|\')*'
> Sequence without any whitespace (not in quote and parses)
> The parsed sequence can contain string literals

This seems to contradict to your and also Peter's previous mail. You
said that the columns cannot be determined without knowing their type.
Similarly in Peter's example, there are columns which are two words.

> In my point of view, the value representation can be restricted to this
>  format, but I would not like stricter format as Alpar suggested.
 
Could you tell me a single real advantage of the 'extended format'?

Remember that these advantages should compensate the facts that
currently
      * it is impossible of process a general .lgf file (either by a
        C(++) code or an awk script)
      * it is impossible to read a column twice (into two maps). It is
        not a theoretical problem as you might think. You will come
        across this whenever you want to write a program where the user
        can decide running time which column should be used for some
        purpose. (Why the user should not be allowed to use the same
        column for different purposes?) Currently if you want to handle
        this situation, it is easier to write an own reader, which is
        ridiculous.
      * The current GraphReader/GraphWriter implementation is extremely
        and overly complex. Probably nobody understand how it works,
        except you. Nobody is able to do any single change in that,
        except you.

The last bullet is really a serious problem. Just an example, once I
wanted to change the '@uedgeset' string in the GraphReader for some
reason :). It took me more than half an hour to just identify where is
the string is hidden in the source code and I still didn't understood
how I could properly change is to '@edgeset'. 

Alpar


>  If
>  you want to develop some general lgf handling tool, you can use this
>  short specification, or you can use the lemon::UnformattedReader
>  class. Unfortunately, the multiple reading is not possible, but I do
>  not feel it important question.
> 
> Best, Balazs
> 
> 
> 
> 
> ________________________________________
> From: lemon-devel-bounces at lemon.cs.elte.hu [lemon-devel-bounces at lemon.cs.elte.hu] On Behalf Of Alpár Jüttner [alpar at cs.elte.hu]
> Sent: Sunday, January 20, 2008 1:09 PM
> To: Kovács Péter
> Cc: LEMON Development; lemon-user at lemon.cs.elte.hu
> Subject: Re: [Lemon-devel] [Lemon-user] GraphReader
> 
> Hi,
> 
> > Maybe Alpar's idea seems better. However there are special cases when it
> > is not so good. For example if the .lgf file contains a map of
> > dim2::Point value, the following lines are valid now:
> >
> >       coords
> > 1     10 20
> > 2     (30 40)
> > 3     50, 60
> > 4     (70, 80)
> > 5     90,100
> > 6     (110,120)
> 
> Why on earth would anyone want you write a file like this? And even if
> someone wants to do that, why should we enable to do that?
> By the way, these formats can also be used in my approach, they just
> have to be quoted like this:
> 
>         coords
> 1       "10 20"
> 2       "(30 40)"
> 3       "50, 60"
> 4       "(70, 80)"
> 5       90,100
> 6       (110,120)
> 
> Regards,
> Alpar
> 
> >
> > If we used the method suggested by Alpar, only the last two lines would
> > be valid, but according to the current implementation of the
> > dim2::Point::operator<< function, a graph writer would generate the 4th
> > line. (Of course it could be changed to the last version: (x,y) without
> > spaces.)
> >
> > Peter
> >
> >
> > Alpár Jüttner írta:
> > > Hi,
> > >
> > > This design has much more drawbacks than advantages.
> > >
> > > The worst thing is that it makes it fully impossible to write any tool
> > > that would manipulate a general .lgf file. For example it is even
> > > impossible to correctly read a general .lgf file into a graph editor.
> > >
> > > Do we really need such a free file-format? Probably we don't.
> > >
> > > I think we should insist on the original definition, i.e. the edgeset
> > > and the nodeset of the file should consist of plain whitespace separated
> > > columns. The only exception I would allow is that a column can also be a
> > > string enclosed by two double-quotes characters (in order to enable
> > > whitespace containing strings). Of course, we may also use a more
> > > complex evaluation similar to the way the unix shells evaluate their
> > > parameters, but I'm not sure if it is worth doing that.
> > > This approach would make it possible to write general .lgf manipulation
> > > tools, and it would also enable a much simpler API for making custom
> > > readers/writers for special data types, as they would basically be
> > > converters between std::string and the data type.
> > >
> > > Of course, it also means that we must write e.g. "x + y / 82" instead of
> > > just x + y / 82.
> > > I think it is really worth doing that.
> > >
> > > Regards,
> > > Alpar
> > >
> > >
> > >
> > > On Fri, 2008-01-18 at 17:20 +0100, Balazs Dezso wrote:
> > >> Hi
> > >>
> > >>> What is the reason for that?
> > >> The reader does not cache the string representation of the map value, because
> > >> the map reader reads the value directly from the input stream. More general
> > >> reason, the graph IO design is based on the next rule, just the map knows
> > >> where is the end of its input. By example, the value may contains space, or
> > >> it should be well formed expression.
> > >>
> > >> By example, valid values for some readers:
> > >> Hello\ world!
> > >> <xml> AB <tag> C </tag> D </xml>
> > >> x + y / 82
> > >> separator;
> > >> "\"Hello\" \"World\""
> > >>
> > >> Best, Balazs
> > >>
> > >> On Friday 18 January 2008 16.50.25 you wrote:
> > >>> Hi,
> > >>>
> > >>>> It is not possible, but an exception is thrown when you try to do this.
> > >>> What is the reason for that?
> > >>>
> > >>>>  The
> > >>>> only solution is using maps such ForkWriteMap...
> > >>>>
> > >>>> Best, Balazs
> > >>>>
> > >>>> On Thursday 17 January 2008 11.07.26 Alpár Jüttner wrote:
> > >>>>> Hi,
> > >>>>>
> > >>>>> Is it possible to read a column of an .lfg file into two different maps
> > >>>>> (of different types, such as NodeMap<double> and NodeMap<std::string>)
> > >>>>> at the same time?
> > >>>>>
> > >>>>> Regards,
> > >>>>> Alpar
> > >>>>>
> > >>>>>
> > >>>>> _______________________________________________
> > >>>>> Lemon-user mailing list
> > >>>>> Lemon-user at lemon.cs.elte.hu
> > >>>>> http://lemon.cs.elte.hu/mailman/listinfo/lemon-user
> > >>>> _______________________________________________
> > >>>> Lemon-user mailing list
> > >>>> Lemon-user at lemon.cs.elte.hu
> > >>>> http://lemon.cs.elte.hu/mailman/listinfo/lemon-user
> > >>
> > >
> > > _______________________________________________
> > > Lemon-user mailing list
> > > Lemon-user at lemon.cs.elte.hu
> > > http://lemon.cs.elte.hu/mailman/listinfo/lemon-user
> >
> > _______________________________________________
> > Lemon-user mailing list
> > Lemon-user at lemon.cs.elte.hu
> > http://lemon.cs.elte.hu/mailman/listinfo/lemon-user
> 
> _______________________________________________
> Lemon-devel mailing list
> Lemon-devel at lemon.cs.elte.hu
> http://lemon.cs.elte.hu/mailman/listinfo/lemon-devel
> _______________________________________________
> Lemon-devel mailing list
> Lemon-devel at lemon.cs.elte.hu
> http://lemon.cs.elte.hu/mailman/listinfo/lemon-devel

More information about the Lemon-devel mailing list