> > but, hmm... one could always have 2 stacks: create a stack over the stack, > in turn reversing the RPN into PN, and also gets some "meta" going on...
Uh, I'm afraid one stack is one too many for me. But then again, I'm not sure I get what you mean. > > + 2 * 3 4 => 24 Wouldn't that be "+ 2 * 3 4 => 14" in Polish notation? Typo? > > commands are pushed left to right, execution then consists of popping of and > executing said commands (the pop/execute loop continues until the stack is > empty). execution then proceeds left-to-right. Do you have to get busy with "rot", "swap", "drop", "over" etc? That's the problem I see with stack-based languages. >> _ I *hate* infix notation. It can only make sense where everything has >> arity 3, like in RDF. > > > many people would probably disagree. > whether culture or innate, infix notations seem to be fairly popular. My beef with infix notation is that you get ambiguity, and then this ambiguity is usually eliminated with arbitrary policies of operator priority, and then you still have to use parens, even with fixed arity. In contrast, with pure Polish notation, once you accept fixed arity you get unambiguity for free and you get rid of parens for everything (except, maybe, explicit lists). For instance, in infix notation, when I see: 2 + 3 * 4 I have to remember that it means: 2 + (3*4) But then I need the parens when I mean: (2 + 3) * 4 In contrast, with Polish notation, the first case would be: + 2 * 3 4 And the second case would be: * 4 + 2 3 Which is clearly much more elegant. No parens, no operator priority. > > actually, it can be noted that the many of the world languages are SVO (and > many others are SOV), so there could be a pattern here. I've read a recent study which says the human brain seems to be wired for SOV. The reason for this conclusion was that two groups of deaf people had independently developed their own sign languages, and both were SOV. By the way, I'm playing with the idea of making a logical conlang with a concise, highly-regular syntax. The most promising type of syntax seems to be REBOL-like, that is, Polish notation. The funny thing is that, at present, the way I'm trying to handle event description makes it have the verb at the end, but it's not RPN. Here's why: walk evt-1 == "evt-1 is a walking event" subj John walk evt-1 == "evt-1 is a walking event with John as its subject" ex-past walk == "there is a past walking event" ex-past subj John walk == "there's a past walking event with John as its subject" My point is that the correspondence between SOV or SVO and the underlying syntax may not be so straightforward. Also, the issue of how to build a good model of spoken language is still open. > > a reasonable tradeoff IMO is using prefix notation for commands and infix > notation for arithmetic. You can always use a library for infix instead of having it built into the interpreter and making life more difficult for those who prefer the more consistent prefix notation. I would say that's reasonable enough. For instance: http://folk.uio.no/jornv/infpre/infpre.html > > > >> _ Matching parens is a non-issue. Just use Paredit or similar ;) > > > I am currently mostly using Notepad2, which does have parenthesis matching > via highlighting. > > however, the issue isn't as much with just using an editor with parenthesis > matching, but more an issue when quickly typing something interactively. one > may have to make extra mental effort to get the counts of opening and > closing parenthesis right, potentially distracting from "the task at hand" Ah, but that's the whole point of Paredit. It *doesn't let you* have unmatched parens. That's right, you just can't do it. You don't write or delete parens, you create an empty sexpr, you delete it, you move it around, you swallow the following sexpr into it, you barf it, you fuse, splice, etc, always working with sexprs, never with parens. > > > something like REBOL could possibly work fairly well here, given it has some > structural similarity to shell-command syntax. I would say REBOL is better, because it's just as terse if not more, and it's more regular. > the main merit it has is that it can reduce the need for commas (and/or > semicolons), since the parser can use whitespace as a separator (and space > is an easier key to hit). Okay, so it's because the space key is bigger. I see the point, but it has more to do with keyboard layout than with visual or mental considerations. I would happily exchange a little typing speed for stronger visual cues, but other people may have other preferences. Best, -Martin _______________________________________________ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
