Bio – Experimental Lisp dialect, written in Zig(github.com)
github.com
Bio – Experimental Lisp dialect, written in Zig
https://github.com/cryptocode/bio
38 comments
Very interesting. Would be useful to know how this compares to other Lisps and what could be some use cases.
What's the experiment?
Putting closing parentheses on their own lines is extremely cursed.
I used to like Lisp-1s when I used Scheme, but having used Common Lisp for a while I've come to appreciate Lisp-2s, if only for silly things like...
I used to like Lisp-1s when I used Scheme, but having used Common Lisp for a while I've come to appreciate Lisp-2s, if only for silly things like...
(defun foo (list)
(declare (type List list))
(assert (> (length list) 1))
(list (second list)
(first list)))
Bio dev here, time to create a HN account I guess. Got a nod that someone posted about it here, which I would prefer to happen a few years from now given the early stage, but hey what can you do :)
I 100% agree with formatting and I've started fixing it, the leftovers were from some (misguided) experimenting.
I 100% agree with formatting and I've started fixing it, the leftovers were from some (misguided) experimenting.
[deleted]
notadev2(2)
tfhfj(1)
Need a dialect without using bracket.
People complaining about parens/brackets in lisps have never really used structural editing. Change my mind!
Parentheses in lisp are a lot like significant indentation (Python, Haskell, etc), in that people tend to complain about it "from afar". It is only once they start actually using the language to develop something nontrivial, that they realize that you quickly stop noticing the syntax entirely.
After 20 years of using python I still think significant whitespace is a flaw.
It saves a little bit of typing in exchange for a lot of ambiguity.
It saves a little bit of typing in exchange for a lot of ambiguity.
There is no ambiguity with significant whitespace.
Problem is always when you need to move code, select/highlight code, paste code, navigate code, and so on. With clear start and end markers like open and close parentheses or like "begin" and "end" in other languages, that problem does not even exist.
Those actions have never been a problem for me. Maybe get a better editor?
Basically, you are confirming, what the original comment said. I now strongly suspect, that you have never used structured editing, which is where the issues with Python syntax are.
Where paredit for Python?
Where paredit for Python?
When using structured editing, why does it matter what the syntax is? The editor is going to handle it for you anyway.
> Where paredit for Python?
I don’t know, go make it. But what would you imagine it to do? Moving blocks of indented code around is already easy without needing language-specific treatment.
> Where paredit for Python?
I don’t know, go make it. But what would you imagine it to do? Moving blocks of indented code around is already easy without needing language-specific treatment.
> When using structured editing, why does it matter what the syntax is? The editor is going to handle it for you anyway.
It matters, because the start and end markers of code allow for easy recognition of where something starts and ends and make the move independent from things like indentation. In Python, if you wanted to do the same, you would have to change indentation in many cases. Also the language is less expression based, which makes it even harder to, for example slurp a block/unit of code, because it is not clear how far the slurping should go.
> I don’t know, go make it. But what would you imagine it to do? Moving blocks of indented code around is already easy without needing language-specific treatment.
Well, I am not the one claiming here, that it does not matter, whether there are start and end markers for blocks of code, so the onus is not on me to make this thing, it is up to you to prove it can be done. Lets not try to reverse the obligation of proof here.
It matters, because the start and end markers of code allow for easy recognition of where something starts and ends and make the move independent from things like indentation. In Python, if you wanted to do the same, you would have to change indentation in many cases. Also the language is less expression based, which makes it even harder to, for example slurp a block/unit of code, because it is not clear how far the slurping should go.
> I don’t know, go make it. But what would you imagine it to do? Moving blocks of indented code around is already easy without needing language-specific treatment.
Well, I am not the one claiming here, that it does not matter, whether there are start and end markers for blocks of code, so the onus is not on me to make this thing, it is up to you to prove it can be done. Lets not try to reverse the obligation of proof here.
There is, four abstractions down,my comment gets squished as a sardine
I basically agree with you, however thought the following was an interesting idea about it perhaps not always being that simple:
https://news.ycombinator.com/item?id=33166116
https://news.ycombinator.com/item?id=33166116
There is this: https://srfi.schemers.org/srfi-119/srfi-119.html
Everyone forgets about Dylan. (https://en.wikipedia.org/wiki/Dylan_(programming_language)?w...)
Brackets? That's easy! Just use parentheses instead!
I guess you mean parentheses. Perhaps I am unaware of some meaning of brackets, that also describes parentheses, but afaik parentheses are different from brackets.
UK English mostly treats unadorned “bracket” as referring to (), in fact, as opposed to US English which more often treats it as referring to [].
In Russian words parentheses, brackets and braces are represented by the same word with modifier (round, square, figure, etc)
I always have problem when speaking English because can’t remember which one is which.
In German the same happens:
"runde Klammern" for (), "eckige Klammern" for [], and "geschweifte Klammern" for {}.
Although when you say only "Klammern" people usually understand (), because that is what is often used in texts.
This translates well:
runde Klammern --> parentheses, eckige Klammern --> brackets, geschweifte Klammern --> braces.
As such, the US English understanding of the words is clearer to me, than a non-distinguishing understanding.
"runde Klammern" for (), "eckige Klammern" for [], and "geschweifte Klammern" for {}.
Although when you say only "Klammern" people usually understand (), because that is what is often used in texts.
This translates well:
runde Klammern --> parentheses, eckige Klammern --> brackets, geschweifte Klammern --> braces.
As such, the US English understanding of the words is clearer to me, than a non-distinguishing understanding.
in commonwealth english () are "brackets" and everything else gets the shape modifier
I see they use they use the actual lambda character "λ" to create functions which is both cool and also probably makes grepping for functions a PITA. It does look pretty but I would have to search the web or write down the random keystroke to generate that symbol.
An example usage:
(filter (quicksort '(5 40 1 -3 2) <) (λ (x) (>= x 0)))
An example usage:
(filter (quicksort '(5 40 1 -3 2) <) (λ (x) (>= x 0)))
Haskell uses \ which is nice, it's an ASCII character that looks like the right half of λ
It's pretty common to wire \ to the lambda character in your editor. I think racket already allows this (if not as a replacement for lambda, an alternative syntax for it)
Functions deserve their own symbol in Lisp.
Though I prefer ^ since it’s easier to type.
https://github.com/codr7/sharpl
Though I prefer ^ since it’s easier to type.
https://github.com/codr7/sharpl
The language supports both (λ is just an alias... which I might remove)
Replaced the example with lambda - appreciate the feedback!
Replaced the example with lambda - appreciate the feedback!
[deleted]
This is also what Agda does (though \ is synonymous).
You can use a λ in many common Rackets.