So for a long time I found LISP elegant but I found the syntax infuriating.
-
@mcc cond is a particularly challenging form I never managed to come up with a clean formatting for.
(You can see examples including fizzbuzz of my whitespace sensitive Lisp at https://rosettacode.org/wiki/Category:Wart)
@akkartik This was my approach to cond, I called it the "match" statement
I think it's quite readable, but when writing it it's a bit frictiony to have to remember when to use [], when to use {}, and when to use () to get the results you wanted. (Note "match" is a *function* defined further up in the file; this LISP has no special forms, even the {}:. syntax isn't special forms, it's just inserting (, ) and ' in various ways.)
-
@akkartik This was my approach to cond, I called it the "match" statement
I think it's quite readable, but when writing it it's a bit frictiony to have to remember when to use [], when to use {}, and when to use () to get the results you wanted. (Note "match" is a *function* defined further up in the file; this LISP has no special forms, even the {}:. syntax isn't special forms, it's just inserting (, ) and ' in various ways.)
@akkartik Are there any examples of cond in the examples list above?
-
@akkartik Are there any examples of cond in the examples list above?
@akkartik By the way, something that may not be obvious in my sample code. I said {} is "lambda", but I was simplifying for space. {} is an argument-less lambda. In fact, {a b, c d} is shorthand for '((a b)(c d)). You upgrade a quoted list (a {}) to a function by passing it to the fn or set-fn builtin functions.
-
-
@akkartik Are there any examples of cond in the examples list above?
@mcc I basically got rid of cond because the `((` pattern seemed to require new delimiters. So instead `if` is multi branch as you can see in fizzbuzz.
My approach was to keep it memorable by minimizing delimiters. There are only parens, just like in regular Lisp. You can just avoid inserting parens sometimes, that's it. (And then infix arithmetic and $ for implicit gensyms 😄 I should create a version with just the paren insertion rules.)
I used the same approach as you for single word lines. No parens around them, but no error either.
-
@mcc I basically got rid of cond because the `((` pattern seemed to require new delimiters. So instead `if` is multi branch as you can see in fizzbuzz.
My approach was to keep it memorable by minimizing delimiters. There are only parens, just like in regular Lisp. You can just avoid inserting parens sometimes, that's it. (And then infix arithmetic and $ for implicit gensyms 😄 I should create a version with just the paren insertion rules.)
I used the same approach as you for single word lines. No parens around them, but no error either.
@akkartik Oh, multibranch if makes sense.
I'm actually doing a vaguely bizarre thing where the if statement can have an optional "else" because "else" is a global symbol which is defined as "false". If the symbol is non-false (eg, a block) it's treated as a case. i'm considering defining "elif" as "true" and special-casing that to determine whether the next item is a case or a condition.
-
@akkartik Oh, multibranch if makes sense.
I'm actually doing a vaguely bizarre thing where the if statement can have an optional "else" because "else" is a global symbol which is defined as "false". If the symbol is non-false (eg, a block) it's treated as a case. i'm considering defining "elif" as "true" and special-casing that to determine whether the next item is a case or a condition.
-
@SpindleyQ @mcc I've been annoyed by the lack of keywords in Lisp conditionals for.. (https://github.com/akkartik/wart/commit/c2e6d0c6d3) almost 14 years. Indentation should either mean "code that also runs" or "code that sometimes runs". When it can be either in a single stanza the result is shit.
-
So for a long time I found LISP elegant but I found the syntax infuriating. Then I made my own LISP variant with semi-significant whitespace and helper syntax— each line (up to whitespace or comma) is wrapped in an implicit (), a : wraps a () to the end of the line, a {} wraps its interior in (lambda), a [] wraps its contents in (list ), "x.y" becomes "get x y". Suddenly, I found it usable!
I wonder if I could just make an editor that applies these rules implicitly, and then I could use GUIX.
@mcc wait, are you aware of Wisp <https://www.draketo.de/software/wisp>, the indentation+shortcuts Scheme syntax?
It’s one of the supported syntaxes in Guile, so you can theoretically use it to write Guix packages.
-
@mcc wait, are you aware of Wisp <https://www.draketo.de/software/wisp>, the indentation+shortcuts Scheme syntax?
It’s one of the supported syntaxes in Guile, so you can theoretically use it to write Guix packages.
@aartaka I think it's very interesting!
I didn't know it was an option for Guix. That's good to know.
-
@aartaka I think it's very interesting!
I didn't know it was an option for Guix. That's good to know.
@mcc it’s an option for *Guile*. I’m not sure if it extrapolates to practical Guix programming, despite Guix being implemented in Guile. I don’t want to lead you astray here, because I’m uncertain myself 😅
-
( Look how fundamentally un-LISP-y my LISP is. I'm proud of it. https://codeberg.org/mcc/nameless-experimental-lisp/src/branch/unstable/sample/fizzbuzz.l0 )
EDIT: Wait, I think this sample code might be a bit out of date… this is from before the language had a "while" builtin, so it defines a "while" operation in terms of "if".
Wait. Can you write GUIX flakes (or whatever they're called) in Wisp?
-
Wait. Can you write GUIX flakes (or whatever they're called) in Wisp?
@mcc guix takes the radical approach of just using guile for everything instead of inventing another turing tarpit, so, probably?