Why am I receiving this? Thanks, John McKay
On Tue, 13 Mar 2012, Stephen Linton wrote:
> Jakob,
>
> Could we take this discussion onto the support list, please?
> I think it's become a bit too abstract to be of general interest for the
> forum.
> If any interesting ideas come up that are of wider interest, we can post a
> summary to the forum.
>
> Steve
>
>
> On 13 Mar 2012, at 15:51, kroeker wrote:
>
> > Dear Alexander,
> >
> >
> > thanks for the link again ! (
> > http://dl.acm.org/citation.cfm?id=281508.281540 )
> >
> > Indeed it is not surprising that some features of GAP seem unusual.
> >
> > Just let us forget GAP for a moment and think in general about one of my
> > previous questions:
> > What positive or negative implications for a language e.g. 'python'
> > would have a silently failed action?
> > Is it worthwhile and possible to change the behaviour of the language or
> > not?
> >
> >
> >
> > Best,
> >
> >
> > Jakob
> > ( Яков )
> >
> >
> > P.S. I'm posting some observations which seems unusual to me promptly,
> > because as soon as I get adopted to GAP
> > I wouldn't even notice. In general some implications of (historically
> > grown) functionality are not automatically 'useful' or 'unfavourable',
> > e.g. the financial system is evolved over time but I hope you agree that
> > it also has some serious problems.
> >
> >
> > Am 10.03.2012 19:30, schrieb Alexander Konovalov:
> >> Dear Jakob,
> >>
> >> On 9 Mar 2012, at 14:52, kroeker wrote:
> >> ...
> >>
> >>>> there is no way to "lock" an operation, [..] it would also cause problems
> >>> Let for now assume that it is not necessary to lock operations. Then in
> >>> my opinion a user should get at least a warning that locking is not
> >>> possible when trying it.
> >>> By the way, It shouldn't be possible to lock existing read-only
> >>> operations, so it is not obvious to me that locking an operation would
> >>> cause problems a priori.
> >>> It also seems that other functionality in GAP has similar behaviour
> >>> which is unusual from my point of view:
> >>> actions fail without a warning, e.g. calling an attribute setter twice
> >>> with different values (the second call has no effect)
> >> GAP may be regarded as a problem-oriented language designed to be a
> >> platform for implementing mathematical (mostly discrete) algorithms, and
> >> it has rather unique object-oriented features invented to model
> >> mathematical objects: for example, objects that learn during their
> >> lifetime and change their type in the process, and dynamic polymorphism
> >> (that is, method selection based on current type of all arguments). So
> >> it's not surprising that from the beginning some of its features may seem
> >> unusual.
> >>
> >> There is a paper "The GAP 4 type system: organising algebraic algorithms"
> >> by Steve Linton and Thomas Breuer in ISSAC'98 proceedings available here:
> >>
> >> http://dl.acm.org/citation.cfm?id=281508.281540
> >>
> >> which may give more details about the reasoning behind GAP design
> >> principles, in addition to the GAP manual.
> >>
> >> Best wishes,
> >> Alexander
> >>
> >>
> >
> >
> > _______________________________________________
> > Forum mailing list
> > Forum@mail.gap-system.org
> > http://mail.gap-system.org/mailman/listinfo/forum
>
>
> _______________________________________________
> Forum mailing list
> Forum@mail.gap-system.org
> http://mail.gap-system.org/mailman/listinfo/forum
>
_______________________________________________
Forum mailing list
Forum@mail.gap-system.org
http://mail.gap-system.org/mailman/listinfo/forum
