Quale linguaggio di programmazione pratico e non teorico non ha parole chiave riservate?

22

Ho cercato un linguaggio di programmazione pratico che non abbia parole chiave riservate, ma non ho avuto fortuna a trovarne uno.

Sto lavorando a un linguaggio di programmazione per la mia modifica e intrattenimento e non ho ancora avuto bisogno di includere parole chiave, questo è ciò che mi ha portato alla mia ricerca e alla domanda:

Non vedo la comodità per lo scrittore del compilatore come importante per l'utente finale della lingua. I computer sono abbastanza potenti oggi per essere in grado di dedurre significati dal contesto. Non più di quanto uno scrittore abbia bisogno di etichettare nomi, verbi e simili quando scrive un romanzo, perché un programmatore dovrebbe etichettare funzioni e variabili con function x() {}o set x = 1o var x = 1etc; quando posso dedurre dal contesto delle affermazioni che si tratta di una dichiarazione di funzione o di una chiamata o che un'etichetta è un'assegnazione a un valore o un riferimento a quel valore di etichette?

Ecco un esempio concreto di ciò che sta facendo il mio attuale parser, senza bisogno di parole chiave riservate per supportare cose comuni che normalmente avrebbero un sacco di rumori come funco functiono deco cosa no.

Dichiarazione di funzione

sum3(a,b,c) -> a + b + c.

Invocazione di funzioni

x = sum3(1,2,3).

Funzione anonima denominata x

x = (a,b,c) -> a + b + c.
y = x(1,2,3).

Vorrei sapere perché le parole chiave sono così importanti per un linguaggio di programmazione di successo?

theory languages

8

Forth è piuttosto pratico e non ha parole chiave.

— Logica SK

4

@JamesAnderson, no, sono solo parole, come tutte le altre parole. Nessun significato speciale di sorta.

— SK-logic

7

Gli operatori e la punteggiatura vengono considerati "parola chiave"? se sì, allora non può esistere alcuna lingua, poiché non è possibile definire alcuna sintassi.

— Emilio Garavaglia l'

2

@ SK-logic: di solito. Ma quali sono gli "identificatori" se non si è ancora tokenizzati? Poiché un token è "qualunque cosa riconoscibile", "int", "myvalue" e "+" non sono diversi, prima che fosse data una regola di sintassi. Se "+" non è definito come operatore, può essere solo un nome per qualcosa come qualsiasi altra stringa di caratteri singoli unicode. Gli operatori, dal punto di vista della sintassi pura, non sono altro che "parole chiave a carattere singolo".

— Emilio Garavaglia l'

2

In questo contesto, cos'è una parola chiave? È un identificatore che ha un significato speciale per il compilatore? È un identificatore che il programmatore non dovrebbe usare come variabile o qualcosa del genere? Conta come senza parole chiave se le parole chiave devono essere appositamente designate? (Molto tempo fa ho visto un sistema ALGOL in cui le parole chiave dovevano essere citate per essere parole chiave.)

— David Thornley

12

MUMPS ha molto successo, essendo ampiamente utilizzato in ambito assicurativo e sanitario e non ha parole riservate. Direi che aiutano in termini di scrittura di codice più chiaro ma non sono strettamente necessari. APL è un altro esempio. APL vede l'uso di script una tantum nell'industria nucleare tra gli altri. J , un membro della famiglia APL manca anche di parole chiave.

Le parole chiave aiutano gli autori di compilatori a implementare l'analisi più facilmente. APL è notoriamente il giusto associativo. Aiutano anche a rafforzare le convenzioni e migliorare la leggibilità. APL non è noto per essere estremamente leggibile dalla maggior parte.

— Ingegnere mondiale
fonte

2

+1 per "Le parole chiave aiutano gli autori di compilatori a implementare l'analisi più facilmente". Penso che sia praticamente tutto. Le parole chiave sono state inventate per ridurre la quantità di contesto che un parser deve conservare in memoria, quando l'intero compilatore e il suo set di lavoro dovevano adattarsi a una dozzina di KB di RAM.

— Jörg W Mittag

2

È più facile scrivere un parser per APL di quasi qualsiasi altra lingua! Considera che la prima implementazione di un interprete APL è stata fatta usando transistor e diodi.

— James Anderson

2

Penso che il motivo principale delle parole chiave sia quello di rendere più facile per gli umani analizzare la lingua più facilmente. I computer sarebbero più felici se la lingua consistesse interamente di numeri e modelli di bit proprio come il loro codice macchina.

— James Anderson,

6

Ciò che manca di APL nelle parole chiave, è più che compensato nel richiedere il proprio carattere.

— Blrfl

@Blrfl Questo è il punto di J, K e Q. Sono tutti in un modo o nell'altro, APL in ASCII.

— Ingegnere mondiale

9

Una lingua ben nota senza parole chiave è Lisp. La cosa più vicina alle parole chiave sono i cosiddetti moduli speciali - il loro numero può variare tra dialetti - che ricevono un trattamento speciale dall'interprete. A parte ciò sono indistinguibili dalle normali funzioni in termini di come vengono utilizzati, ad eccezione del fatto che non possono essere ridefiniti (almeno in Lisps ho familiarità).

Ciò si traduce in una sintassi semplice (ma paren-heavy) ed è una delle cose che ha permesso a Lisp di avere un sistema macro così potente. D'altra parte, si dice spesso che Lisp sia difficile da leggere. APL e MUMPS, ancora di più, ho visto entrambi descritti a metà strada verso Brainf * ck. Le parole chiave aiutano in questo dipartimento e facilitano la lettura del codice anche per noi umani.

Quindi non direi che le parole chiave sono necessarie per una lingua di successo, ma sicuramente aiutano una lingua per avere successo.

— scrwtp
fonte

1

IIRC Lisp NON ha parole chiave. I moduli speciali devono essere trattati appositamente dal compilatore, ma i loro nomi sono simboli regolari.

— Jan Hudec,

2

Le parole chiave sono una caratteristica della sintassi, che neanche Lisp ha. Non penso che abbia senso parlare di parole chiave in Lisp, davvero.

— Jörg W Mittag

2

Sono d'accordo con Jörg. Penso che si possa parlare di parole chiave quando una lingua ha token che devono essere definiti esplicitamente come speciali per essere distinti da token con una struttura simile. Token diversi portano a diversi alberi di sintassi. Ad esempio, ifin C sarebbe un identificatore valido se non fosse definito speciale (una parola chiave). Ciò significa che ifnon è un identificatore e if = 10genera un errore di sintassi. Se non mi sbaglio, la sintassi minima di Lisp non distingue defunda f, x, ye +in (defun f (x y) (+ x y)).

— Giorgio

@Giorgio in particolare if è un nome di variabile valido in Common Lisp (e altri Lisp-2) (defparameter if nil)non romperà nulla e può essere utilizzato in forme come(unless if (setf if t))

— tobyodavies

Sulla stessa nota, tuttavia, (defun if ...)fallirà. Ha preso appunti dai commenti e ha modificato la risposta. Posso essere d'accordo sul fatto che i moduli speciali non sono parole chiave allo stesso livello di C, ad esempio, ma sono la cosa più vicina a Lisp.

— scrwtp

8

TCL non ha parole chiave, e in effetti solo 12 regole di sintassi. anche se non è così popolare come una volta, ha la sua nicchia con aspettarsi e incorporato in ECAD e router, quindi certamente conta come pratico per la mia mente.

Penso anche che possa mostrare perché molte lingue non seguono questa strada. Sì, è perfettamente possibile scrivere un parser TCL (probabilmente più facile di molte altre lingue), tuttavia non è possibile scrivere una grammatica BNF molto utile per la lingua e molte persone sembrano avere problemi nell'apprendimento della lingua. Sospetto che ciò sia almeno in parte dovuto alla mancanza di parole chiave.

— jk.
fonte

2

Tcl è molto simile a Lisp in questo senso, tranne che per "tutto è un elenco" ha "tutto è una stringa". Una lista è solo una stringa con spazi bianchi e una chiamata di procedura è solo una lista il cui primo elemento è interpretato come il nome di una procedura e il resto è interpretato come i suoi argomenti. Questa è essenzialmente una S-Expression Lisp.

— Jörg W Mittag

sì, entrambi usano la notazione polacca e sono omo-iconici, quindi hanno una semantica abbastanza simile

— jk.

5

I computer sono abbastanza potenti oggi per essere in grado di dedurre significati dal contesto.

Questo significa che vuoi una grammatica che non sia senza contesto? In bocca al lupo.

Non si tratta di essere potenti o no. Ci sono regole eterne e immutabili sui linguaggi - quelli matematici. Questo e il fatto che un linguaggio di programmazione dovrebbe essere sintatticamente semplice renderà la regola dei CFG per alcuni decenni a venire.

A proposito, in Haskell come la sintassi, scrivi semplicemente qualcosa del genere

f x y = (x+1)*(y-1)

per definire una funzione. Ma osserva che la "parola chiave" in questo caso è "=". Se lo manchi, nel parser accadranno cose terribili.

Ma questo è un punto in cui sono d'accordo con te, lo trovo molto più intuitivo di tutte le parole chiave def, dcl, fun, fn, function o what-not che introducono funzioni in altre lingue.

Tuttavia, questa grammatica può essere scritta nel vecchio e semplice LALR (1), qui nessun significato è "dedotto dal contesto".

— Ingo
fonte

1

+1 per affrontare questa affermazione (i computer sono abbastanza potenti oggi da essere in grado di dedurre significati dal contesto). Penso che il motivo per cui le grammatiche di CFG siano preferite sia che permettano di definire induttivamente la struttura del programma. Non vedo perché uno vorrebbe cambiare questo anche tra 100 anni, forse mi manca solo l'immaginazione?

— Giorgio

2

I CFG sono piuttosto morti, ed erano morti da decenni. JavaScript all'interno di HTML, anche stringhe di formato C all'interno di C, persino commenti nidificati in, diciamo, OCaml - tutto ciò non è privo di contesto. E perché dovresti limitarti a un formalismo scelto così arbitrariamente, ora, in un'epoca di PEG e GLR?

— Logica SK

1

@Ingo, sì, hai ragione, una scelta sbagliata di un esempio. Intendevo grammatiche miste ed estensibili (cioè di alto ordine), che non sono CFG.

— SK-logic

2

@ SK-logic: non so dove hai trovato le informazioni che i CFG sono piuttosto morti. Ho parlato con un mio ex collega che ha insegnato costruzione di compilatori negli ultimi 20 anni e CFG sembra essere tutt'altro che morto.

— Giorgio

1

@Ingo: per quanto ricordo, gli aspetti non CF vengono successivamente gestiti analizzando l'albero di analisi semanticamente. Ad esempio, { int x = 0; x = "HELLO"; }dovrebbe produrre un albero di analisi ma quando il compilatore cerca x nella seconda assegnazione, vede che è stato dichiarato come int e genera un errore di tipo. Quindi il programma viene rifiutato anche se la sua struttura CF è corretta.

— Giorgio

4

Per quanto ne so, Smalltalk è la lingua che ha meno parole chiave (se non conto le lingue come Brainfuck). Smalltalk parole chiave sono true, false, nil, self, supere thisContext.

Ho progettato una lingua, ispirata a smalltalk, che non aveva parole chiave. Ma dopo un po 'di tempo, ho finito per aggiungere alcune parole chiave, principalmente per lo zucchero sintattico.

Quindi, la mia opinione è che la lingua senza parole chiave è possibile, ma non è molto pratica e questo è il motivo per cui tutte le lingue popolari hanno parole chiave.

— del-boy
fonte

Se Smalltalk avesse il supporto per l'invio di messaggi con un ricevitore implicito, almeno true, falsee nilpotrebbe essere definito come metodi su quel ricevitore implicito e, date le capacità di riflessione, probabilmente anche gli altri tre.

— Jörg W Mittag

1

Quelle non sono parole chiave, sono pseudovariabili. "Pseudo" perché true, falsee nilsono valori noti forniti dall'ambiente e self, supere thisContextsono variabili che non è possibile impostare ma i cui valori cambiano a seguito dell'esecuzione.

— Frank Shearar,

3

Sembra che tu stia lavorando su un falso presupposto, che le parole chiave sono lì per rendere le cose più facili per il compilatore. Mentre rendono le cose più facili per il compilatore, hanno un vantaggio molto più importante: rendono le cose più facili per la persona che legge il codice .

Sì, potresti guardare un sacco di contesto e capire che stai guardando una dichiarazione di funzione o una dichiarazione di variabile, ma a seconda del contesto e della complessità del codice coinvolto, che potrebbe richiedere molto tempo per capire . Oppure, potresti avere una parola chiave a portata di mano come funzione o var , e sai subito cosa stai guardando.

Sì, rendono il codice più complicato da scrivere , ma considerando che i programmi impiegano molto più tempo nella manutenzione che nella produzione e che il loro codice viene letto, sottoposto a debug e mantenuto molto più di quanto non sia stato creato, cercando di progettare la tua lingua per semplificare la scrittura anziché la lettura è un classico caso di ottimizzazione prematura dannosa.

Inoltre, non disdegnare concetti che semplificano il lavoro del compilatore. Più facile è analizzare, più veloce sarà la compilazione del codice, il che significa che i cicli di modifica-build-debug diventano più veloci, il che significa che la tua produttività aumenta.

Quando si dispone di una base di codice ampia e complessa, ciò può comportare una differenza non banale nella produttività. Ad esempio, dove lavoro abbiamo un programma al lavoro che è di circa 4 milioni di linee di Delphi. Abbiamo un altro modulo di circa 300.000 linee di C ++. Entrambi richiedono lo stesso tempo per la compilazione. (Circa 3 minuti). Se avessimo 4 milioni di linee di C ++, la costruzione potrebbe richiedere un'ora!

— Mason Wheeler
fonte

Tutti i punti eccellenti. +1

se ogni sostantivo, verbo, avverbio e aggettivo in un romanzo fosse etichettato come tale, renderebbe PIÙ difficile leggere!

@JarrodRoberson: Certo, lo sarebbe, ma il codice non è un romanzo. I linguaggi naturali sono molto diversi dai linguaggi di programmazione. Il linguaggio naturale è compreso intuitivamente, mentre un linguaggio di programmazione ha una semantica formale. Le tecniche utilizzate per leggerlo e comprenderne il significato sono molto diverse, ed è un errore cercare di equiparare i due come fai tu.

— Mason Wheeler

Ho detto che lo scrittore del compilatore è diverso dal compilatore . I compilatori diventano più veloci su hardware più veloce, gli autori di compilatori sono umani, non aderiamo alla Legge di Moore!

le basi di codice con cui tendo a lavorare sono ordini di grandezza più lunghi dei romanzi di lunghezza, la maggior parte sono più di 1.000.000 di righe di codice, la maggior parte dei romanzi più lunghi sono <2.000.000 di parole ! E come i romanzi che vengono letti dagli umani, in realtà passa più tempo a leggere il codice che a scriverlo! Data una base di codice che ha> 10 anni e oltre 1.000.000 di righe, il numero di volte che viene letto dagli sviluppatori in 10 anni diminuisce il tempo impiegato per creare in primo luogo.!

2

Ci sono alcuni esempi rari.

APL utilizza solo simboli, ma molti di loro! È necessaria una tastiera speciale per utilizzare la lingua.

Vedi questo articolo di Wikipedia

CORAL 66 - aveva parole chiave ma le riconosceva solo se citate tra virgolette singole.

PL / 1 aveva anche parole chiave, ma potevi anche usarle come nomi di variabili o procedure.

Tutto sommato, però, la tua domanda è un po 'come chiedere "perché le lingue parlate hanno parole?".

— James Anderson
fonte

Solo per aggiungere che se ti piace l'aspetto di APL ma non vuoi acquistare una nuova tastiera, allora J è la cosa giusta.

— AakashM

0

Il motivo principale è che è più facile analizzare sia gli umani che i computer. Disambiguare un linguaggio complesso senza parole chiave richiederebbe molti simboli come sintassi e sarebbe confuso in modo massiccio e inutile. È molto più facile da leggere functiondi $!{}. E il contesto non risolve tutte le ambiguità.

— DeadMG
fonte

1

Penso che la parola chiave nella tua risposta sia complessa , un linguaggio sufficientemente progettato dovrebbe essere semplice , non complesso .

1

@Jarrod Roberson: Leonardo da Vinci: "La semplicità è la massima raffinatezza", Antoine de Saint Exupéry: "Sembra che la perfezione non sia raggiunta quando non c'è più niente da aggiungere, ma quando non c'è più nulla da togliere".

— Giorgio

1

@Jarrod: tutti i linguaggi per computer significativamente espressivi sono complessi.

— DeadMG

1

@DeadMG: lo schema è molto semplice e allo stesso tempo molto espressivo. Sfortunatamente, per quanto ne so, manca una libreria standardizzata.

— Giorgio

Erlang è molto espressivo e non complesso sintatticamente. Penso che tutti i linguaggi funzionali finiscano per essere più espressivi con parole chiave meno riservate.