Live data from Hacker News

Steel – An embeddable and extensible Scheme dialect

github.com

121–130 of 192 posts

Re: Steel – An embeddable and extensible Scheme dialect

#121

Earlier quoted context omitted.

Why? The properties of lisp make it suitable for both a config file, and an extension language. It can be easily embedded into existing languages and is extremely flexible.

Turing-completeness in a config file is an anti-pattern. Write an external program to generate the config file instead.

But then how do you write custom key handlers?

Re: Steel – An embeddable and extensible Scheme dialect

#122

This is a surprise! Steel is my project, happy to answer any questions anyone might have

May I ask, what is your personal journey of learning to code? Did you also discover Lisp/Scheme through SICP? And what have you professionally used Scheme for? I am currently going through SICP, and I am also interested in Rust, so this project is a great discovery! Maybe I can contribute to it also.

I learned to code primarily through school - I had the privilege of studying at Northwestern where a lot of the Racket people teach, so my first programming class was in Racket. I have worked through some of SICP and How to Design Programs. After Racket I learned some C, C++, and C#. Then taught myself python just independently doing some projects, ended up back taking a few classes in Racket, then one in Agda that got me down the programming language rabbit hole. Took a class in Rust and that got me working on Steel.

I haven't _directly_ used scheme professionally except for some steel scripts for automating some work flows and some racket programs for spark query plan analysis. I'd like to work in scheme more in my professional work, but for now I'm quite happy just working on it for fun.

Contributions are welcome! Feel free to either join the discord and ask questions there if you want a more chat based place, or open a discussion on github if you'd like to learn more. I have it on my TODO list to set up a matrix chat, just haven't gotten around to it - so apologies for having discord as the only chatroom.

Re: Steel – An embeddable and extensible Scheme dialect

#123

Earlier quoted context omitted.

Why not just program everything in assembly? High level languages give you powers of expression that lead to better programs or are simply more convenient for the particular task at hand. Lisp languages have several features that aren't found in most other programming languages. And a lot features that are found in other languages originated in Lisp. Perhaps what you are missing is the practical part. For that you sh…

>Perhaps what you are missing is the practical part. I think that's it. Thanks, I'll take a look at common lisp, especially at projects written in it.

Not exactly what you asked for but, if you have time, I would recommend looking at Practical Common Lisp:

https://gigamonkeys.com/book/

And also this blog post (which is a much smaller time commitment):

https://mikelevins.github.io/posts/2020-12-18-repl-driven/

Re: Steel – An embeddable and extensible Scheme dialect

#124

Earlier quoted context omitted.

Why? Emacs has Emacs Lisp and Neovim has Lua, it's great to be able to configure, write plugins and helper functions, in the same language.

So, if I use an editor config off the Internet, I need to inspect it for malware, because it's code, not configuration? Yes, there are languages for configuration - Jsonnet, Starlark, Dhall, which are execution safe - unlike Lisp and Lua!

Do you inspect all the code you run on your computer? You probably got all of it off the internet, except for the firmware blobs you couldn't even inspect if you wanted to.

And hell, even an "execution safe" configuration can contain malware if there's a parser bug.

At some point you have to choose who to trust and not to trust to write code that runs on your system, and all you can really do is try to verify that they did in fact write it, and run untrusted code in isolation from sensitive data.

Re: Steel – An embeddable and extensible Scheme dialect

#125
post #97

Earlier quoted context omitted.

I would use Helix in the terminal if it supported Emacs keybindings tbh but I don't want to relearn another set of keybindings. Still I'd be interested in what it becomes.

The keybindings is one of the major selling points of helix. It uses kakoune style object-verb action (like vim visual mode) by default with multiple selections. If you're comfortable with emacs bindings then you're better off with a lightweight emacs alternative.

As an evil user, this is potentially huge to me. Emacs happens to have the best balance of easy to setup configuration (relatively), powerful package ecosystem, and proper hackability of all editors I've found. It's not very fast though and has some conventions that feel archaic.

Re: Steel – An embeddable and extensible Scheme dialect

#126
post #18
post #7

Earlier quoted context omitted.

One option that might be suitable for a DSL, is implicit parens based on whitespace. A newline opens a new paren, and the paren closes when it reaches another line with the same indentation e.g: (defun factorial (x) (if (zerop x) 1 (* x (factorial (- x 1))))) could be rewritten as defun factorial (x) if (zerop x) 1 * x (factorial (- x 1))

Existing SRFI: SRFI 49 "Indentation-sensitive syntax": https://srfi.schemers.org/srfi-49/srfi-49.html

I doubt that SRFI 49, or any other proposal I've seen online, has been battle-tested.

I've written thousands of lines of Scheme using my own preprocessor, and it's my favorite code to look at. I prefer Haskell, for incredible ease of parallelism and a deeper mathematical foundation.

The two features I look for in a reduced parenthesis syntax (like looking for the bone marrow in a beef stew recipe) are:

1. Some constructions begin doubly parenthesized. One needs a symbol to represent the missing object one parenthesis in. I use $.

2. One can write more expressive lines with a flavor of open paren that autocloses at the end of the line. I use |.

Re: Steel – An embeddable and extensible Scheme dialect

#127

Earlier quoted context omitted.

I don't like curly braces, but I don't let that decide which programming languages I use.

That’s your choice!

People that express strong opinions about syntax come across as dummies to professionals. Doesn’t mean they are of course. Just sayin’.

Re: Steel – An embeddable and extensible Scheme dialect

#128

I want this to succeed!! please do not let the word "srfi" ever appear in the packages list...naming libraries with obscure numbers no one remembers was a terrible terrible idea that all schemes seem to perpetuate

SRFI editor here. The numeric designations are there because, among other reasons, there is sometimes more than one SRFI for a particular general idea. But there is nothing stopping libraries from having more than one name, including a semantically meaningful one. In fact, there has been a SRFI standardizing how that is done since 2008 [1].

[1] https://srfi.schemers.org/srfi-97/srfi-97.html

Re: Steel – An embeddable and extensible Scheme dialect

#129
post #88

Earlier quoted context omitted.

Yeah it is a personal issue, there are people who really like Lisp syntax (I'm one of them). That doesn't mean anything bad, of course, some people like dark text on a light background, others light text on a dark background. Everyone is different and that's what makes the world so awesome. I see something like: some-var: I64 := a * b - c ^ d ^ e; ...and my brain gives out, while I find: (let ((some-var (- (* a b) (^…

How do you look at the latter and know the code structure? Are you counting parentheses? Or are you relying on conventions around white space indentation. If the latter, are you not concerned a misplaced parentheses might make the code different from it appears? There could be bugs not shown in the indentation. Most lispers I know code in eMacs or other smart editors that provide auto code formatting and colored pare…

Auto code formatting is a must in every language at this point.

Re: Steel – An embeddable and extensible Scheme dialect

#130
post #88

Earlier quoted context omitted.

Yeah it is a personal issue, there are people who really like Lisp syntax (I'm one of them). That doesn't mean anything bad, of course, some people like dark text on a light background, others light text on a dark background. Everyone is different and that's what makes the world so awesome. I see something like: some-var: I64 := a * b - c ^ d ^ e; ...and my brain gives out, while I find: (let ((some-var (- (* a b) (^…

How do you look at the latter and know the code structure? Are you counting parentheses? Or are you relying on conventions around white space indentation. If the latter, are you not concerned a misplaced parentheses might make the code different from it appears? There could be bugs not shown in the indentation. Most lispers I know code in eMacs or other smart editors that provide auto code formatting and colored pare…

> But why not just make the indentation (or whatever that you really rely upon) the actual syntax, so there CANNOT be hidden bugs of that sort?

That's Python. When whitespace matters, any aesthetic reformatting mistake can change the program's meaning. With s-expressions this cannot happen. A lisp code parser is completely deterministic regardless of where the newlines, spaces, and tabs occur. You can remove all the newlines from a 10,000-line Lisp program and the compiler will parse it exactly the same as if it were formatted aesthetically.* You can also write a simple program that takes that godawful one-line program and reformats it aesthetically however you like--the meaning won't change.

IOW in Lisp the aesthetics of the source code do not determine its meaning; aesthetics and meaning are orthogonal properties and you are free to adjust the two independently. This is also somewhat true in languages like C, but rather than several special-case punctuation characters, in Lisp there's only one: The parenthesis. Lisp is thus similar in spirit to HTML where semantics and layout are [mostly] independent.

* With a few obvious exceptions like EOL comments, and newlines that are part of quoted strings.

Post reply on HN