25

I have been searching for a practical programming language that has no reserved keywords but I haven't had any luck finding one.

I am working on a programming language for my own edification and entertainment and I haven't needed to include any keywords yet, that is what led me to my search and the question:

I don't see convenience to the compiler writer as being important to the end user of the language. Computers are powerful enough now days to be able to infer meanings from context. No more than a writer needs to label nouns, verbs and such when writing a novel, why should a programmer have to label functions and variables with function x() {} or set x = 1 or var x = 1 etc; when I can infer from the context of the statements that it is a function declaration or an invocation or that a label is an assignment to a value or a reference to that labels value?

Here is a concrete example of what my current parser is doing, no need for reserved keywords to support common things that would normally have a bunch of noise like func or function or dec or what not.

Function Declaration

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

Function Invocation

x = sum3(1,2,3).

Anonymous Function Named x

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

I would like to know why are keywords that important to a successful programming language?

  • 9
    Forth is pretty practical, and it does not have any keywords. – SK-logic Mar 08 '13 at 08:34
  • @SK-Logic, don't IF and ELSE count as keywords in FORTH? – James Anderson Mar 08 '13 at 10:46
  • 4
    @JamesAnderson, no, they're just words, same as all the other words. No special meaning whatsoever. – SK-logic Mar 08 '13 at 11:14
  • 7
    Do operators and punctuation count as "keyword"? if yes, then no language may exist, since no syntax can be defined. – Emilio Garavaglia Mar 08 '13 at 13:04
  • "What non theoretical practical programming language": How do you define **theoretical** and **practical** programming languages? – Giorgio Mar 08 '13 at 13:20
  • @EmilioGaravaglia, usually, only things which are syntactically similar to identifiers are called "keywords". – SK-logic Mar 08 '13 at 14:31
  • 2
    @SK-logic: usually. But what are "identifiers" if you dint't tokenize yet? Since a token is "whatever recognizable sting", "int", "myvalue" and "+" are not different, before a syntax rule had been given. If "+" is not defined as operator, it can be just a name for a thing like whatever other unicode single character string. Operators, by a pure syntax stand point, are nothing more that "single character keywords". – Emilio Garavaglia Mar 08 '13 at 14:38
  • 1
    @EmilioGaravaglia, you don't actually have to tokenise before you can distinguish "keywords" from "identifiers". Normally, it only means that a keyword is something that conforms to the same regular expression as identifiers. But, yes, the definition is pretty vague and artificial. Even the "token" definition itself is vague. – SK-logic Mar 08 '13 at 14:41
  • 2
    In this context, what's a keyword? Is it an identifier that has special meaning to the compiler? Is it an identifier that the programmer shouldn't use as a variable or something? Does it count as keywordless if keywords have to be specially designated? (A LONG time ago I saw an ALGOL system where keywords needed to be quoted to be keywords.) – David Thornley Mar 08 '13 at 22:55
  • 1
    @MattDavey: It is a Big List™ question. I've edited the title to make the question clearer. – Robert Harvey Mar 08 '13 at 23:12
  • 2
    Question edits have made the answers below incomprehensible. Five provide examples of keyword-free languages while three try to tackle the "why are keywords important?" variant. – Corbin March Mar 08 '13 at 23:29
  • 1
    The following is valid PL/I - a non-theroetical (at one time) practical programming language with no reserved words. `IF IF = THEN THEN THEN = ELSE; ELSE ELSE = IF;` This should be reason enough to understand why reserved words are good. –  Mar 09 '13 at 01:55
  • @MichaelT that isn't a problem if the language doesn't have a C-style `if/then/else` construct! :-) –  Mar 09 '13 at 01:57
  • @Jarrod: Then how do you represent an if/then/else conditional statement, which is a necessity in any non-trivial program, in an intuitive, easy-to-understand way? – Mason Wheeler Mar 09 '13 at 02:49
  • 2
    simple pattern matching does away with `if/then/else` as well as `switch` constructs as well as traditional `for/each` loops. –  Mar 09 '13 at 03:09
  • your question sounds contradictory, could you elaborate a bit on that? Look, "computers are powerful enough now days" somehow suggests that earlier, languages inferring from context just could not be successful for computers being _not_ powerful enough. This sort of self-answers why you "haven't had any luck finding... _practical_ programming language" doesn't it? – gnat Mar 09 '13 at 07:59
  • Fortran is another language that never had reserved words. – Vladimir F Героям слава Sep 20 '13 at 09:01

8 Answers8

13

MUMPS is highly successful, being widely used in insurance and healthcare and and has no reserved words. I'd say they help in terms of writing clearer code but they aren't strictly necessary. APL is another example. APL sees use for one-off scripts in the Nuclear Industry amongst others. J, a member of the APL family also lacks keywords.

Keywords help compiler writers implement parsing more easily. APL is famously right associative. They also help reinforce conventions and improve readability. APL is not known for being hugely readable to most.

  • 2
    +1 for "Keywords help compiler writers implement parsing more easily". I think that's pretty much it. Keywords were invented to cut down on the amount of context a parser has to keep in memory, back when the entire compiler plus its working set had to fit into a dozen KB of RAM. – Jörg W Mittag Mar 08 '13 at 05:38
  • 2
    Its easier to write a parser for APL than almost any other language! Consider that the first implementation of an APL interpreter was done using transistors and diodes. – James Anderson Mar 08 '13 at 08:23
  • 3
    I think the main reason for keywords is to make it easier for humans to parse the language more easily. Computers would happier if the language consisted entirely of numbers and bit patterns just like their machine code. – James Anderson Mar 08 '13 at 10:48
  • 6
    What APL lacks in keywords, it more than makes up for in requiring its own font. – Blrfl Mar 08 '13 at 12:58
  • @Blrfl That's the point of J, K, and Q. They are all to one degree or another, APL in ASCII. –  Mar 08 '13 at 20:50
10

One well known language without keywords is Lisp. The closest thing it has to keywords are so called special forms - their number may vary between dialects - that get special treatment from the interpreter. Apart from that they are indistinguishable from regular functions in terms if how they are used, with the exception that they can't be redefined (at least in Lisps i'm familiar with).

This results in a simple (but paren-heavy) syntax, and is one of the things that enabled Lisp to have such a powerful macro system. On the other hand, Lisp is often said to be hard to read. APL and MUMPS, even more so, I've seen both described as halfway to Brainf*ck. Keywords do help in this department and make reading code easier for us humans too.

So I wouldn't say keywords are required for a successful language, but they sure help a language to become successful.

scrwtp
  • 4,532
  • 1
  • 24
  • 29
  • 1
    IIRC Lisp has NO keywords. The special forms have to be treated specially by the compiler, but their names are regular symbols. – Jan Hudec Mar 08 '13 at 10:24
  • 2
    Keywords are a feature of the syntax, which Lisp doesn't have either. I don't think it even makes sense to talk about keywords in Lisp, really. – Jörg W Mittag Mar 08 '13 at 12:41
  • 2
    I agree with Jörg. I think one can speak about keywords when a language has tokens that must be defined explicitly as special to be distinguished from tokens with a similar structure. Different tokens lead to different syntax trees. For example, `if` in C would be a valid identifier if it were not defined to be special (a keyword). This means that `if` is not an identifier and `if = 10` gives a syntax error. If I am not mistaken, Lisp's minimal syntax does not distinguish `defun` from `f`, `x`, `y` and `+` in `(defun f (x y) (+ x y))`. – Giorgio Mar 08 '13 at 13:18
  • @Giorgio notably `if` *is* a valid variable name in Common Lisp (and other Lisp-2s) `(defparameter if nil)` won't break anything and it can be used in forms like `(unless if (setf if t))` – tobyodavies Mar 09 '13 at 05:53
  • On the same note, though, `(defun if ...)` will fail. Taken notes from comments into account and edited the answer. I can agree that special forms are not keywords on the same level as in C for example, still they're the closest thing Lisp has. – scrwtp Mar 09 '13 at 08:46
8

TCL has no key words, and indeed only 12 syntax rules. while its not as popular as it once was, it has its niche with expect and embedded in ECAD and routers so it certainly counts as a practical to my mind.

I also think it may show why lots of languages don't go this route. Yes its perfectly possible to write a TCL parser (arguably easier than many other languages) however you can't write a very useful BNF grammar for the language and many people seem to have trouble learning the language. I suspect this is at least partly because of lack of keywords.

jk.
  • 10,216
  • 1
  • 33
  • 43
  • 2
    Tcl is very similar to Lisp in this regards, except instead of "everything is a list" it has "everything is a string". A list is just string with whitespace in it and a procedure call is just a list whose first element is interpreted as the name of a procedure and the rest are interpreted as its arguments. That's essentially a Lisp S-Expression. – Jörg W Mittag Mar 08 '13 at 12:43
  • yes they both use polish notation and are homo-iconic so have pretty similar semantics – jk. Mar 09 '13 at 09:10
5

Computers are powerful enough now days to be able to infer meanings from context.

Does this mean you want a grammar that is not context free? Good luck.

It's not a question about being powerful or not. There are eternal, unchanging rules about languages - mathematical ones. This, and the fact that a programming language should be syntactically easy will make CFGs rule for some decades to come.

Btw., in Haskell like syntax, you just write something like

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

to define a function. But observe that the "keyword" in this case is the '='. If you miss it, terrible things will happen in the parser.

But this is a point where I agree with you, I find this much more intuitive than all the def, dcl, fun, fn, function or what-not keywords that introduce functions in other languages.

Yet, this grammar can be written in plain old LALR(1), no meaning is "inferred from the context" here.

Ingo
  • 3,903
  • 18
  • 23
  • 1
    +1 for addressing this statement (Computers are powerful enough now days to be able to infer meanings from context). I think the reason why CFG's grammars are preferred is that they allow program structure to be defined inductively. I do not see why one would like to change this even in 100 years, maybe I just lack imagination? – Giorgio Mar 08 '13 at 15:06
  • 2
    CFGs are pretty dead, and had been dead for decades. JavaScript inside HTML, even C format strings inside C, even nested comments in, say, OCaml - all this stuff is not context free. And, why would you want to restrict yourself to such an arbitrary chosen formalism, now, in an age of PEG and GLR? – SK-logic Mar 08 '13 at 15:13
  • @Giorgo - no, I think the same. CFG is an ideal middleground: you can make provably correct (and fast) parsers. And, humans can learn the syntax easily. – Ingo Mar 08 '13 at 15:14
  • @SK-logic Huuh, you must be kidding. Since when is embeding one CFG into another not CF? I suspect you mean "not regular" when you speak of nested comments. – Ingo Mar 08 '13 at 15:17
  • 1
    @Ingo, yes, you're right, a wrong choice of an example. I meant *mixed* and *extensible* (i.e., high-order) grammars, which are not CFG. – SK-logic Mar 08 '13 at 15:27
  • @SK-logic would like to see applications thereof, I am still convinced that grammars may be too easy like the language S -> 0 S|1 S|E, or something like LISP: it's then hard to read for the lack of structure. Or, it maybe ambiguos, which makes it also hard for humans to recognize. An ideal grammar is one that goes unnoticed by the user (after a bit of training, of course), just like the grammar of your mother's tongue - you want to expend energy on the message, not on the structure of the message. And yet, there must be structure to make understanding possible. – Ingo Mar 08 '13 at 16:01
  • @Ingo: Lisp has a very simple grammar compared to other languages but it is still CFG. That's what allows to construct a fast parser that can recognize inductive (tree-like) program structures. – Giorgio Mar 08 '13 at 16:37
  • 2
    @SK-logic: I do not know where you got the information that CFG's are pretty dead. I have been speaking to a former colleague of mine who's been teaching compiler construction for the last 20 years and CFG's seem to be far from dead. – Giorgio Mar 08 '13 at 16:38
  • @Giorgio most actual languages do not seem to be CF though as even if they have extensive CFGs they tend to need additional rules outside of the grammar – jk. Mar 08 '13 at 22:52
  • @jk - You mean hacks like in the C parser? Others have some additional rules to avoid parsers with lookaheads > 1. This could be expressed in a CFG. But it's all about speed these times, where you need to parse the source every time some key is hit in the IDE. – Ingo Mar 08 '13 at 22:57
  • 1
    @Ingo: As far as I remember, the non CF aspects are handled afterwards by analysing the parse tree semantically. E.g., `{ int x = 0; x = "HELLO"; }` should produce a parse tree but when the compiler looks up x in the second assignment it sees that it has been declared as an int and issues a type error. So the program is rejected even if its CF structure is correct. – Giorgio Mar 08 '13 at 23:09
4

As far as I know, Smalltalk is the language that has least keywords (if I am not counting languages like Brainfuck). Smalltalk keywords are true, false, nil, self, super and thisContext.

I have designed a langage, inspired with smalltalk, that had no keywords. But after some time of using it I ended up adding a few keywords, mostly for syntactic sugar.

So, my opinion is that language without keywords is possible, but it is not very practical and that is the reason why all popular languages have keywords.

del-boy
  • 159
  • 3
  • If Smalltalk had support for message sends with an implicit receiver, then at least `true`, `false` and `nil` could be defined as methods on that implicit receiver, and, given the reflection capabilities, the other three probably as well. – Jörg W Mittag Mar 08 '13 at 05:31
  • 1
    Those aren't keywords, they're pseudovariables. "Pseudo" because `true`, `false` and `nil` are well-known values supplied by the environment and `self`, `super` and `thisContext` are variables you can't set but whose values change as a result of execution. – Frank Shearar Mar 09 '13 at 09:01
3

You seem to be laboring under a false assumption, that keywords are there to make things easier for the compiler. While they do make things easier for the compiler, they have a much more important benefit: they make things easier for the person reading the code.

Yes, you could look at a bunch of context and figure out that you're looking at a function declaration or a variable declaration, but depending on the context and on the complexity of the code involved, that could take a long time to figure out. Or, you could have a handy keyword there like function or var, and you know immediately what you're looking at.

Yes, they make the code more complicated to write, but considering that programs spend a lot more time in maintenance than in production, and that their code is read, debugged and maintained a lot more than it is created, trying to design your language to make it easy to write instead of easy to read is a classic case of harmful premature optimization.

Also, don't disdain concepts that make the compiler's job easier. The easier it is to parse, the faster your code will compile, which means edit-build-debug cycles get faster, which means your productivity goes up.

When you have a large, complex codebase, that can amount to a non-trivial difference in productivity. For example, where I work we have a program at work that's about 4 million lines of Delphi. We have another module that's about 300,000 lines of C++. They both take about the same length of time to compile. (About 3 minutes.) If we had 4 million lines of C++, it could take an hour to build!

Mason Wheeler
  • 82,151
  • 24
  • 234
  • 309
  • All excellent points. +1 –  Mar 08 '13 at 23:32
  • if every noun, verb, adverb and adjective in a novel was labeled as such it would make it HARDER to read not easier! –  Mar 09 '13 at 01:53
  • @JarrodRoberson: Sure, it would, but code is not a novel. Natural languages are very different from programming languages. Natural language is *understood intuitively,* whereas a programming language has *formal semantics.* The techniques used to read it and understand the meaning of it are very different, and it's a mistake to try to equate the two like you do. – Mason Wheeler Mar 09 '13 at 01:59
  • I said **compiler writer** which is different from *the compiler*. Compilers get faster on faster hardware, **compiler writers** are human, we do not adhere to Moore's Law! –  Jan 18 '15 at 16:07
  • the code bases I tend to work with are orders of magnitude longer than novels in length, most are > 1,000,000+ **lines** of code, the most of the longest novels are < 2,000,000 *words*! And like novels they are read by humans, actually more time is spent reading code than writing it! Given a code base that is > 10 years old and 1,000,000+ lines the number of times it is read by developers over 10 years dwarfs the time it took to create in the first place.! –  Apr 30 '15 at 17:13
2

There are some rare examples.

APL uses only symbols -- but a lot of them! You need a special keyboard to use the language.

See this wikipedia article

CORAL 66 -- had keywords but only recognised them if they were quoted with single quotes.

PL/1 also had keywords -- but you could also use them as variable or procedure names.

All in all though your question is a bit like asking "why do spoken languages have words?".

James Anderson
  • 18,049
  • 1
  • 42
  • 72
  • Just to add that if you like the look of APL but don't want to buy a new keyboard, then [J](http://en.wikipedia.org/wiki/J_%28programming_language%29) is just the thing. – AakashM Mar 08 '13 at 08:45
0

The main reason is that it's easier for both humans and computers to parse. Disambiguating a complex language without keywords would require many symbols as syntax, and it would be massively and unnecessarily confusing. It's much easier to read function than $!{}. And context does not resolve all ambiguities.

DeadMG
  • 36,794
  • 8
  • 70
  • 139
  • 1
    I think the key word in your answer is *complex*, a sufficiently designed language should be *simple*, not *complex*. –  Mar 08 '13 at 16:30
  • 1
    @Jarrod Roberson: Leonardo da Vinci: "Simplicity is the ultimate sophistication", Antoine de Saint Exupéry: "It seems that perfection is reached not when there is nothing left to add, but when there is nothing left to take away". – Giorgio Mar 08 '13 at 17:23
  • 1
    @Jarrod: All meaningfully expressive computer languages are complex. – DeadMG Mar 08 '13 at 19:21
  • 1
    @DeadMG: Scheme is very simple and at the same time very expressive. Unfortunately, as far as I know it lacks a standardized library. – Giorgio Mar 08 '13 at 22:55
  • Erlang is very expressive and not complex syntactically. I think all functional languages end up being more expressive with less reserved keywords. –  Mar 09 '13 at 01:44
  • I've seen a little Scheme and some Haskell, and they are both in desperate need of keywords. – DeadMG Mar 09 '13 at 08:45
  • @Giorgio - I went to art school for 5 years, both of those are very familiar to me and not familiar to enough computer science majors. –  Feb 24 '16 at 18:55