On 7/19/12, Kartik Agaram <a...@akkartik.com> wrote: >> There have been dozens of Lisp-based programming languages that started >> with that premise, starting with McCarthy's M-expressions. > > But I think my proposal hasn't been tried before: a single consistent > set of primitives that map 1-1 to various lisp dialects. > > You wouldn't be able to translate a nontrivial codebase to both Common > Lisp and Scheme. When you target Common Lisp you'd use its libraries > and make assumptions about its runtime. You'd just parenthesize let > and if differently from Common Lisp. Compiled files would be > compatible with Common Lisp, so you could use all the standard > libraries of Common Lisp. > > Or you could switch to a Scheme project and use its runtime, and all > its libraries, but with the same consistent syntax for let and if as > the Common Lisp project. > > Calling it a language seems almost too overblown; I'm just creeping > scope very slightly relative to sweetexprs :) > > Have y'all seen lisp-flavored erlang? This seems a little bit like that.
Hmm. Basically, suppose we propose that let is universal to all Lisp-like languages, and specifically give a syntax specifically designed for let. Then we allow conversion from the let-syntax to Scheme/CL let syntax, and a conversion to Arc with syntax, which have different rules for pairing. How do we then handle it when someone wants to make a macro that is like, but isn't, let? For example, suppose someone wants to implement and-let*, SRFI-2 http://srfi.schemers.org/srfi-2/srfi-2.html. Obviously we want the to reuse the let-syntax in the indent-syntax, except that we use the and-let* symbol. Okay, so we're open to having different languages, so we consider writing an and-let* macro for Scheme, another for CL, and another for Arc. How do we express the usage of this macro using the Unified Syntax for Indented Lisp? It's like let, but isn't - the syntax is identical to let, but the semantics is different, and so we must use a different symbol. How do we mark this macro so that the syntax converter will convert and-let* forms properly to CL/Scheme and-let* and Arc and-withs? > And then there was something about starting > a top-level form with indent to suppress indent-sensitivity; I'm not > too clear on that. This fixes a bloody messy problem: your indentation reader starts up. It looks at the port... and sees a space!! Oh noes!! Someone has just indented the first line! So how do we act in this case? Okay, let's count the first line's indent... two spaces. Let's pretend that this is the 'left edge' i.e. all lines in the file are indented by at least two spaces. Okay, let's go to the next line... oh noes! It's got one space for indent - it's managed to go beyond the left edge, it's even lefter than left! How do we handle that? So we started devising some rules to handle that. And then Things Got Worse (TM). The rules collapsed into themselves and formed a singularity, threatening to drag sweet-expressions, basically the ENTIRE REMAINING SET of completely non-insane( Lisp users left in the universe (*), into oblivion. Since the rules got complicated, we just decided "screw it" and said "You want indentation processing, start at the *real* leftmost edge: don't indent the first line!" So: indentation on the first line disables indent processing. (I suppose it *should* be an error rather than a silent disabling of indentation, but well). (*) This is a joke. o(^.^o)(o^.^)b (**) (**) This is also a joke (~.~);; ------------------------------------------------------------------------------ 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
