Hmmm that's too bad, I'd like a python-flavoured lisp. That is a relatively fast functional language that replaces most of the brackets with indentation.
Make sure you use an editor, like emacs, that really understands lisp and the parentheses won’t mater. The auto indenting with lisp makes working with it syntactically just as easy as python.
I don't disagree, I did that back in university. My problem with the brackets is that it lends itself to a 'write-once-read-never' style when a function ends with 12 round brackets.
I think S-expr trees and their macros are the right way to write code, and that a S-expr diff is the one true way to do git-diff. But so far I haven't seen a language that integrates into the toolchain like that.
Go has gofmt that at least acknowledges that style should be consistent, but I would argue 'who gives a fuck'. The expression tree is what really matters.
Look into pyret. Its made by one of the racket creators. But as most commentors said use a lisp with a good editor. Emacs or atom with parinfer for example.
Yes, wisp : http://www.draketo.de/english/wisp
But most lisper prefer parentheses. As for me I'm just starting to learn scheme because of GuixSD and I'm trying to get used to parentheses. It's not that bad if you use paredit/parinfer/...
Have you used wisp? I'm actually just about to work on a small github project to learn it, and was wondering if there's an editor with wisp syntax highlighting out there.
I tend to use VS Code, but it just has a plugin package named "wisp" with no documentation, looks for ".w" extensions, and is on version 0.0.1...
No, I'm just starting to learn my first lisp.
I just found wisp while I was lurking on search engines for this parentheses "problem" (as I viewed it). Then I found this answer on quora and started to convince myself parentheses don't really matter: https://www.quora.com/Would-it-be-possible-to-replace-parent...
(From memory, don't quote me on this), The BEAM bytecode is apparently not well documented, so the standard practice for compile-to-beam languages is to emit Erlang terms, then use the erlang toolchain to compile down to bytecode. I think that's how Elixir and LFE do it anyways.
The only problem is that everytime he/she wants to execute Hy (Python in s-expression syntax) code, he will invoke the macro "org-babel-execute:hy", and this runs Hy as a shell command.
So Common Lisp objects can't be quickly copied or shared to Python, and for each invocation there is a time overhead.
I'd love to see a good bridge from Common Lisp to Python. It should be possible.
Has Hy gotten the let special form working yet? Last I looked, there was a ton of conversation over let not working right/at all, which seems like a big sticking point.
I don't know that I'd call them weird, just the natural result of Python's assignment syntax (tho I suspect that you might call that weird as well). Without specific declaration syntax, it would be somewhere between messy and impossible to differentiate between block and function-level scopes. The only thing I could think of would be the inclusion of a new declaration/assignment operator, like `=:`, that would declare the variable as block scoped, but such a change would be backwards incompatible and I don't believe they're going to do that again.
What would you like it to look like? How would you want it to work?
"A Lisp that runs Python" is kind of vague. Hy describes itself as "a Lisp-flavored Python". I'd call it "a lisp that compiles to Python".