Un modo per forzare Mathematica a rimuovere l'attributo Locked?

Question

Ovviamente Mathematica è in grado di rimuovere questo attributo; semplicemente non mi lascia. Qualcuno sa di qualche hack per costringere Mathematica a fare quello che dico?

Answer 1

Questa non è una risposta positiva.

Un caso di utilizzo particolare che potrebbe richiedere la rimozione dell'attributo Locked sarebbe la modifica locale di un simbolo con ad es. Internal InheritedBlock`. Spesso questo costrutto di scoping viene utilizzato per modificare/rimuovere gli attributi localmente dei simboli di sistema, per ottenere un comportamento diverso per l'ambito del blocco (vedere ad esempio this answer).

Tuttavia, secondo la mia ricerca, dalle 38 Locked simboli (di tutti i contesti e pacchetti di cariche di Quiet[Needs /@ Contexts[]]!) nessuno avere altri attributi funzionali che, se è cambiata, si tradurrebbe in un comportamento modificato (ad esempio non Flat, Orderless, Hold***, ecc.) E nessuno di questi ha uno Options che potrebbe essere modificato. Di solito questi simboli sono molto basilari, quasi tutti dal contesto System` ad es. I, List o True. Le uniche eccezioni 3 aventi un'attributi funzionali o le opzioni sono:

(* Symbol *)     (* Attributes *)    (* Options *) 
Remove      {HoldAll, Locked, Protected} {} 
$ProductInformation   {Locked, Protected}   {"ProductIDName" -> "Mathematica", "ProductKernelName" -> "Mathematica 9 Kernel", "ProductVersion" -> "9.0 for Microsoft Windows (64-bit) (January 25, 2013)", "ProductVersionNumber" -> 9.} 
Developer`StartProtectedMode {Locked, Protected}   {"Allow" -> Null, "Deny" -> Null, "Execute" -> {}, "Read" -> {}, "ReadWrite" -> {}, "Write" -> {}} 

Quindi, oltre a modificare queste funzioni utilizzate da remoto, l'unico reasone si vorrebbe rimuovere Locked è quello di modificare direttamente le definizioni di qualche simbolo. Ma questo può essere eseguito solo iff il simbolo è anche ReadProtected, altrimenti il ​​codice è scritto in inferiore a Matematica - livello completamente nascosto all'utente (tranne forse i wrapper di alto livello). Ci sono solo tre tali simboli (ancora una volta, fuori di tutti i contesti standard e pacchetti):

I     (* with {Locked, Protected, ReadProtected} *) 
$InputStreamMethods (* with {Locked, Protected, ReadProtected} *) 
$OutputStreamMethods (* with {Locked, Protected, ReadProtected} *) 

In conclusione, direi la rimozione Locked non sarebbe davvero dare alcun vantaggio per l'esplorazione/modifica interni funzionali per una grande molte funzioni, e anche il cambiamento di comportamento di tali funzioni fondamentali come I o $Input sembra essere una pessima idea, quindi nessuno è in grado di investire troppo tempo nel capire un trucco.

Inoltre, poiché lo stesso Locked ha l'attributo Locked (poiché v9, in v8 era solo Protected), non può essere modificato ad es. Locked = Sequence[] prima di caricare un pacchetto per bypassare la sicurezza anche per cose crittografate. Uno potrebbe ridefinire Attributes e SetAttributes prima di caricare i pacchetti, ma dio sa cosa potrebbe andare storto se fatto.

Ovviamente se la funzione è di tipo pacchettizzato e i file del pacchetto sono disponibili e non codificati, è possibile rimuovere manualmente gli attributi modificando direttamente i file. Ma secondo la mia esperienza, la tradizione comune è che le funzioni che sono liberamente esplorabili nei pacchetti non sono Locked.