Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pixie: A small fast, native lisp

github.com

Post reply on HN
Print view View original

51–58 of 58 posts

Re: Pixie: A small fast, native lisp

#51

Post by sklogic »

wtbob wrote: post #34
sklogic wrote: post #24

Earlier quoted context omitted.

Common Lisp is too big for a typical application (e.g., embedded scripting engines, mataprogramming hosts, etc.). And it's a Lisp-2, which is quite a deterrent for many.

I know folks used to say that Common Lisp was too big, comparing it to C or Pascal. But is it really big compared to, e.g., Python, JavaScript or Ruby? If anything, a common complaint now is that too little is standardised (which is true, but good portable libraries exist for most such things). And, as lispm notes, one can implement a subset of Common Lisp—all that's required is that one define the subset.

Interestingly, so far people preferred to implement dialects of Lisp-1 mostly. Not that many Common Lisp subsets or even Common Lisp-inspired languages around. I can only name Shen as one obvious exception from this rule.

Re: Pixie: A small fast, native lisp

#52

Post by drtse4 »

andrewchambers wrote: post #45
drtse4 wrote: post #19

Earlier quoted context omitted.

Thanks, i already noticed the age of the project :). The ""complaint"" is obviously valid, i'd add at least half a page of examples to explain what it does and how to try it, just to increase the chance of contribution. No snarkiness was intended... but looks like it came out that way.

Did you even read the readme? He clearly says hes changing a bunch of stuff and doesn't think outside people can contribute much yet.

Next time, don't hit reply.

Re: Pixie: A small fast, native lisp

#53

Post by sedachv »

andrewchambers wrote: post #40
sedachv wrote: post #38

Earlier quoted context omitted.

> This is a lisp engine written in python - RPython, to be precise. So there is nothing "native" about it, and until we see this on http://benchmarksgame.alioth.debian.org/ no basis for calling it "fast."

You don't understand what rpython is. RPython is a statically typed subset of python which compiles to C. It also has code in it for generating a Jit.

You don't understand what the word "native" means. Transpiling to C is not "native." The RPython JIT 'compiler' is a trace optimizer for the bytecode interpreter. There is absolutely nothing "native" about that. If you don't have an assembler, it's not "native."

Re: Pixie: A small fast, native lisp

#54

Post by sedachv »

sklogic wrote: post #49
sedachv wrote: post #37

Earlier quoted context omitted.

> And it's a Lisp-2, which is quite a deterrent for many. I used to be on the fence about multiple namespaces in programming languages. After a decade of programming in Common Lisp and in other languages that pretend to have a single namespace, I see multiple namespaces as a clearly superior approach. I don't think it is a deterrent either - a reason to post complaints on the Internet, yes.

For me it's clearly a deterrent - it does not fit at all into my model of building hierarchies of DSLs.

> it does not fit at all into my model of building hierarchies of DSLs

Links to source code or GTFO. The only way people manage to combine DSLs in a single-namespace language is by having stupid naming rules and restrictions (see for example Ruby on Rails). Compare this to something like https://github.com/vsedach/cliki2 where I could just throw arbitrary CL libraries that define their own DSLs together and not worry that my function name is going to clobber some reference in the template system.

Re: Pixie: A small fast, native lisp

#55

Post by dTal »

andrewchambers wrote: post #44
dTal wrote: post #18

Earlier quoted context omitted.

Clojure's success, I believe, is due to retaining Java's semantics (preserving library compatibility) while overhauling its syntax. Fighting the semantics of your host language/VM just makes work and causes trouble. Therefore, if you want a "Clojure on Python" that preserves the benefits of the original, you need to give it Python semantics, not Java/Clojure's. Hylang is that project - it uses Clojure syntax where se…

Only hylang has a lot of stupid limitations and problems like scope leakage.

I take it you refer to your complaint here: https://github.com/hylang/hy/issues/543

Your problem is with Python, not Hy. Hy inherits the "stupid limitations" of Python, and not even all of those - for example, it does away with the statement/expression distinction, which means multiline lambdas (at last!).

It's just Python with s-expressions. If you don't like it, you either don't like Python or don't like s-expressions.

Re: Pixie: A small fast, native lisp

#56

Post by sklogic »

sedachv wrote: post #54
sklogic wrote: post #49

Earlier quoted context omitted.

For me it's clearly a deterrent - it does not fit at all into my model of building hierarchies of DSLs.

> it does not fit at all into my model of building hierarchies of DSLs Links to source code or GTFO. The only way people manage to combine DSLs in a single-namespace language is by having stupid naming rules and restrictions (see for example Ruby on Rails). Compare this to something like https://github.com/vsedach/cliki2 where I could just throw arbitrary CL libraries that define their own DSLs together and not worry…

See https://github.com/combinatorylogic/mbase

Problem with two namespaces is, well, need to maintain two namespaces, in all your DSLs. Which in many cases may double the effort.

Of course, macros must have their own namespace, but that's an obvious thing, you cannot mix compile-time and run-time namespaces anyway.

Re: Pixie: A small fast, native lisp

#57

Post by sedachv »

sklogic wrote: post #56
sedachv wrote: post #54

Earlier quoted context omitted.

> it does not fit at all into my model of building hierarchies of DSLs Links to source code or GTFO. The only way people manage to combine DSLs in a single-namespace language is by having stupid naming rules and restrictions (see for example Ruby on Rails). Compare this to something like https://github.com/vsedach/cliki2 where I could just throw arbitrary CL libraries that define their own DSLs together and not worry…

See https://github.com/combinatorylogic/mbase Problem with two namespaces is, well, need to maintain two namespaces, in all your DSLs. Which in many cases may double the effort. Of course, macros must have their own namespace, but that's an obvious thing, you cannot mix compile-time and run-time namespaces anyway.

> Problem with two namespaces is, well, need to maintain two namespaces, in all your DSLs. Which in many cases may double the effort.

How so? And why only two namespaces? Common Lisp probably has a dozen: package name, lexical variable, dynamic variable, function (stores either function or macro function), documentation string, property list, type name, class name, slot name, etc.

As long as you have first-class identifiers, you can define arbitrary namespaces without having to worry about conflicts between the namespaces.

> Of course, macros must have their own namespace

That doesn't have to be true, and is not true in Common Lisp: http://www.lispworks.com/documentation/HyperSpec/Body/03_bba...

Having an identifier denote a function and a macro at the same time like that enables adding partial evaluation and other compile-time optimizations to DSLs without having to dig into the compiler.

> but that's an obvious thing, you cannot mix compile-time and run-time namespaces anyway.

? You have to mix them if you want a compiler in your runtime.

Re: Pixie: A small fast, native lisp

#58

Post by andrewchambers »

sedachv wrote: post #53
andrewchambers wrote: post #40

Earlier quoted context omitted.

You don't understand what rpython is. RPython is a statically typed subset of python which compiles to C. It also has code in it for generating a Jit.

You don't understand what the word "native" means. Transpiling to C is not "native." The RPython JIT 'compiler' is a trace optimizer for the bytecode interpreter. There is absolutely nothing "native" about that. If you don't have an assembler, it's not "native."

The trace JIT has an assembler, and the C code is compiled to native assembly.

https://bitbucket.org/pypy/pypy/src/f7bc5ed1602fb522625a3d02...

Assembler.py is the jit assembler.

Post reply on HN