gavinhoward

> First-class symbols (incl. uninterned symbols)?

Yes.

> Classes and functions can be redefined at runtime?

No.

> User-available parsing (read) and runtime compilation (compile)?

Yes, though runtime compilation is not implemented yet.

> Restarts?

Yes, though they are only implemented in the runtime; the keywords don't exist yet.

> CLOS and MOP?

No, the object system will be more recognizable to non-Lispers.

> Communication with the compiler (declarations and ClTl2 *-information)?

I wasn't able to find info on these. I will keep looking, and I would appreciate pointers, but the answer is probably no.

Edit: after skimming [1], the answer on declarations is probably yes, for the most part. Still searching for *-information stuff.

Edit 2: After skimming [2], Yao originally didn't have any concept of stuff like the *-information functions, but those are good ideas, and I will add them.

[1]: https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node105.html

[2]: https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node102.html

That is why I need lawyer money.

But I have actually gotten halfway with a lawyer. A lawyer actually wrote the No Duty clause.

I designed my own, uncreatively called Yvm. Yao already compiles to it.

The post answers that.

Every unmarked function can do anything. If you add a new thing that functions can do, you assume unmarked functions can do it (even if they don't), and you add a trait for the negative.

I only have one Perl script in that repo...

Anyway, Yzena is my business. I am not a very good marketer, and the website is bad.

I also don't think I will get any business, but eh.

Programs written in Yao.

Good question.

Yao's concurrency will be explicit. You will not get concurrency unless you open a threadset and spawn threads. Yao scripts run in a single thread by default.

I focused on solving the concurrency problem because if it is solved, single thread code is solved as well.

I agree. I think getting provability right would bring reliability along with it.

Good question. I will add that.

It means that users' convenience comes before my convenience. (I am the programmer in question.)

This means that if there is something I could do to make things easier on users, I do it, even if it is a lot more work for me.

An example is https://git.yzena.com/Yzena/Yc/commit/c9086af225d42b2f125959... . Comments in Yao do not use the `#` character, but I added the shebang to the parser specially so that scripts could be run just like any others scripts.

Yes.

In the crypto example, the backend would have to be sophisticated enough to know when the same addresses would be accessed every time, like bitslicing in AES. [1]

The devil absolutely is in the details. This is why I say Yao's capabilities on this front are unproven.

[1]: https://www.bearssl.org/constanttime.html#constant-time-in-b...

Yes, sorry. I should clarify that.

Fair criticisms, John. I just want to address macros.

Yao has something like Rust's macros. They are called "keywords," because even the built-in keywords are implemented that way. (That is why Yao can just not have a `while` keyword.)

My Yao-based build system, Rig, uses keywords to implement a build DSL. [1]

And keywords are fast to compile.

[1]: https://rigbuild.dev/build.rig5/#keywords

Yes, you are correct.

My idea is to cause a compile error if the backend can't use all instructions for which it knows the worst case latency or if it can't use purely constant-time instructions.

This is one of the nicest, yet honest, compliments I have ever received. Thank you!

Please don't jump to Yao! The only thing it's good for right now is to replace shell scripts.

I wish I could upvote you twice.

I decided on my values because of bcantrill's talk. Everyone should watch it.

A more complete list of my values is at https://git.yzena.com/Yzena/Yc/src/branch/master/docs/adl/00... .

Author here.

You are absolutely right to be skeptical. I wrote that a long time ago.

I did detail the current status of those claims in a comment: https://news.ycombinator.com/item?id=41672316 .

Specifically, a disclaimer of duty. https://yzena.com/yzena-noncommercial-license/#no-duty .

For why, see questions 33-36 at https://yzena.com/yzena-noncommercial-license-faq/ .

I have no beef with FSL. FSL is totally fine.

I would just prefer to have more liability protection.

Author here.

Yeah, you shouldn't believe it yet, but here is the status of each:

* "As powerful as C": unproven. I might need something like Rust's `unsafe`, and even though I have something in mind for that, it requires that any program be expressible in Dynamic Restricted Structured Concurrency, an open problem. I am working on a proof, though.

* "As flexible as Lisp": I think this is proven. Yao has equivalents for both macros (keywords) and reader macros (lexing modes). My build system uses its own keywords to implement a build DSL [1]. The shell sublanguage uses a lexing mode, and another makes it possible to embed JSON.

* "As easy as Python": in retrospect, this isn't quite possible, but I hope to get 90% of the way.

* "As provable as Ada/SPARK": I'll let you read the design in [2] and decide for yourself. But Yao will also have contracts.

* "More reliable than Rust": unproven, but I think the lack of async will go a long way.

* "With the time semantics of HAL/S": unproven. HAL/S was what the Shuttle software was written in [3]. It was hard real-time. Because Yao will be distributed in IR form [4], the back end could leverage knowledge of worst-case instruction latencies to calculate worst-case response times. This same thing will also allow using only constant-time instructions for cryptography, using a `constant_time` function trait.

[1]: https://rigbuild.dev/build.rig5/#keywords

[2]: https://gavinhoward.com/2024/05/what-rust-got-wrong-on-forma...

[3]: https://www.fastcompany.com/28121/they-write-right-stuff

[4]: https://gavinhoward.com/2024/09/rewriting-rust-a-response/#d...

This is partially why I began to look at source available more: https://gavinhoward.com/2023/12/is-source-available-really-t... . And what I found is that source available can still be good for end users, leaving us most of the four freedoms, including control, while discouraging dealers.

I explain how Rust missed the mark in [1].

[1]: https://gavinhoward.com/2024/05/what-rust-got-wrong-on-forma...

As someone who thinks the industry should professionalize, I actually agree with you somewhat; we pushed too far, too fast, and into territory that software has no business being in.

I don't quite agree, but I do somewhat agree.

We need to professionalize and actually accept liability for our work. [1]

[1]: https://gavinhoward.com/2024/06/a-plan-for-professionalism/

I don't like systemd, but I don't like s6 either.

What we need is something simple that uses something easy like unit files. (Though I wouldn't choose the systemd unit file syntax.)

Unfortunately, I can't really say much about historical design.

Gavin Howard here.

There really isn't a design choice to be made. POSIX requires unary negation to have higher precedence.

The only precedence change (I can remember) from GNU bc is that I changed the not operator to have the same precedence as negation. This was so all unary operators had the same precedence, which leads to more predictable parsing and behavior.

I am Gavin Howard, the author of the other dc.

My dc does have a few differences from the GNU dc. I added the extension of using _ as a negative sign.

That is why you are both seeing behavior differences.

I am the author of that dc.

You are correct about its behavior.

See https://git.gavinhoward.com/gavin/bc/src/branch/master/manua... (scroll down to the underscore command).

This is definitely a thing.

However, there are some people who can't. I am one of them.

And that is why I am not successful in my career.