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?

Improve this question
17
  • 9
    Forth is pretty practical, and it does not have any keywords.
    – SK-logic
    Mar 8, 2013 at 8:34
  • 4
    @JamesAnderson, no, they're just words, same as all the other words. No special meaning whatsoever.
    – SK-logic
    Mar 8, 2013 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 8, 2013 at 13:04
  • 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 8, 2013 at 14:38
  • 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 8, 2013 at 22:55

8 Answers 8

Reset to default
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.

Improve this answer
5
  • 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 8, 2013 at 5: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 8, 2013 at 8: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 8, 2013 at 10:48
  • 6
    What APL lacks in keywords, it more than makes up for in requiring its own font.
    – Blrfl
    Mar 8, 2013 at 12:58
  • @Blrfl That's the point of J, K, and Q. They are all to one degree or another, APL in ASCII.
    – user28988
    Mar 8, 2013 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.

Improve this answer
5
  • 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 8, 2013 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 8, 2013 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 8, 2013 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 9, 2013 at 5: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 9, 2013 at 8: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.

Improve this answer
2
  • 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 8, 2013 at 12:43
  • yes they both use polish notation and are homo-iconic so have pretty similar semantics
    – jk.
    Mar 9, 2013 at 9: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.

Improve this answer
11
  • 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 8, 2013 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 8, 2013 at 15:13
  • 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 8, 2013 at 15:27
  • 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 8, 2013 at 16:38
  • 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 8, 2013 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.

Improve this answer
2
  • 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 8, 2013 at 5: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 9, 2013 at 9:01
4

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!

Improve this answer
5
  • All excellent points. +1
    – user39685
    Mar 8, 2013 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!
    – user7519
    Mar 9, 2013 at 1: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 9, 2013 at 1: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!
    – user7519
    Jan 18, 2015 at 16:07
  • 1
    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.!
    – user7519
    Apr 30, 2015 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?".

Improve this answer
1
  • Just to add that if you like the look of APL but don't want to buy a new keyboard, then J is just the thing.
    – AakashM
    Mar 8, 2013 at 8: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.

Improve this answer
7
  • 1
    I think the key word in your answer is complex, a sufficiently designed language should be simple, not complex.
    – user7519
    Mar 8, 2013 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 8, 2013 at 17:23
  • 1
    @Jarrod: All meaningfully expressive computer languages are complex.
    – DeadMG
    Mar 8, 2013 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 8, 2013 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.
    – user7519
    Mar 9, 2013 at 1:44