7

I'm designing a programming language which has three kinds of quoted entities: strings and characters as in C, and symbols (interned strings intended for use as lookup keys and such) which I consider one of the most endearing features of Lisp. Currently I have the following syntax for these:

"*" // String '*' // Character `*` // Symbol

which I quite like, but has a couple of potential problems:

  1. I'm told that on some keyboard layouts, backquote is a nuisance to type.

  2. Backquote and ' are not the most visually distinct of characters, and I have a few times found myself typing ' when I meant backquote. On my setup this is not a problem because I have UltraEdit syntax highlighting set up to show backquoted symbols in green so the mistake is instantly apparent, but of course I can't provide syntax highlighting for most of the editors people use, so at least in the early days most users won't have the benefit of that kind of special coloring.

So, given these potential problems, I'd like to get some feedback on which option people consider preferable:

  1. Keep the syntax the way I have it now.

  2. Swap backquote and ', so that ' is used for symbols and backquote is used for character constants.

  3. Use ' for symbols, @"*" for character constants (in e.g. the Linux kernel code, character constants are something like thirty times rarer than string constants, so it's arguably okay to give them slightly more verbose syntax) and backquote for something else, perhaps raw (most escape codes not interpreted) strings.

  4. Use ' for symbols, @"*" for character constants and forswear the use of backquote entirely.

Improve this question
12
  • 1
    You might want to study Python's approach to this problem before inventing something that's too complex. Commented Feb 7, 2012 at 18:19
  • 1
    From what I've seen, Python uses both single and double quotes for strings, and doesn't have a separate notion of either characters or symbols; am I missing something? Commented Feb 7, 2012 at 18:27
  • 3
    Python does not have a need for character as a separate type. All strings are "interned". It's much simpler than the approach you're outlining. Keep reading. Commented Feb 7, 2012 at 18:31
  • 3
    "I do need these things". You're missing the point. You may not actually need the complexity you're designing. It's very difficult to justify non-interned strings and a separate character type. Commented Feb 7, 2012 at 19:15
  • 2
    Who cares if it is necessary or not. Lisp decided it was (ahem) necessary for such functionality, so why can't the OP? Fun fact: Mike Tyson invented Lisp. Commented Feb 7, 2012 at 21:29

4 Answers 4

Reset to default
2

I think the potential confusion is a serious problem. If you already find yourself confusing backquote and single-quote, think how many future code writers and readers will make the same mistake.

Many languages that use backquotes as special syntax seem to reserve them for comparatively rare usage. I could speculate why, but if you expect symbols to get heavy usage, you could take this as a cue to use some other syntax.

So, for the multiple choice bonus question, I would prefer #3 or #4 over #1 or #2, for anti-confusion reasons. You can keep backquotes in reserve for when you need an extra-special quotelike operator...

Improve this answer
1
  • I agree. I've concluded S.Lott is right, I don't need so many options, because it's fine for all string constants to be interned, so I'll just use single quotes for interned strings/symbols. Commented Feb 9, 2012 at 23:00
3

If you're introducing a new concept (symbols) into a familiar syntax, why not introduce new notation along with it? For example, within the rules of your lexer you could use a single lead-in character for a simple symbol name:

$symbol $this_could_also_be_a_symbol_name

For arbitrarily named symbols, a symbol("$ymbol w1th 4rbitrary n4m3") compile-time construct could provide the needed flexibility. It might even be useful to have a function that constructs symbols at runtime, depending on the semantics of your language.

It occurs to me that Ruby does almost exactly this using ::

:symbol :this_could_also_be_a_symbol_name :'$ymbol w1th 4rbitrary n4m3'
Improve this answer
2
  • 1
    $ is a poor choice as well, because it’s inconvenient to type on many northern and eastern European keyboard layouts. Besides, : looks better anyway. Commented Feb 9, 2012 at 0:32
  • 2
    To be honest most non-QWERTY layouts hardly make any sense when it comes to programming. I'm in Europe but my keyboard is definitely QWERTY... (and I do "compose" the "euro characters with diacritical marks" when I do need them). Commented Mar 20, 2012 at 17:33
0

Smalltalk also has a distinction between the three things, and uses this syntax:

'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"

Aside from the potential difficulty of getting at some symbols (sorry Euro-folks!) it does have the unconventional but pleasant syntax of using single-quotes for strings, since it doesn't (on an American keyboard) require a shift-key press to get at and you type a lot more strings than characters (comments using the double-quote is a bit odd, but arguably people put up with longer key strokes for comments since they are typed in a different mindset than code.)

There are really several ways you can handle it, but keep in mind the rarity and use cases for each type. Strings will get used a lot, and should have the easiest syntax. Characters are rarer to use. Symbol-usage will depend on how much meta-programming your language allows or requires.

You can also do some trickery at compile-time, depending on how much type-checking you've got you might be able to convert a single-character string to a char or a char to a single-character string as needed with implicit casting. In most high-level languages, the needs to directly utilize an actual char type are fairly uncommon.

Another option is to use tagged strings. C#, for example, has "regular strings" and @"non-escaping strings that ignore things like \n". The D language uses r"this is a string" for the same purpose. Those are very good for symbol heavy strings like regexps or directory names. You could use c"A" for characters and s"symbol" for symbols. Letters as operators is tricky business, but it makes for a very easy mnemonic for the programmer, and shouldn't be hard to lex since a string literal would never directly follow a symbol without whitespaces in most languages.

Improve this answer
1
  • I never found shifted quotes difficult on any keyboard layout, whether to the right of semicolon or on the "2" key. String literals, however, would strike me as being more likely to need apostrophes inside than quotation marks. Personally, I liked the Vax BASIC approach of allowing either single or double quotes to be used for strings, thus allowing either "There can't be a problem here" or 'He said "Hi"'. Commented May 12, 2014 at 13:27
-1

Since an instance of the char type is only one character long, do you really need to enclose it in matching marks? If you bracket symbols in apostrophes, you can use only a single backquote to precede a char. If the user mixes them up, large syntax error messages follow, like when a C programmer forgets a closing brace.

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.