Kartik Agaram:
> While we're throwing out wild and whacky ideas, here's one I've been
> mulling for a few days.
>
> You know how the lisp evaluator reads a list, evals all the elements,
> passes the cdr as arguments to the car? Forget all that.
Lisp has always let you write your own evaluator. That's no problem, just code
it up, and send your data to it. It'd be a crisis if you tried to REPLACE the
standard evaluator with something different, of course. But all you have to do
is send the data to your new evaluator directly (in many ways it's actually
easier to do this than replace the reader).
> New rules:
>
> a) Adjacent expressions = function application.
>
> factorial 5 => 120
> ++ 3 => 4
>
> Corollary: The function doesn't have to come first.
>
> 5 factorial => 120
> 3 ++ => 4
Okay, but how do you determine which function to apply? For example, if the
symbol is "and", you want it to be the function to be applied here:
#t and #t
but NOT here:
conjunction-list and or
> b) What if a function needs 2 args? Or 3? Curry.
>
> + 1 2 => ((+ 1) 2) => 3
>
> Now we suddenly have infix for free, thanks to above corollary.
>
> 1 + 2 => ((1 +) 2) => 3
>
> (Still no precedence though. Sorry, math guys :)
>
> 1 + 2 * 3 => ((((1 +) 2) *) 3)
>
> c) You don't have to repeatedly curry functions, you can just pass in a list.
>
> +(1, 2) => 3
> cons(1, 2) => (1 . 2)
Uh oh, comma for separating function parameters. That's been tried before in a
Lisp, but that means that ,-lifting is easily missed visually.
> As a corollary, parentheses are just for grouping. They never mean a
> function call.
>
> (+ 1 2) <=> ((+ 1 2))
I'm not sure you mean here. You need to be able to represent what in
traditional Lisp would be (+ 1 2) as well as ((+ 1 2)), since they are
different.
> And that's it! I think this s-expression language would admit
> convenient macros. And I'm not sure if you need quote anymore..
I'm not so sure. WHEN do things go where? Which function is applied? Being
able to be sure what will happen is important.
This also isn't even slightly backwards-compatible. That may not matter to
you, of course. But I've been striving to maximize backwards compatibility.
> I've thought about a couple of additional frills you could add to this
> language:
>
> A. You could interpret this programming model using an accumulator.
>
> > + 1 2
> ; + => store + in accumulator
> ; 1 => combine + and 1, store a curried function in accumulator
> ; 2 => combine curried function and 2, store 3 in accumulator
> 3 ; finally print 3
>
> The combination of currying and an accumulator seems to do what a
> stack does in forth or factor.
Forth?! Cool. I was just reading some old Forth books.
> Instead of functions picking up
> arguments from a stack, there's a *queue* of arguments trotting into a
> function's mouth. When the function's done eating all the args it
> needs it closes its mouth, digests, excretes a result to the
> accumulator, and vanishes.
>
> B. If you have rules for how values of various types coerce to
> functions you can get array and hash dereference. Just treat all kinds
> of brackets as groupers.
>
> array[2, 3] => (array 2 3) => ((array 2) 3)
> hash{key} => (hash key)
>
> You can also coerce booleans to functions and turn 'if' into a
> single-arg function.
>
> if (x < 3) {
> print "haha";
> 34;
> }
>
> ; => (if (x < 3)) { .. }
>
> ; => true { .. }
>
> ; => eval-all { print "haha"; 34 }
>
> Compare this with smalltalk: (3 < 4) :iftrue [ print "haha"; 34; ]
> (I suck at smalltalk, so this has a negligible chance of being correct
> syntax.)
>
> One assumption I'm making in this code fragment is that semi-colons
> are delimiters. Just like all kinds of brackets behave the same,
> semi-colons and commas are delimiters and behave the same, serving
> only to separate elements of a list or array.
>
> { a; b; c; d } <=> (a, b, c, d) <=> [a, b, c, d]
>
> This flexibility allows us to add the illusion of syntax without
> giving up s-expressions and macros.
Again, you've completely abandoned backwards compatibility with existing
s-expressions if you do this. That may be fine for your purposes, but isn't
mine.
> C. You can make parens optional like in ruby:
>
> f a, b, c => f(a, b, c)
I think at this point, you're designing a new language that happens to build on
some existing Lisp primitives. Which is fine, there's nothing wrong with
that... Logo and others have done so as well.
But frankly, this is starting to sound like you want ML or Haskell. The thing
is, if you want ML or Haskell, there are already fine implementations of them.
> All of this suggests to me that all talk of lisp 'permitting macros'
> because it is 'homoiconic' is a canard. You can build parse trees and
> macros for any syntax. It's just that the people who want such syntax
> haven't cottoned on to the power of macros. Or they haven't realized
> the value of optional syntax, or of redundant syntax where multiple
> tokens mean exactly the same thing.
Here I completely disagree with you. Being homoiconic is a *necessary*
property of a Lisp notation. If complex list structures get created without
*any* possibility of the developer knowing, it becomes impossible to control
the result.
> I'm not sure I would use all this syntax, but it might be worth
> turning this idea into a language, just as a proof of concept. The
> name for this language is blazingly self-evident:
>
> Blub.
:-).
The currying and paren-less-ness of the above makes me think of Haskell.
I doubt I would use any of this syntax, but you're welcome to give it a try.
I think these ideas are so far from my own goals that, if you want to go for
it, you probably ought to start it as a separate project. If you *do* start a
different project, please let us know so we can follow each others' insights,
and I truly wish you the best!
--- 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
