[erlang-questions] Re: Special syntax for dictionaries

[Richard O'Keefe]

On May 7, 2010, at 12:41 AM, Tim Fletcher wrote:
>
> Parentheses. British usage of the word "brackets" usually means
> parentheses. Sorry for the additional confusion.

My dialect/chronolect is fairly close to British.
However, I learned early on that talking about "brackets"
was EXTREMELY error-prone.  I try to redundantly say
	round parentheses
	square brackets
	curly braces
	angle brockets
to be unambiguous.  The OED (www.oed.com) says
	One of two marks of the form [ ] or ( ),
	and in mathematical use also {}, used for enclosing
	a word or number of words, a portion of a mathematical
	formula, or the like, so as to separate it from the
 >>>	context; in typography, esp. applied to ‘square brackets’
 >>>	(formerly called crotchets), the ‘round brackets’ being
 >>>	designated ‘parentheses’.
So the distinction between "brackets" and "parentheses" is not
confined to (careful!) programmers.  It looks as though people
working in an area where it *matters* which kind of paired
symbols you use distinguish between brackets and parentheses,
whereas people working in an area where it doesn't (like it
doesn't really matter whether you use (Freddo, 1633) or
[Freddo, 1633] for citations) use brackets for both indifferently.

For what it's worth, it was the >>European<< programming language
Algol that taught me the importance of the distinction.

> Just because syntax might be a relatively trivial issue does not mean
> that it can't be discussed and alternatives considered/compared. I
> don't have anything to add to the "more important" discussion on
> "should we add frames/structs?" because I think they are a sound idea
> in principle and would much prefer using them to records.

There are none-the-less some important semantic questions.
>
> It is also my opinion that using a tilde is not the best syntax to use
> for seperating the keys and values.

Believe me, I've looked for something better, and there _isn't_  
anything.

> Whilst it can't be confused with
> any existing syntax, I don't think it makes the meaning of the code
> very clear. Looking at <{foo ~ bar}> doesn't make me think of "a key/
> name mapped to a value". It looks more like some binary operator.

Well, if it comes to that, << makes me think of "very much less than"
and "left shift".  It *certainly* doesn't suggest "binary" to me.
*Anything* you put between the label and the value of a maplet is
going to look like some binary operator, in fact from a grammatical
point of view it's going to BE a binary operator.  The important
thing is that it not look like some EXISTING binary operator in the
language.

And I repeat: this is a notation that HAS been used before.
If it doesn't suggest "maplet" to you because you're not familiar
with the relevant work at Xerox PARC, it's not the fault of the
notation.

There *is* a Unicode character which is perfect for the job.
U+21A6 ↦ looks like exactly the maplet character.
Back in 2003 I couldn't type Unicode characters into a mail message.
In fact, I *still* can't, I have to use Insert|Special characters|...
which is a pain in the neck.  (It makes \mapsto a marvel of
usability.)

Realistically, one is often looking at
	<{ foo ~ SOME HAIRY EXPRESSION
	 , bar ~ ANOTHER HAIRY EXPRESSION
	 , ugh ~ YET A THIRD
	}>
It's pretty obvious what's going on (as long as we don't use : or =
or ->).

Oh, the use of <{ ... }> was inspired by
  - these things are sets of pairs, so {...} is appropriate
  - I've seen overstruck  < (  ...  ) > used for string quotes