<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>Harri Pitkänen kirjoitti 19.1.2010 kello 20.08:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>On Tuesday 19 January 2010, Flammie Pirinen wrote:<br><blockquote type="cite">Ah yes, that's one thing that isn't entirely trivial, or at least,<br></blockquote><blockquote type="cite">ideal solution exceeds my C++ skills. Since HFST is just a bridge-like<br></blockquote><blockquote type="cite">wrapper over underlying libraries, and currently it includes the<br></blockquote><blockquote type="cite">external libraries in source tree, and some of the definitions leak to<br></blockquote><blockquote type="cite">public installed headers of hfst. Easy way out would be to fix<br></blockquote><blockquote type="cite">underlying libraries from using e.g. deprecated data structures in<br></blockquote><blockquote type="cite">their respective public interfaces, but I suppose there must be<br></blockquote><blockquote type="cite">something in the proper bridge etc. design patterns that do the hiding<br></blockquote><blockquote type="cite">more elegantly without need to modify the external library code.<br></blockquote><br>I think the correct solution depends on what sort of applications are supposed <br>to use this API. If the applications do not need to know anything about the <br>underlying libraries you can just remove all the functionality that depends on <br>SFST/OpenFST headers and stop including those headers. </div></blockquote><div><br></div><div>Yes that has been my impression of the HFST and I hope there are not any software that would use structures or functions of underlying libraries directly. The reason I believe that just removing the headers isn't possible is that public interface of hfst operates on some structures or classes which have at least private members from underlying libraries and necessitate inclusion of underlying libraries' headers in public headers of hfst (I hope that makes sense, I haven't been actively developing the library side of things myself).</div><br><blockquote type="cite"><div>This is most certainly <br>the case for libvoikko since we basically do only lookups and nothing else.<font class="Apple-style-span" color="#000000"><font class="Apple-style-span" color="#144FAE"><br></font></font></div></blockquote><div><br></div><div>Hopefully for libvoikko as well as many other end applications we can provide the lightweight lookup transducers with specialised code for faster lookup, as Krister said in other mail. This will cut the size of library to a fraction and since it's entirely our code then it will not have licencing issues that may be problematic to some users.</div><br><blockquote type="cite"><div>I have not studied these headers very carefully but it seems that the problem <br>may be that HFST is not really providing an abstraction layer. It seems to <br>equate weighted transducers with OpenFST and unweighted transducers with SFST <br>and use the backend data types directly in public headers. Often such types <br>can be replaced with pointers to incomplete types or abstract base classes.<br></div></blockquote><div><br></div>Yes that is certainly current state of the things, only guarantee in current library is that it provides almost same function signatures for both back ends. Our svn contains a reformulation in object oriented terms that provides framework for inclusion of more backends, but it seemingly does not escape the requirement of including headers of underlying libraries as implementation classes contain private members of data structures from the backends.<br><blockquote type="cite"><div><font class="Apple-style-span" color="#000000"><br></font><blockquote type="cite"><blockquote type="cite">implement checking of correct<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">capitalisation.<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Is it enough if implementers of morphologies are encouraged to make a<br></blockquote><blockquote type="cite">suggestion mechanism, which always prefers (initial) capitalisation<br></blockquote><blockquote type="cite">over anything else, given that the language in question contains<br></blockquote><blockquote type="cite">capitalisation of any form?<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Assuming the suggestion mechanism will<br></blockquote><blockquote type="cite">eventually be fast enough, it possibly won't give much advantage to<br></blockquote><blockquote type="cite">check capitalisation separately. Of course on user interface side it<br></blockquote><blockquote type="cite">should still be trivial to check if the capitalisation is first<br></blockquote><blockquote type="cite">suggestion in the list and inform user of appropriately.<br></blockquote><br>The advantage is significant at least with Malaga since we are now able to <br>implement various modes for checking capitalisation while doing only one <br>analysis operation per word.<br></div></blockquote><div><br></div><div>Theoretically the different modes of capitalisation would either require their own suggestion transducers or some short passage of code allowing or skipping entries depending on some settings. Of course the version where you capitalise first and test if that alone results in correct spelling will be cheaper in not requiring different suggestion relations (e.g. you might have edit distance plus initial capitalisation and edit distance without caps as separate transducers) nor handling the suggestions by c code.</div><div><br></div><blockquote type="cite"><div><blockquote type="cite">Is there anything blocking debian packages of HFST? </blockquote></div></blockquote><blockquote type="cite"><div><blockquote type="cite">[...]</blockquote><br>Probably nothing is blocking it. The included copies of SFST and OpenFST could <br>be an issue for the distributions that care about such things.</div></blockquote><div><br></div><div>Oh yes of course, bundling does certainly prevent the HFST ebuild entering gentoo's main repository, I hadn't even thought of having it outside the science repo. Hopefully if the library gains enough importance there will be available experience for debundling the backend libraries as well.</div></div></body></html>