Somewhat related, hy (aka hylang) is a lisp that compiles to the python abstract syntax tree which technically makes python a multi-syntax language already. Plus you get all the python libraries.
BTW the "if" in Python is very different to the "if" in lisp as one is a statement and the other is an expression. I'm curious how the OP plans to deal with the expression != statement.
I like these type of things but I don't believe they are practical because of the massive potential variation within a single syntax which is typically hidden by language specific culture, convention and idiom. When you transliterate from one language to another, the gulf is made visible and the resulting code is alien and unacceptable despite executing correctly.
The unavoidable problem is finding a language in which every one's solution to the same problem is the same but I think that goal is more likely provably false than possible. If it is possible then finding solutions in such a language might be like threading a tiny needle and too hard to use.
Well, you mean the Zen of Python's "There should be one-- and preferably only one --obvious way to do it."
In any case, even then, people think in different ways: you can model a problem via category theory, geometry, algebra, and those would never translate into the same syntactical constructions, since the abstractions are of fundamentally different natures.
Now I think mostly in a functional way, so my Python code is full of small functions to help write "pythonic functional code", e.g. the function iff(b,x,y) that returns x if b and else returns y. The resulting code could be translated algorithmically to a functional language in a very natural way; the internal def would be translated to where clauses, etc.
The point being, I want to be able to think in the way that is the most adapted to tackle a problem, even if the code seems to be written in two different languages. This is no different from mathematics where each "X theory" is essentially its own language and each implies its own set of natural theorems.
That's correct, I made it because I wanted to illustrate an idea.
However I think it can still be useful, and already there are precedents: semi-visual languages with underlying text source, lisp bi-directional macroses.
Do you think my another hivemind idea can be useful? Regrouping code based on structure and intent
(e.g. Group source by class / by method / in groups of highly-connected components)
Awesome! This has long been a dream of mine, but I never solved the problem of creating a better syntax than BNF grammars etc.
I don't know if we have the same goals, but my end-goal was to have some treelike serialization (JSON/XML) but a canonical editor which would display in whatever you were most familiar with (Lisp, Python, Haskell, C-ish). The limitation would be that you'd have to store metadata-ish stuff on the tree to handle custom indentations that don't follow some canonical style guide.
Bidirectional parsing-pretty-printing is a nice thing, with the only potentially tricky issue in an idiomatic rendering of the infix opetators with priority. Firstly, parser must be aware that they are special (I am using a dedicated Pratt parser for the binaries inside a Packrat for this reason). Secondly, it is often important to print parenthesis around an expression for readability, even if it is not dictated by the priority.
This is very cool. People who want to create new languages usually have to write a lot of code even though most of the heavy lifting is done by a lexer and a parser generator.
This seems to me like a very high level way to specify a new language. A much easier way, definitely. I assume the cost of this is that only a small subset of programming languages can be specified in hivemind. Nevertheless, it's still an incredible project. Target LLVM, and this could become a compiler generator ;-).
Nim has a powerful templating system that allows introducing new syntactic elements and semantics, but maybe you are thinking about generating output code in multiple languages (C, C++, JS...)?
What is the connection between OO and infix vs. FP and prefix? Most FP languages use infix notation for operators, and Haskell even supports infix notation for all functions. Lisp does both OOP and FP in prefix notation.
[+] [-] cyrus_|10 years ago|reply
http://cs.brown.edu/~sk/Publications/Papers/Published/pk-res...
and more recently:
http://cs.brown.edu/~sk/Publications/Papers/Published/pk-hyg...
[+] [-] mjn|10 years ago|reply
[+] [-] alehander42|10 years ago|reply
[+] [-] shpx|10 years ago|reply
https://github.com/hylang/hy
It's been posted a bunch of times on HN
https://www.google.ca/search?q=site%3Anews.ycombinator.com+h...
[+] [-] zeckalpha|10 years ago|reply
[+] [-] alehander42|10 years ago|reply
Actually I've done a prototype of a lisp compiling to python bytecode, so that's why when I found hy, I was pretty excited about it.
https://github.com/alehander42/bach
However it's not making it multi-syntax in the same way, because you don't get 1-to-1 python-hy inter-translation.
[+] [-] earleybird|10 years ago|reply
[+] [-] xKingfisher|10 years ago|reply
It's a great tool.
[+] [-] agentgt|10 years ago|reply
And yes with Racket you can mix and match languages and create them with out parenthesis (https://docs.racket-lang.org/guide/languages.html).
BTW the "if" in Python is very different to the "if" in lisp as one is a statement and the other is an expression. I'm curious how the OP plans to deal with the expression != statement.
[+] [-] duncanawoods|10 years ago|reply
The unavoidable problem is finding a language in which every one's solution to the same problem is the same but I think that goal is more likely provably false than possible. If it is possible then finding solutions in such a language might be like threading a tiny needle and too hard to use.
[+] [-] logicrook|10 years ago|reply
In any case, even then, people think in different ways: you can model a problem via category theory, geometry, algebra, and those would never translate into the same syntactical constructions, since the abstractions are of fundamentally different natures.
Now I think mostly in a functional way, so my Python code is full of small functions to help write "pythonic functional code", e.g. the function iff(b,x,y) that returns x if b and else returns y. The resulting code could be translated algorithmically to a functional language in a very natural way; the internal def would be translated to where clauses, etc.
The point being, I want to be able to think in the way that is the most adapted to tackle a problem, even if the code seems to be written in two different languages. This is no different from mathematics where each "X theory" is essentially its own language and each implies its own set of natural theorems.
[+] [-] alehander42|10 years ago|reply
However I think it can still be useful, and already there are precedents: semi-visual languages with underlying text source, lisp bi-directional macroses.
Do you think my another hivemind idea can be useful? Regrouping code based on structure and intent
(e.g. Group source by class / by method / in groups of highly-connected components)
[+] [-] drostie|10 years ago|reply
I don't know if we have the same goals, but my end-goal was to have some treelike serialization (JSON/XML) but a canonical editor which would display in whatever you were most familiar with (Lisp, Python, Haskell, C-ish). The limitation would be that you'd have to store metadata-ish stuff on the tree to handle custom indentations that don't follow some canonical style guide.
[+] [-] alehander42|10 years ago|reply
I also imagined automated reordering of code in an editor, but I still have only a demo (https://github.com/alehander42/rehab)
[+] [-] sklogic|10 years ago|reply
[+] [-] winter_blue|10 years ago|reply
This seems to me like a very high level way to specify a new language. A much easier way, definitely. I assume the cost of this is that only a small subset of programming languages can be specified in hivemind. Nevertheless, it's still an incredible project. Target LLVM, and this could become a compiler generator ;-).
[+] [-] vbit|10 years ago|reply
[+] [-] nyan4|10 years ago|reply
[+] [-] zeckalpha|10 years ago|reply
[+] [-] nv-vn|10 years ago|reply
[+] [-] sklogic|10 years ago|reply
[+] [-] jiyinyiyong|10 years ago|reply
[+] [-] ilaksh|10 years ago|reply