>
> > > I dislike the name "modern-expressions"
>
> Can you propose some alternative names?
>
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)
It is this naming convention that rubs me the wrong way; which is why I'd
call these "functional expressions" instead of "modern expressions". I do
not recall *exactly* how functional notation came to be, but I suspect that
Leonhard Euler probably did a lot to standardise the notation into what it
is today. (Euler seemed to do pretty much *everything*, though.)
One problem I see is that one-letter names (like "c-expressions" for curly
> infix, "m-expressions" for modern expressions, and "t-expressions" for
> sweet expressions) don't really have the same "punch".
I would expect that the entire project could still be called
"sweet-expressions"; the purpose of the one-letter name is for
convenience. 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". Technically, in my mind at least,
"t-expr" is short for "tree-expression", which is convenient if you want to
emphasise that the data structures we are dealing with are trees.
(Technically, s-exprs are "tree-expressions", too, but that shouldn't
matter in the naming convention, because one of the goals of the project is
to make sure that any "s-expr" is also a valid "t-expr"--so s-exprs *ought*
to be valid t-exprs!)
Referring to "modern-expressions" as "m-exprs" would be problematic,
because this name is already spoken for; we'd have to refer to them as
"f-exprs". But then, I wasn't thinking in terms of naming different
expressions according to the rules they used; I just expected each of the
types to be different rules describing "t-exprs".
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.
On Fri, Jul 20, 2012 at 1:24 PM, Kartik Agaram <a...@akkartik.com> wrote:
> > One problem I see is that one-letter names (like "c-expressions" for
> curly infix, "m-expressions" for modern expressions, and "t-expressions"
> for sweet expressions) don't really have the same "punch".
> >
> > What names would you propose for all 4 cases, and why?
>
> It might make sense to think about adoption for the umbrella name for
> the project, and just use unambiguous jargon-y names for the three
> tiers under it. If c/m/t expressions don't need to pull the weight of
> increasing adoption, that might make the problem a little more
> tractable.
>
>
> ------------------------------------------------------------------------------
> 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
>
------------------------------------------------------------------------------
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
