simboli backquoted, buoni o cattivi?

Penso che la potenziale confusione sia un problema serio. Se ti trovi già a confondere backquote e citazione singola, pensa a quanti futuri autori di codice e lettori faranno lo stesso errore.

Molte lingue che utilizzano le backquote come sintassi speciale sembrano riservarle per un utilizzo relativamente raro. Potrei speculare sul perché, ma se ti aspetti che i simboli ottengano un uso pesante, puoi prendere questo come un suggerimento per usare qualche altra sintassi.

Quindi, per la domanda bonus a scelta multipla, preferirei # 3 o # 4 sopra # 1 o # 2, per motivi anti-confusione. Puoi mantenere le backquote in riserva per quando hai bisogno di un operatore quotelike extra-speciale ...

Se stai introducendo un nuovo concetto (simboli) in una sintassi familiare, perché non introdurre una nuova notazione insieme ad essa? Ad esempio, all'interno delle regole del tuo lexer potresti usare un singolo lead-in per un semplice nome simbolico:

$symbol
$this_could_also_be_a_symbol_name

Per i simboli con un nome arbitrario, un costrutto in fase di compilazione symbol("$ymbol w1th 4rbitrary n4m3") potrebbe fornire la flessibilità necessaria. Potrebbe anche essere utile avere una funzione che costruisca simboli in fase di esecuzione, a seconda della semantica della tua lingua.

Mi viene in mente che Ruby fa quasi esattamente questo usando : :

:symbol
:this_could_also_be_a_symbol_name
:'$ymbol w1th 4rbitrary n4m3'

Smalltalk ha anche una distinzione tra le tre cose e utilizza questa sintassi:

'strings are in single quotes'
"comments are in double quotes. Yes, comments!"
$a "is the character a, dollar-sign prefixes characters"
#symbol "is a symbol, prefixed by a hash"

A parte la potenziale difficoltà di ottenere alcuni simboli (mi dispiace Euro-gente!) ha la sintassi non convenzionale ma piacevole dell'uso di virgolette singole per le stringhe, dal momento che non richiede (su una tastiera americana) -key premi per entrare e digiti molte più stringhe dei caratteri (i commenti che usano la doppia virgola sono un po 'strani, ma probabilmente le persone sopportano colpi di chiave più lunghi per i commenti poiché sono digitati in una mentalità diversa rispetto al codice.)

Ci sono molti modi in cui puoi gestirlo, ma tieni a mente la rarità e i casi d'uso per ogni tipo. Le stringhe si abitueranno molto e dovrebbero avere la sintassi più semplice. I caratteri sono più rari da usare. L'utilizzo dei simboli dipenderà dalla quantità di meta-programmazione che la lingua consente o richiede.

Puoi anche fare alcuni trucchetti in fase di compilazione, a seconda di quanti controlli di tipo hai che potresti essere in grado di convertire una stringa di un singolo carattere in un char o un char in una stringa di un solo carattere, se necessario con il casting implicito. Nella maggior parte dei linguaggi di alto livello, le esigenze di utilizzare direttamente un tipo char effettivo sono abbastanza rari.

Un'altra opzione è usare stringhe con tag. C #, ad esempio, ha "regular strings" e @"non-escaping strings that ignore things like \n" . Il linguaggio D utilizza r"this is a string" per lo stesso scopo. Sono molto utili per stringhe di simboli pesanti come espressioni regolari o nomi di directory. Puoi usare c"A" per i caratteri e s"symbol" per i simboli. Le lettere come operatori sono affari complicati, ma rappresentano un mnemonico molto semplice per il programmatore e non dovrebbero essere difficili da lessare poiché una stringa letterale non seguirebbe mai direttamente un simbolo senza spazi bianchi nella maggior parte delle lingue.

Poiché un'istanza del tipo char ha una lunghezza di un solo carattere, è davvero necessario racchiuderla tra i segni di corrispondenza? Se si sovrappongono i simboli in apostrofi, è possibile utilizzare solo un singolo backquote per precedere un carattere. Se l'utente li mescola, seguono messaggi di errore di sintassi di grandi dimensioni, come quando un programmatore C dimentica una parentesi di chiusura.