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

[kroeker]

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
>
>