Alpheus Madsen: > It was my understanding that "modern-expressions" was the name of the rule > that transformed the standard s-expr (function arg1 arg2 arg3) > into the sweet-expression form function(arg1 arg2 arg3)
Well, sort of. Modern expressions add that transformation rule, but the other direction. That is, a modern-expression of the form function(arg1 arg2 arg3) is transformed into the standard s-expression (function arg1 arg2 arg2). I think you knew that, and just wrote it backwards, no biggie. I'm clarifying this not for you, but for other people who are reading our conversation so that they won't get confused. Also, a nit: modern-expressions include several rules, including all the curly-infix rules. So the f(a b c) => (f a b c) is one of the key *additional* rules added by modern-expressions. > It is this naming convention that rubs me the wrong way; which is why I'd > call these "functional expressions" instead of "modern expressions". That's not a *bad* name, but: 1. s-expressions can also represent functions 2. f-expressions sounds like f*n-expressions, which is not the association I'm looking for :-). As I noted earlier, prefix-expressions becomes p-expressions which sounds like pee-expressions. I suppose affix-expressions would work, becoming a-expressions, but that's hard to say and, well, boring. Of the alternatives to "modern" I like "neoteric" the best. Not sure I'd want to switch, but that's the one I like best so far. Anyone have an alternative name for "modern"? > I would expect that the entire project could still be called > "sweet-expressions" Clarification: The full name of this project is currently the "Readable Lisp S-expressions Project"; I normally shorten this to the "readable" project. See http://readable.sourceforge.net/ or http://sourceforge.net/projects/readable/ Neither name is cast in stone, of course. If you think the project should have another name, please propose one! However, changing it to something without "readable" in it would be a big pain; I would want the URLs to match the project name, and that'd be unpleasant to change. So I'd want to hear a good name, with good justification. While "sweet-expressions" are the (current) name for the topmost tier, I think it's important to have tiers, *AND* I'm open to changing the name. But I'm not into change for change's sake; it needs to be plausibly better. > ... Indeed, I wouldn't refer to something as a "t-expression", any more than > I would something an "s-expression"--I'd sooner use the abbreviations > "t-expr" and "s-expr". Interesting. I use the term "s-expression" all the time. But no big deal. > ... Referring to "modern-expressions" as "m-exprs" would be problematic, > because this name is already spoken for Right. Agree, that is an issue. > Come to think of it, to what extent are we working on the problem that > McCarthy started with, to produce "m-exprs"? I'm inclined to think that > we're *sort-of* working towards that, but not really--after all, our goal is > to create a system of s-exprs, just with a different expressional syntax. I've read that work, yes. What we're doing is completely different. The problem was that he was trying to create a notation that was, at its heart, similar to Algol, Fortran, etc. At the time, no one understood that a Lispy language notation HAD to be homoiconic or general, so his notation was not. That this was a problem was not understood at all at the time, which makes sense, this was the early days of Lisp and the whole idea was new. The same kind of thing has happened again & again over decades. It's not obvious that a new notation for a Lisp-like language has to be homoiconic & not tied to the underlying semantic, so the same problems kept happening. But now that we know that these are some of the key advantages of traditional s-expressions, we can devise notations that preserve those advantages while being easier to read. --- David A. Wheeler ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
