On 3/15/2012 9:21 AM, Martin Baldan wrote:
I have a little off-topic question.
Why are there so few programming languages with true Polish syntax? I
mean, prefix notation, fixed arity, no parens (except, maybe, for
lists, sequences or similar). And of course, higher order functions.
The only example I can think of is REBOL, but it has other features I
don't like so much, or at least are not essential to the idea. Now
there are some open-source clones, such as Boron, and now Red, but
what about very different languages with the same concept?
I like pure Polish notation because it seems as conceptually elegant
as Lisp notation, but much closer to the way spoken language works.
Why is it that this simple idea is so often conflated with ugly or
superfluous features such as native support for infix notation, or a
complex type system?
because, maybe?...
harder to parse than Reverse-Polish;
less generic than S-Expressions;
less familiar than more common syntax styles;
...
for example:
RPN can be parsed very quickly/easily, and/or readily mapped to a stack,
giving its major merit. this gives it a use-case for things like textual
representations of bytecode formats and similar. languages along the
lines of PostScript or Forth can also make reasonable assembler
substitutes, but with higher portability. downside: typically hard to read.
S-Expressions, however, can represent a wide variety of structures.
nearly any tree-structured data can be expressed readily in
S-Expressions, and all they ask for in return is a few parenthesis.
among other things, this makes them fairly good for compiler ASTs.
downside: hard to match parens or type correctly.
common syntax (such as C-style), while typically harder to parse, and
typically not all that flexible either, has all the usual stuff people
expect in a language: infix arithmetic, precedence levels, statements
and expressions, ... and the merit that it works fairly well for
expressing most common things people will care to try to express with
them. some people don't like semicolons and others don't like
sensitivity to line-breaks or indentation, and one generally needs
commas to avoid ambiguity, but most tend to agree that they would much
rather be using this than either S-Expressions or RPN.
(and nevermind some attempts to map programming languages to XML based
syntax designs...).
or, at least, this is how it seems to me.
ironically, IMO, it is much easier to type C-style syntax interactively
while avoiding typing errors than it is to type S-Expression syntax
interactively while avoiding typing errors (maybe experience, maybe not,
dunno). typically, the C-style syntax requires less total characters as
well.
I once designed a language syntax specially for the case of being typed
interactively (for terseness and taking advantage of the keyboard
layout), but it turned out to be fairly difficult to remember the syntax
later.
some of my syntax designs have partly avoided the need for commas by
making the parser whitespace sensitive regarding expressions, for
example "a -b" will parse differently than "a-b" or "a - b". however,
there are some common formatting quirks which would lead to frequent
misparses with such a style. "foo (x+1);" (will parse as 2 expressions,
rather than as a function call).
a partial downside is that it can lead to visual ambiguity if code is
read using a variable-width font (as opposed to the "good and proper"
route of using fixed-width fonts for everything... yes, this world is
filled with evils like variable-width fonts and the inability to tell
apart certain characters, like the Il1 issue and similar...).
standard JavaScript also uses a similar trick for "implicit semicolon
insertion", with the drawback that one needs to use care when breaking
expressions otherwise the parser may do its magic in unintended ways.
the world likely goes as it does due to lots of many such seemingly
trivial tradeoffs.
or such...
_______________________________________________
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
