Hi Simon,
On Wed, Dec 26, 2018 at 8:40 PM Simon King <simon.k...@uni-jena.de> wrote:
>
> Hi Dima,
>
> On 2018-12-26, Dima Pasechnik <dimp...@gmail.com> wrote:
> >>> No, it does, by tradiation:
> >>> AFAIK, *ALL* interfaces that are named after a third-party computer
> >>> algebra
> >
> > if you count ECL in, the interface with it is not pexpect, yet it is
> > called ecl, not libecl.
>
> Right. I wasn't aware of ecl.
>
> >> projects (gap, singular, r, pari, polymake, maxima, and of course magma,
> >> mathematica...) used to be pexpect interfaces. There has been
> >> an increased use of C level interfaces (libsingular, libgap, ...), but I
> >> got
> >> the impression that their names give a hint that they are not pexpect
> >> interfaces.
> >
> > You're involved with the project. I doubt most users ever had a look at the
> > implementation.
>
> Maybe, but that doesn't change the fact that most (but as you pointed
> out not all) interfaces to other project's interpreters were based on
> pexpect. Changing it would be a HUGE change and clearly requires a
> deprecation, IMHO.
>
> > IMHO it is carelessness of the pexpect gap interface design: while
> > there are perfectly reasonable GAP names for functions, e.g. Order()
> > for the group order in GAP, available in libgap, Sages's pexpect gap
> > has cardinality() etc.
> > This is just unnecessary namespace bloat.
>
> That's totally not what I meant. In fact libgap is very far from being
> a drop-in replacement for gap. The convenience methods you mention are
> basically peanuts.
>
> I am sorry for the following long text on libgap vs. gap. I do not try
> to hijack this thread but try to raise awareness that incompatible
> interface changes may be very reasonable and well-motivated, but can
> at the same time have nasty consequences for users of that interface.
> These words of warning may or may not apply to R pexpect/library
> interfaces (so, I am not hijacking...).
>
> EXAMPLES:
>
> In the following, GAP denotes the third party software, gap denotes the
> pexpect interface to a GAP process, libgap denotes the C interface for
> the GAP interpreter.
>
> Like in *all* pexpect interfaces, calling gap with a command `c` given as
> a string results in a Sage object that corresponds to a GAP object defined
> by interpreting `c`. libgap returns a GAP string instead of interpreting
> that string and binding a Sage object to the result of interpreting `c`.
>
> sage: gap('DihedralGroup(8)')
> Group( [ f1, f2, f3 ] )
> sage: libgap('DihedralGroup(8)')
> "DihedralGroup(8)"
>
> Like in *all* pexpect interfaces, calling `gap.eval(c)` invokes the gap
> interpreter on the command `c` and returns the answer of gap's
> interpreter as a string. In contrast, libgap.eval(c) evaluates the command
> `c` and returns a Sage object. And actually I did recall that an assignment
> in the libgap interpreter was impossible, but apparently I was mistaken.
>
> sage: gap.eval('G := DihedralGroup(8)')
> '<pc group of size 8 with 3 generators>'
> sage: gap.eval('Order(G)')
> '8'
> sage: libgap.eval('G := DihedralGroup(8)')
> <pc group of size 8 with 3 generators>
> sage: libgap.eval('Order(G)')
> 8
> sage: __.Order()
> 8
>
> Similar to Sage, the GAP interpreter uses a dot followed by a number to
> access the generators of a group. So does gap. However, libgap doesn't.
>
> sage: G = gap('DihedralGroup(8)')
> sage: gap(G.name()+'.1')
> f1
> sage: G.1
> f1
> sage: G = libgap('DihedralGroup(8)')
> sage: G.1
> Traceback (most recent call last):
> ...
> AttributeError: name "gen" is not defined in GAP.
>
> That's what happens if one removes convenience methods. Perhaps it isn't
> peanuts after all?
>
> gap counts its lists 1-based, which is (as we probably agree) the root
> of all evil. libgap, on the opposite, counts its lists 0-based. While in
> principle 0-based is the only way to paradise and 0 is the smallest
> natural number, CHANGING from 1-based to 0-based is a maintanance
> nightmare for people who have research code involving gap and want to
> change to libgap.
>
> sage: L = gap('[1,2,3]')
> sage: L[1]
> 1
> sage: L = libgap.eval('[1,2,3]')
> sage: L[1]
> 2
>
> SUMMARY:
>
> - libgap.eval behaves similar to gap.__call__.
> - libgap.__call__ on a string does not interprete that string but
> returns a GAP string. That's of course a reasonable thing to do, but
> is totally not the same as what gap.__call__ is doing.
> - gap allows generator access in the usual GAP and SageMath way. libgap
> doesn't.
> - gap is (like GAP) 1-based. libgap is (like Python) 0-based.
>
> So, now you can imagine how much fun I had changing p_group_cohomology
> from gap to libgap. I am very close to finally get it finished.
> But please don't try to change libgap now to make it match more closely
> with gap - or I would have all that fun again...
>
> > I am for removal of pexpect interfaces for which there are
> > replacements available.
>
> I am not. Replacement of the default interface yes. Removal no.
>
> Removing well established pexpect interfaces would realistically imply
> that the pexpect *infrastructure* will bit rot, and so it would be more
> difficult to maintain cases in which pexpect is the only option (magma,
> mathematica,...).
>
> And of course, a removal should require a deprecation.
>
> And of course, a "replacement" is only possible if the two interfaces
> are truely equivalent, which in the case of (lib)singular and (lib)gap
> they aren't. I cannot tell if lib_r and r are equivalent.
>
> Best regards,
> Simon
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to sage-devel@googlegroups.com.
> Visit this group at https://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
