Live data from Hacker News

Steel – An embeddable and extensible Scheme dialect

github.com

141–150 of 192 posts

Re: Steel – An embeddable and extensible Scheme dialect

#141
post #4

When I tried to introduce s-expressions to a DSL my co-workers nearly lynched me. The parenthesis were so violently hated I sunk into a deep hole and still haven’t came back out of it.

The things I'm looking for in language syntax these days are

1. That it's unambiguous enough that my editor can format it correctly every time (provided the code is correct, obviously). Indentation-based languages like Python fail this.

2. That its elements and keywords are distinct enough that my editor can apply colours on it. I sometimes feel that S-expression languages fail at this because of their small number of distinct keywords, but that might not be true.

Besides these two points, if the language is not a joke language, it's probably fine.

Re: Steel – An embeddable and extensible Scheme dialect

#142

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!

Why would you use an entire config off the internet?

Re: Steel – An embeddable and extensible Scheme dialect

#143

Earlier quoted context omitted.

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 th…

I install software from credible sources. I do reuse configs from dotfiles off the Internet - just like most people do.

There are way more configs out there than there are software projects.

Re: Steel – An embeddable and extensible Scheme dialect

#144

Earlier quoted context omitted.

I'm familiar with the Steele quote. The manner in which C++ programmers were "dragged halfway to Lisp" concerns primarily manual memory management and all the bugginess attending thereto (Java came out before the STL and smart pointers were widely adopted). Concerns about memory safety were a significant part of the impetus for developing Java in the first place. Steele was responding to complaints that he had turned…

Java came out before the STL and smart pointers were widely adopted. This is a strange comment. Java 1.0 was released in Jan 1996. (Java wasn't very useful before 1.1) However, Stepanov proposed STL to ANSI/ISO committee in Nov 1993, and HP released a working version to the Internet in Aug 1994. "[W]idely adopted" is an editorial term. It is meaningless without some backing evidence. ("Never been worse" has a similar…

Rust spent its entire innovation budget on zero-cost memory safety! Basically, instead of you tracking lifetimes (like in C with malloc/free) or the runtime tracking lifetimes (like in a GC'd language), Rust lets the compiler do this with a 'borrowing' system.

Borrowing in Rust means objects exist in two states: owned (which get dropped when they fall out of scope, like in C++), and borrowed, which means some other scope owns the object and we only have a reference to it. The compiler verifies that a borrow cannot outlive the actual object, so it statically prevents use-after-free errors.

Rust also has a distinction between constant and mutable values, and statically checks that any mutable references are exclusive, and that immutable references are only shared with other immutable references. With this it helps prevent race conditions or other such mistakes.

Finally, Rust also actually has smart pointers in case you truly don't know when an object won't be needed anymore, although the names are a bit different than in C++; there's Rc/Arc for reference counting (like shared_ptr), Box for owning pointers (like unique_ptr?), and RefCell, that's like a runtime borrow checker.

Apart from these features that prevent use-after-free and aliasing, Rust also has a feature called 'unsafe' with which you can bypass all these and e.g. work with raw pointers. Unsafe is generally used sparingly (and if not, attracts a lot of criticism, like happened to actix-web), and the safe abstractions on top also provide more pedestrian safety features like bounds checking. You can skip bounds checking on e.g. a Vec, but doing so actually requires you to drop into unsafe yourself, since the get_unchecked function is marked unsafe in the stdlib.

Small interesting side note: I'm pretty sure Rust is actually doing very little new things, PL-design wise. It's more of a realization of theory that has been around for years if not decades.

Re: Steel – An embeddable and extensible Scheme dialect

#145

Earlier quoted context omitted.

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…

> any aesthetic reformatting mistake can change the program's meaning.

Why would you just randomly change indentation? On the contrary, I don't want the indentation to say something else than the code actually does.

> 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.

But a human won’t. And that’s a problem.

Re: Steel – An embeddable and extensible Scheme dialect

#146

Earlier quoted context omitted.

I'm not a fan of the parenthesis either, but when I learned about s-expressions and how lisp programs are also a data structures that piqued my interest and helped me look past them. I question people's judgement who can't look past the syntax when there is a very good, and interesting technical reason behind them.

A-expressions are a choice, and it is fine to argue whether it is a good one. There are plenty of other ways of achieving honiconic syntax.

What's an A-expression? I tried looking it up but didn't find anything.

I have heard of M-expressions but never of an actual implementation. Scheme also seems to have some SRFIs involving alternate syntax that's whitespace dependent, like SRFI 119 (wisp), SRFI 110 (sweet-expressions or T-expressions), or SRFI 49.

Re: Steel – An embeddable and extensible Scheme dialect

#147

Earlier quoted context omitted.

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 th…

I install software from credible sources. I do reuse configs from dotfiles off the Internet - just like most people do. There are way more configs out there than there are software projects.

You already face the same threat then. Many, if not most, nontrivial programs have at least one way to escalate to arbitrary code execution from config. For example sway has exec, basically any useful editor has "on save actions", etc. No need for a Turing complete language when you can just shell out.

Re: Steel – An embeddable and extensible Scheme dialect

#148
post #4

When I tried to introduce s-expressions to a DSL my co-workers nearly lynched me. The parenthesis were so violently hated I sunk into a deep hole and still haven’t came back out of it.

The things I'm looking for in language syntax these days are 1. That it's unambiguous enough that my editor can format it correctly every time (provided the code is correct, obviously). Indentation-based languages like Python fail this. 2. That its elements and keywords are distinct enough that my editor can apply colours on it. I sometimes feel that S-expression languages fail at this because of their small number o…

What is ambiguous about Python’s syntax?

Re: Steel – An embeddable and extensible Scheme dialect

#149
post #145

Earlier quoted context omitted.

> 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…

> any aesthetic reformatting mistake can change the program's meaning. Why would you just randomly change indentation? On the contrary, I don't want the indentation to say something else than the code actually does. > 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. But a human won’t. And that’s a problem.

> Why would you just randomly change indentation? On the contrary, I don't want the indentation to say something else than the code actually does.

Because the user may want the development environment to display snippets of code in various places: REPL, debugger, code browsers, inspectors, various editor types, ...

In a Lisp system the code can be data and text. Code formatters can reformat code depending on user preferences, device types (color, font, ...), view sizes, ...

In Lisp often code gets generated (for example via 'Macros') and this code will be automatically layouted in various view (different widths, different fonts, different detail). Code can be small or large, the system may abbreviate parts, which one can expand, if necessary.

Source Code is not necessary static text in a file system. Code can just be list-based data structures and layout is fluid.

In Common Lisp the formatted output of code is also user extensible/customizable, a 'pretty printer' is a part of the language spec:

https://www.lispworks.com/documentation/HyperSpec/Body/22_ba...

If we read a text in a book reading the device, one can also change for example font size and the thing will relayout the text accordingly.

Re: Steel – An embeddable and extensible Scheme dialect

#150

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.

This is why I always only put finite memory in my computers.
Post reply on HN