BGB, please see my answer to shaun. In short: _ I'm not looking for stack-based languages. I want a Lisp which got rid of (most of the) the parens by using fixed arity and types, without any loss of genericity, homoiconicity or other desirable features. REBOL does just that, but it's not so good regarding performance, the type system, etc.
_ I *hate* infix notation. It can only make sense where everything has arity 3, like in RDF. _ Matching parens is a non-issue. Just use Paredit or similar ;) _ Umm, "whitespace sensitive" sounds a bit dangerous. I have enough with Python :p Thanks for your input. Best, -Martin On Thu, Mar 15, 2012 at 6:54 PM, BGB <[email protected]> wrote: > 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 > [email protected] > http://vpri.org/mailman/listinfo/fonc _______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
