Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I'd just like to point out that s-expressions are not the same as Lisp. Rather, they are orthogonal. Using s-expressions for concrete syntax does not say anything at all about the semantics of your language.

This also means that there can be multiple concrete syntaxes for a language: e.g. for Python, you can use the standard syntax, but you could also use s-expressions, without changing the semantics one bit.



OK,

s-Expressions are not the same as LISP sure but I don't think you can say they are orthogonal either. They are a key aspect.

Sure, you can have a non-LISP s-expression language but the boundary between this and a subdialect of LISP is going to be porous.

The strengths and the weaknesses of LISP, as far I can see, come because it is so easy to just create a mini-language, a sub-dialectic to do this and that.

I'll assume people know the strengths (and I'm the one say them most eloquently), I'd mention simplicity, flexibility, recursion, homoiconity, etc.

I'd say the weaknesses "easy wheel reinventing", which has resulted in many half-formed wheels and few canonical wheels.

So to get back to syntax, what's nice about a "strong clear" syntax like infix math or c-style function declarations is that they make purposes clear and make boundaries clear. The useful of designing a "real language" is doing that. You can do everything with s-Expression but if it just your new language for doing X, you'll putting forward your purpose in a loose, flabby way. If you expression-language isn't going to be just rolled into LISP, it will just have all the weaknesses and of the strengths of LISP.


But we have to jump through some hoops to convert expressions into statements/expressions (I work a bit on Hy[0] which does exactly this).

[0] https://github.com/hylang/hy


Yes, that's typically how it works -- at some point, the concrete syntax tree has to be converted to abstract syntax.

I wouldn't call it jumping through hoops though. Rather, for me, it's a natural consequence of separation of concerns. I try to build parsers that only know about concrete syntax. A later pass over the CST is responsible for building the AST, which prevents coupling of the parser to the abstract syntax.

YMMV. There's more than one way to skin this cat.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: