In che modo un sistema di tipo statico influisce sulla progettazione di un linguaggio basato su prototipi?

Il confine tra un tipo fondamentale e un oggetto è sfocato e spesso introdotto artificialmente. Ad esempio, in C una struct è solo un mucchio di record, solo un tipo derivato non-object. In C ++, una struct è una classe con tutti i campi pubblici, un oggetto. Tuttavia, C ++ è quasi totalmente compatibile all'indietro con C ... il bordo è davvero morbido qui.

Per la programmazione basata su prototipi è necessario avere oggetti mutabili in fase di esecuzione. DEVONO essere digitati in modo soft perché ogni modifica cambia in fase di esecuzione, una classe di un tipo cambia in un'altra: il suo tipo cambia.

Potresti mantenere i tipi fondamentali e derivati non-object come statici. Ma questo introduce una strana disparità, gli oggetti sono tipizzati in modo soft, i non oggetti sono tipizzati staticamente e tra i due deve essere stabilito un hard più difficile. Dovresti essere in grado di trasformare una struttura? Una stringa? Dovrebbe Numero essere una classe o un tipo fondamentale, o un insieme di tipi fondamentali, int / float / bignum / etc?

È semplicemente più naturale e facile da imparare, usare e scrivere per avere questa uniforme, tutti i tipi sono mutabili o nessun tipo è mutabile in fase di runtime. Se dichiari che un solo tipo (oggetto) è mutabile, ti ritroverai con mal di testa e problemi di entrambi i mondi.

Tipo statico:

• più facile da implementare
• più veloce / più efficiente
• sicura
• più facile mantenere / documentare i grandi sistemi a causa dell'astrazione.

La digitazione dinamica è:

• più veloce da scrivere,
• più conciso
• lingua più facile da imparare
• più indulgente per errori di progettazione.

Unendo i due, sacrificherai molto.

• L'implementazione diventa più difficile di una qualsiasi delle due precedenti.
• la velocità dipende se usi i tipi di soft o no ... Se lo fai, è basso, se non lo fai, perché scegliere la lingua?
• digita sicurezza è fuori dalla finestra per tutti i tipi di oggetto.
• seguire come un tipo si trasforma in un altro è un compito piuttosto difficile. Documentandolo - molto difficile.
• Hai ancora bisogno di fare tutta la contabilità con i tipi fondamentali, che uccide la concisione e la velocità di scrittura
• La complessità della lingua è più alta (più difficile da apprendere) di qualsiasi "specifica",
• il termine "permissivo" di un tipo digitato dinamico viene sostituito dalla tendenza ad alcuni errori molto complicati nei tipi di attributi non corrispondenti.

La difficoltà è abbastanza semplice da vedere: Considerando gli oggetti come dizionari di metodi o come cose che rispondono ai messaggi, osserva quanto segue sulle comuni lingue OO tipizzate staticamente:

• Tutti i tasti / messaggi del dizionario sono generalmente dichiarati in anticipo, utilizzando identificatori dichiarati staticamente.

• Alcuni set di messaggi vengono dichiarati in anticipo e gli oggetti sono associati a questi set per determinare a quali messaggi rispondere.

• Le relazioni di inclusione di un set di messaggi che costituiscono un sottoinsieme di un altro sono dichiarate staticamente ed esplicitamente; i sottoinsiemi non dichiarati ma logici non sono validi.

• Verifica del tipo di tentativi per garantire che tutti i messaggi vengano inviati solo agli oggetti che rispondono ad essi.

Ognuno di questi conflitti in qualche misura con un sistema basato su prototipi:

• I nomi dei messaggi potrebbero essere dichiarati in anticipo, sotto forma di "atomi" o stringhe internate o quant'altro, ma poco altro; la plasticità degli oggetti significa che l'assegnazione dei tipi ai metodi è scomoda.

• È probabilmente la caratteristica essenziale di un sistema basato sul prototipo che i gruppi di messaggi sono definiti da ciò a cui un oggetto risponde, piuttosto che viceversa. Sarebbe ragionevole assegnare degli alias a particolari combinazioni in fase di compilazione, ma i set di messaggi determinati in fase di runtime devono essere possibili.

• Il vero impatto dei due precedenti citati riguarda le relazioni di inclusione, in cui le dichiarazioni esplicite sono completamente inattuabili. L'ereditarietà nel senso di sottotipizzazione statico e nominale è antitetica a un sistema basato su prototipi.

Il che ci porta al punto finale, che non in realtà vogliamo cambiare. Ci piacerebbe comunque assicurarci che i messaggi vengano inviati solo agli oggetti che rispondono a loro. Tuttavia:

• Non possiamo sapere staticamente quali messaggi possono essere raggruppati.
• Non possiamo sapere quali gruppi sono sottoinsiemi di altri.
• Non possiamo sapere quali gruppi sono possibili.
• Non possiamo nemmeno specificare quale tipo di argomenti vengono inviati insieme a un singolo messaggio.
• Fondamentalmente abbiamo scoperto che non possiamo specificare molto di nulla nel caso in generale.

Quindi come può essere risolto? Limitare l'intera generalità in qualche modo (che è spiacevole, e può rapidamente eliminare qualsiasi vantaggio derivante dall'uso di un sistema basato su prototipi), o rendere il sistema dei tipi molto più fluido ed esprimere vincoli piuttosto che tipi esatti .

Il sistema di tipi basato su vincoli porta rapidamente alla nozione di sub-typing strutturale , che in un senso molto sciolto può essere pensato come l'equivalente statico di "digitazione anatra". I maggiori ostacoli qui sono che tali sistemi sono molto più complicati da controllare e sono meno noti (il che significa poco lavoro preliminare da studiare).

In sintesi: è possibile, è solo più difficile da fare rispetto a un sistema di tipo statico nominale o un sistema dinamico basato su metadati di runtime, e quindi poche persone si preoccupano.

Credo che un modo per ottenere un linguaggio basato sul prototipo e tipizzato staticamente sia basare il linguaggio su Modelli e Concetti.

I concetti erano una volta una funzionalità pianificata per C ++ 0x. Il codice generico nei template C ++ è già de facto "static-typed". L'idea di Concepts è quella di essere in grado di dire alcune cose sui membri richiesti e sulle caratteristiche dei tipi, senza richiedere o implicare un modello di ereditarietà di classe alla base di tale relazione (perché doveva lavorare con un codice di template già "tipicamente anatra digitato") ).

In un linguaggio basato su modelli e concetti, i Concetti sarebbero basati su prototipi e i Modelli ti libererebbero dalla cura di qualsiasi modello di classe che potrebbe essere o non essere utilizzato per implementare i tipi di valori.

A parte i trucchi dell'uso della compilazione di staged per consentire al linguaggio di essere il proprio meta-linguaggio, queste derivazioni prototipali di Concepts sarebbero necessariamente immutabili una volta create. Tuttavia, l'obiezione che ciò non è basato sul prototipo è una falsa pista. Sarebbe semplicemente un linguaggio funzionale. Un modello dinamico di prototipo di base che è anche funzionale è stato almeno tentato .