[GAP Forum] [GAP Support] protecting variables ( MakeImmutable )

[MCKAY john]

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 at mail.gap-system.org
> > http://mail.gap-system.org/mailman/listinfo/forum
>
>
> _______________________________________________
> Forum mailing list
> Forum at mail.gap-system.org
> http://mail.gap-system.org/mailman/listinfo/forum
>