Re: design pattern wanted

From: Steffen Mazanek <steffen.mazanek_at_unibw.de>
Date: Mon, 14 Apr 2008 12:55:07 +0200

Thanks to all who have answered. Bernd, your thought
is very nice, and I kinda do this already at the moment,
i.e., if while parsing a particular edge is needed, it can
either be found in the graph or it is just pretended and,
thus, carried in a so-called completion graph. This
approach appears to be well-suited for my application
domain. When I rethink my problem with this insight, it
may indeed be doable with sets. I'll try :-)

Best regards,
Steffen


2008/4/14, Bernd Brassel <bbr_at_informatik.uni-kiel.de>:
> Steffen Mazanek wrote:
> > I got two replies so far. The first one suggested a solution
> > where instantiated and uninstantiated edges are hold in
> > two different data structures. But I guess this can only
> > be done making heavy use of unsafe functions and losing
> > nice properties.
>
>
> This depends on the concrete way you want to use this. Maybe you know
> beforehand when you add "free edges" and when you add ground ones? This
> way you could well separate the data for inserting but not for
> searching. For example an interface couild be:
>
> insertEdge :: Edge -> Graph -> Graph
> insertFree :: Graph -> Graph
> findEdge :: Graph -> Edge
>
> But intuitively, I would say that with this separation you do not need
> free variables at all.
>
> Another thought: How about returning free variables on default, i.e.,
> when the edge is not found in the graph? Of course I do not know whether
> this complies with your application.
>
> Cheers
>
> Bernd
>


-- 
Dipl.-Inform. Steffen Mazanek
Institut für Softwaretechnologie
Fakultät Informatik
Universität der Bundeswehr München
85577 Neubiberg
Tel: +49 (0)89 6004-2505
Fax: +49 (0)89 6004-4447
E-Mail: steffen.mazanek_at_unibw.de
_______________________________________________
curry mailing list
curry_at_lists.RWTH-Aachen.DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/curry
Received on Mon Apr 14 2008 - 13:26:51 CEST

This archive was generated by hypermail 2.3.0 : Fri Sep 20 2019 - 07:15:07 CEST