Javascript's innate number type is but an approximation - everybody will agree. But the serialization of those numbers in JSON makes it worse. For example, what is really meant with 0.67, 0.667, ... , 0.66666666666667 ? Does 0.67 mean exactly 67 cents and is 0.66666666666667 to be understood as an approximation of 2/3? And does 0.667 also stand for 2/3? What does the number of decimals tell about the underlying intentions? JSON should have a standardized notation for lossless serialization of floating point type numbers. Even C has that: the %a printf format for double in hexadecimal notation. And talking about shortcomings in JSON: please also provide a notation for bignums - both integer and rational ones.

Yes, I found that piece of Bracmat code on Stackoverflow. The accompanying comment is: "this programming language Bracmat [code that is cited] beats Perl in terms of line noise". I understand the sentiment, so I quoted it in the README.md file as a (self-)ironic note. The code snippet has to do with checking IBAN numbers and is not in the domain where I use Bracmat most often. For an example of Bracmat that shows its strengths, see the "Dinesman's multiple-dwelling problem" on Rosettacode. A serious application that is written in Bracmat is the Text Tonsorium.

Fortran, ALGOL-60, ALGOL-68: no fun at all.
Simula-67: I wouldn't say fun, but very mysterious and inspiring.
Basic was fun in the 80s, as was Z80 machine code (not Assembler).
Pascal (Delphi), Python, and Java: Never liked them because they give you points if you sit straight and are well-behaved. They get it wrong. No fun at all.
Cobol: Fun if you read source code written by a physics professor. So mostly for other people to write.
PL/1: Fun. You could have a string with a negative length and append it to another string.
C, PHP, Javascript: not fun, but a lot of freedom, so OK after all.
C++, C#: They do not fit in my brain case, leaving no room for fun. C# tries to become better at pattern matching. Points for that.
Bracmat: my workhorse, still much fun.
The winner is Snobol 4. So unorthodox. But that was back in the 80s.

I did it almost the same way, but decided not to multiply 144 by 5, since I knew I was going to divide by 5, since 365 is dividable by 5. So:

((12-2)²+(12-1)²+12²+(12+1)²+(12+2)²)/365 = (144+(2*(2²+1²))/5)/(365/5) = (144+10/5)/73=146/73 = 2

When lines become long, I split before a binary operator, and make sure that binary operators always are in the same line, or, if the line is split, in the same column as the parentheses, if there are any. In addition, I usually put like binary operators in the same column. If a line is split at a binary operator, I indent both operands by the same amount, e.g. two characters to the right. Like so:

OutputImage
( file
, allFaces
. Where
( f
=> f.Proportion
> double.Parse(ConfigurationManager.AppSettings["LowerBound"].ToString())
&& f.Proportion
< double.Parse(ConfigurationManager.AppSettings["UpperBound"].ToString())
)
. ToList()
. OrderBy(f => f.Proportion)
. ThenByDescending(f => f.Rectangle.Height)
. FirstOrDefault()
);

While a rational number type has both advantages and disadvantages and we can discuss that forever, it is an undeniable truth that JSON should have had a rational number type, simply because some languages or libraries already support rational numbers and there should exist a portable way for applications using rational numbers to serialize and exchange these with other applications. A rational number that is within the range of a floating point number type can always be "downgraded" to that floating point number type, but the converse is problematic. For example, is the JSON expression [0.67,0.33] an array with the numbers 2/3 and 1/3 ? If not, then what about [0.6666666666666667,0.3333333333333333]? It would have been clear what was meant if we were allowed to write [2/3,1/3].

Neither Perl or Scala can solve this simple problem with a simple pattern: Given a list of pairs, each pair consisting of a first name and a family name, give me two names of different persons that have the same family name. I think [Tom](<a href=)[^] (a cousin of Scala, I think) can do it, but the syntax of patterns in that language is very verbose. In Bracmat, you would do: (Abel.Hirst) (Benjamin.Foster) (Letty.Johnson) (George.Hanson) (Chris.Johnson) (Priscilla.Stein):?list; !list:? (?name1.?familyName) ? (?name2.!familyName) ? & out$(!name1 and !name2 "have the same family name (" !familyName ")") | out$"No two persons have the same family name"; which outputs Letty and Chris have the same family name ( Johnson ) The pattern is just ? (?name1.?familyName) ? (?name2.!familyName) ?. Scala only allows a wild card in the tail of a pattern. Perl 6 seems to have modernized its pattern matching, but the subject is still a string, never a list. Correct me if I'm wrong. For a perhaps more convincing, but longer, example, see Dinesman's multiple-dwelling problem[^].

Indeed. Bracmat would have been a better programming language if I had been a computer scientist. For software that is going to be maintained by others, Bracmat is currently not a solution. That is why I am looking for a community driven programming language that has pattern matching (on strings, lists, trees, see the list above) in its tool box. Clarify your answer if I misunderstood you.

Bart Jongejan

There are many programming languages that do string pattern matching, either using regular expressions or using more elegant and powerful mechanisms, like SNOBOL[^]. There are also many programming languages that do tree pattern matching, like Haskell, but you cannot easily write a pattern that attempts to match an element in a list (a right descending tree), unless it is the first element. Many tasks involve complex, irregular and not very large structured data. The most appropriate programming languages for tackling such tasks should have this kind of pattern matching in their tool box. Examples of application domains for such a language:

• HTML/XML validation and correction
• C++ source code analysis
• Analysis of email chains
• Automatic chaining of tools in a workflow
• Transformation from syntax to semantics in natural language processing
• Computer algebra

Starting in the eighties, I have made and maintained such a language, Bracmat (GitHub[^],Rosetta Code[^]), and I have used it for all purposes listed above. Problem is, it is not an established programming language and therefore not the right language for production software, so I'm looking for a replacement. I hope that I am too pessimistic and that there are in fact programming languages with seizable user communities that support the pattern matching facilities that I am looking for. The programming language that I am looking for should have a pattern matching mechanism that:

1. allows wild cards not only in the tail part of a pattern, but anywhere in a pattern,
2. in the case of matching against a list, is capable of matching any number of consecutive elements anywhere in the list, and not just the 'head' of the list,
3. is visually clean, attractive and readable,
4. allows 'normal' instructions to be embedded in patterns (evaluation of variables, writing to files, function calls, other pattern match operations, etc.),
5. can assign a matched part of the subject to a variable,
6. c