[pstricks] Re: pst-eucl (integrating Metapost into Pstricks :-)

[Denis Girou]

>>>>> "Maurice.Diamantini" == Maurice DIAMANTINI <diam at ensta.fr> writes:

    Maurice.Diamantini> To be able to define point as intesection of to figure
    Maurice.Diamantini> could be very usefull for all the Pstricks user

  Probably numberous or many but not "all". Do not forget that PSTricks is a
general tool. It users obviously include some mathematicians but many of them
do not use advanced or even scolar mathematics (for instance, I know some
people who use it intensively since several years for genealogy purposes only).

    Maurice.Diamantini> I'd like it to be included in the core of Pstricks!

  I do not think that we will see it in the next years. First, I am not aware
of any volunteer for common tasks, even for repackaging the whole distribution
in a better way and for integrating the splitted documentation...

  And more, I rather think that it would be a bad idea. The only "good"
changes that I see on the core files is to use internally the `keyval' package
in place of the close but not strictly equivalent PSTricks mechanism (the
`keyval' package was designed with the PSTricks mechanism in mind) and to
exclude the PSTricks management of colors as an external optional package
(Timothy would have done both changes in the version 0.94 ... if he had
finished it). For the rest, I think that stability is a lot more important
quality that new functions for a part of users, so it would be better to keep
such new developments that the ones of Dominique Rodriguez as additional
packages. Even an internal rewritting for the usage of a really coherent and
safe naming scheme would open today a large era of instability...

    Maurice.Diamantini> But if it is, all the command names have to be cleaned
    Maurice.Diamantini> to be more Pstricks complient.

  There is (unfortunately) no such thing. PSTricks has mostly an incoherent
naming scheme (or to be more precise, it has only some "local" coherencies,
as nevertheless there are some conventions used locally). This is mainly
because it was not though as the huge and diversified toolbox that it became,
but as a small and ad hoc development which grew up continously. Of course,
Timothy realize that such choices must have been done in another way, and
around 1994 planned to make a rewritting using this time an integrated and
coherent naming scheme for the macros. Unfortunately, he stopped his work on
PSTricks before to have done this...

  If you look at the source code of `fancyvrb', which was written later by
Timothy, you could see that his naming choices are a lot more coherent than
for Seminar and PSTricks (even if they could have been even stronger in some
places), but this is mainly because he wrote `fancyvrb' several years later
after the beginning of his other developments.

    Maurice.Diamantini> About the commands names, there are two options:

    Maurice.Diamantini> - either pst-geom is consider an addon to Pstricks,
    Maurice.Diamantini>   so all commands should begin by \geo... to avoid conflicts
    Maurice.Diamantini>   names.

    Georges.Mariano> And, more important, the naming of pstricks command don't need to be
    Georges.Mariano> defined from an implementation point of view (pstricks complient) but
    Georges.Mariano> from a user point of view, and I don't know if it is possible or

  The two sides are important. Conflict names is a real issue, for which
(La)TeX has unfortunately no required policy (price of freedom given to
developers...). Look at the source codes of some of the hugest LaTeX packages
of these last years (`hyperref', `listings') for real efforts to define
coherent naming schemes.

  Take care too that PSTricks is always mixed with other packages. The \geo
prefix will not give you a real guarantee that it will not clash with
another package. This is mainly why I used myself names like \PstPoly...,
\PstLens..., \PstCalendar... for external names and \PstPoly at ...,
\PstLens at ..., \PstCalendar at ... for internal names. So, I would be personally
in favor of something like \PstEucl[@]..., \PstEuclide[@]..., \PstGeom[@]...,
\PstGeometry[@]..., etc., but this could seem heavy and painful in extensive
usage and this is to each developer to make his own choices. I think that
there are too few people who make developments to force them to adopt
conventions that they can dislike... They have to make their own choices at
their own risks. Nevertheless, your questions are important and this is a good
contribution of beta-testers and interested people to force developers to
deeply think to the consequences of their choices.

    Maurice.Diamantini>     \geoNodeLC{}    instead of \pstInterLC
    Maurice.Diamantini>     \geoNodeLL{}    instead of \pstInter
    Maurice.Diamantini>     \geoNodeCC{}    instead of \pstInterCC
    Maurice.Diamantini>     ...

    Maurice.Diamantini>   One should easily distinging between commands that define
    Maurice.Diamantini>   some nodes and commands that put something to a node. 
    Maurice.Diamantini>   ...

    Maurice.Diamantini> - also some command which do similar thing have different
    Maurice.Diamantini>   names : they should be replace by option
    Maurice.Diamantini>   ...

    Maurice.Diamantini> - also some option name could be rename:
    Maurice.Diamantini>   ...
       
    Maurice.Diamantini> - if you do some summary of all the commands
    Maurice.Diamantini>   and all the options for each of these commands,
    Maurice.Diamantini>   it could help to define better name.
    Maurice.Diamantini>   (give this abstract to read by someone for 5 mn, then
    Maurice.Diamantini>   ask him what does which command!)

  As far as I can see, probably a lot of good questions / suggestions here,
but it must be discussed with Dominique by the specialists of this field,
as Georges Mariano start to do it, and this is to Dominique to choose the
appropriate answers and the changes he would like to do.

    Maurice.Diamantini> general discution about integrating METAPOST INTO PSTRICKS.

  I never believed that such general discussions can be very productive,
never believed at all that the future of MetaPost is to be integrated inside
PSTricks, nor PSTricks integrated inside MetaPost...

  I already explained several times in other places what I personally think:
that the only important thing is to have a programming language to implement
graphic algorithms (so, this is not because MetaPost is a very good tool that
MetaGraf is a good idea...) ; that MetaPost and PSTricks are not alone and
that there are other very good generic packages with different strengths and
weaknesses (at least AlDraTeX, mfpic, PiCTeX, Xy-pic) ; that the most
important final thing is probably that everybody find the "right" tool for him
which make him happy...

  MetaPost users (I know that few people here use both) would be interested to
know that Denis Roegel has implemented a large part of PSTricks functions in
MetaPost, which will give a lot of high level user functions to MetaPost, which
often lacked of them. I think it could help a lot MetaPost users, and also
help to build new high level MetaPost packages, but I do not think it will
deeply change the global situation. The spirit of the two packages is
different and their usage is also really different, even if the
functionalities will be closest up to now.
http://www.loria.fr/~roegel/TeX/momanual.pdf

  And I am convainced since the beginning (I saw the very first versions) that,
even if I will probably never use it myself!, the work of Dominique Rodriguez
is of very good quality and will be a great improvement for people drawing
geometrical pictures with PSTricks.

D.G.