[Lemon-devel] [Lemon-user] GraphReader

[DEZSO Balazs]

Hi Developers,

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

In my point of view, the value representation can be restricted to this format, but I would not like stricter format as Alpar suggested. 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