Live CEOing Ep 695: Language Design in Wolfram Language [Underlighted and More]

Stephen Wolfram and John Fultz discuss design decisions in the Wolfram Language, including style sheets, resource objects, and interface improvements. They explore why certain features remain underlighted and how the language balances technical depth with usability.
Chapters
Sam.
All right. Hi, everyone. Welcome to another Wolfram Language Design Review. This will be a fairly short one, I think, today. Part of our Language Completeness and Consistency series. All right, style sheet, definition, style.
So most of this stuff is mine. And just FYI, there's probably more agenda items than we're going to go through in the allotted time today. But we'll make what we can. Okay, so the. In terms of supporting the style sheet repository, the we have a significant issue that style definitions can only take certain things, and it's usually the front end is pretty good about. If it receives something it just doesn't recognize, then it preserves it, and it may behave badly, but it preserves it and then serializes it back out uncorrupted. But not so with style definitions. So I can't do, like, style definitions, arrow, resource, object, or something like that, because older front ends will corrupt these notebooks. So what I'm proposing is basically that if we want to have a resource object style sheet that we reference, that essentially it's always going to live in the same sort of text that we use for inherited style sheets.
That's a micro notebook, effectively.
Yes. And this is exactly the. I mean, if you do format edit style sheet in a new notebook, what.
Happens if I say notebook put of that thing? Does it. Oops.
Yeah. Yes, you can see it right there. There is a style data cell. You are running a legacy version because we haven't made a new version yet. And it says, I don't know what this is, but it's not going to corrupt it.
At least the fonts are the same as they were in 1987.
So if you do, on your new notebook, you do format edit style sheet.
Which new notebook? This one here?
No, in your Untitled 11.
Okay.
Just in the menus. Format edit style sheet. Okay. And then if you select that, that cell and show cell expression, this cell there. Yes. And you'll see this is very much the same sort of thing we're already doing for style sheet inheritance. All right? The only issue being we don't yet support Resource Object, but at least if we serialize this way, we're not going to corrupt anything.
Okay.
And also, I think it gives us an opportunity to do things asynchronously. You know, we can load up the notebook and say, well, we don't know what the style sheet is yet, but it'll kind of start off with default and then pop in once we've loaded.
So let me just understand something. So, I mean, in terms of the workflow, there'll be the style sheet repository and then you would presumably in that repository you are able to either apply a style sheet to an existing open notebook or create a new notebook that is in that style.
Well, it's a good question what the workflow is and I actually raise one possibility under the related issues, which is that I could come up with some sort of auto interpreted copy and paste. Kind of like, you know, the copy paste cell expressions do their auto interpretation. I could come up with something like that that basically auto switches your style sheet to, you know, to the given resource object.
Sorry, say that again, I got distracted for a second.
Could you say that? So you know, you copy a cell expression and you paste and it auto interprets as a cell express as a cell.
Yes.
I could come up with a magic thing that auto switches your style sheets and then, you know, it would be a click to copy on the, on the resource page.
So I don't quite understand what would happen. So you click it on the resource page and then you would paste it into your notebook and poof, it would kind of spray itself all over your notebook.
Is that exactly? Exactly.
Yeah, I think it's a good idea.
It would change your style sheet to be that expression.
That's exactly what it would do. Yes.
So if you were, if you wanted to add that style sheet to the notebook style sheet as, you know, multiple inheritance, like if you didn't want to overwrite everything and you just wanted to add these styles to maybe something you'd.
Already defined that that would require a bit more knowledge and something a different.
Yeah, okay.
Yeah, okay.
But it's going to be a little weird, this idea about you just. I mean, it's like saying it's like some of these UI things where you're moving files around, you just drop a file in some general area.
Yeah, I mean, it is weird because you would be pasting something and you wouldn't see an actual thing paste, you would see styles change. But I mean, there are other applications that allow you to copy and paste styles. True. They don't generally work between applications though. Right. Usually that's only a thing that works inside of a given application.
Okay, so by the way, are there security issues with dynamics and things like that that could exist in styles?
Yes, yes, there are. And I think that the stylesheet repository probably needs some level of curation for that.
Okay, fine, fine. So then it will assume it's curated and so we will assume that it's safe to paste.
Yeah. Okay.
For the issue of not being able to Set a resource object for style definitions. Could there be like an alternate string syntax, like resource Object?
No, believe it or not, it munches strings too.
Oh, okay.
Yeah.
Cause that just seems like that would be hard for a user to figure out, like set options, what they would put in for style definitions for a resource object.
Yeah, I mean, the only other thing that I can do is just come up with a brand new option.
Yeah, right.
And that's going to be clunky because then the two options are fighting one another. Right.
Well, I think that this. If what mostly happens is people are getting it from the repository or a private repository. I think it doesn't. They don't. They're not going to see what this code is underneath.
And you know, and when you do set options. Right. It's not like the kernel directly sets it in. In the notebook. It sends a request to the front end. So we could conceivably have something. If you do set options and you set style definitions to a resource object.
Then this is true. Yeah, that's a good point. That's a good point. Yes. I like that.
Sorry, what did you just say?
So the idea being that the set options command would have a bit of sugar. So if it receives a resource object, it would actually construct this notebook expression.
Yeah, that makes perfect sense.
Yeah.
Okay. But then the main thing is that the flow is going to be. There's going to be a bunch of sort of samples of the. Of styles in the style sheet repository. You click to copy, you paste it and it sprays the style on what you have. Yeah, that's the basic.
Is that undoable like with command Z?
Not at present, but it wouldn't be difficult to make it undoable.
I almost wonder if if pasting like a. An interface, like a button that, you know, click to apply that and then.
Click to clear it would be nice. I agree.
Well, you can always just do format style sheet, default to.
Nobody's going to know to do that.
So open up the related issues section, Stephen. So I, you know, I talk about the paste interpret thing, which you've already been discussing. I also wonder whether things that you recently applied should show up in the style sheet menu somewhere.
Why not?
Yeah.
Down at the bottom or something.
Yeah. Okay, that's.
That's easy enough to do probably before other. But yeah, I like the idea of having. I think it's much less obscure if you get an interface.
In. In theory, if you had like four style sheets you wanted to try, you could paste each of them and they'd have their own button. That's part of why I think pasting a button might be useful.
All right. Okay.
But.
So this has to be developed and.
Yeah.
Together.
Well, and, and I, I imagine that there could be an interface that lives in the other. Or the style sheet chooser dialog. That's not necessarily going to happen right away, but, but I wanted to. Even though, you know, the style sheet repository may not be ready on this time frame, I wanted to start building and support in the front end for. In anticipation of these guys. So we, so we wouldn't have an interface in 13.3, but I can get the other machinery in.
Okay, so hold on. There's also the question of.
The.
In the cloud, how this works.
Yes.
And I think the style sheet support in the cloud is inadequate at this time, but hopefully will improve. But then there's the question of how all these steps work.
Yeah, okay. Yeah.
But anyway, we've got the beginnings of this and we can see there's not. It's not devastatingly hopeless to have the. At least for the desktop, to have the styles appropriately used, but we should check with the cloud team. I don't know whether there's anybody here from that team today about how this can work.
Yeah, so they, they do support private style sheets, and this is basically a flourish on a private style sheet. So I'm hopeful that it's not going to be a lot of effort for them.
All right, let's move on to.
Oh, you're not using a recent build.
Okay, well, I mean, tell me what to do. I, I can go to a prototype build.
Okay.
And I think for the resource folks, I think that was all that we needed you for. Thank you, man.
Thanks.
Thanks. Okay. Under lighted, Sandra is commenting on her that he doesn't like the name. And we also had terrible trouble with the name yesterday. Where does that name come from?
So it was, it was a random name that a developer added to it, which I did not change because, frankly, I thought about, you know, I thought about trying to come up with a better name, and I couldn't come up with one.
Yeah, okay, fine. Okay. So it was added in 2016, I found from my archive.
Yeah, yeah, it's been there for a while. Right.
Okay. But, but, but, okay, so what should the name be? So is there a name for. I mean, is there an official name for the squigglies that show up in.
I am not an official name. I've, I've never seen a name for these things, And I'm uncomfortable with using the Word squiggly. Because one of the things we've discussed is having variations of these things that wouldn't necessarily be squiggly.
I agree. The wavy red underline, it says and. Hmm, Wow. Even Microsoft refers to it, not the red squiggly underline. They call it a squiggly too.
So, I mean, it is related to highlighting. I know it's not what we think of as, you know, like a yellow highlighter sort of thing, but it is related to the conceptually.
Well, I mean, so the question is, could it be a feature of highlighted?
Well, highlighted does not correspond to a front end option. We, we would still need a front end option name. And maybe you decide the front end option name can be a bad name and that's. Okay.
Well, but. Okay, so hold on a second. Highlighted right now as a wrapper. That is a symbolic wrapper that stays. Whereas under lighted. Now I'm very confused. Under lighted is also a symbolic wrapper that stays or not.
Depends on your definition of stays. Right.
I mean, yeah, the type form will evaluate to identity effectively. It'll remove the head on reevaluation.
Right.
And.
Oh, let's remind ourselves what we're using this for. Okay, so, for example, it's used in the code assistance system to indicate potential errors. Correct.
Right, but, Right, right, but one thing that was said in yesterday's livestream, which isn't quite accurate, is that, that you can't really assume that, oh, you can just put it into editable code and then people can edit it and everything will be because, and this is true with highlighted as well, that, you know, the thing which does the highlighting imposes structure, and that structure might drop away on evaluation. But it exists for purposes of editing.
I mean, but the interpretation function is basically £1.
Right?
So if you're editing it, that'll still be there.
Right, right. But, but, but, but it means that, you know, you have to, you know, what's inside the highlight has to be evaluateable. That's true, Yeah. I mean, you can't, you know, if you add, you know, plus one to the example here, you can't have the plus inside the highlighted and the one outside the highlighted.
So it has to be a syntactically complete sub expression.
Exactly, exactly.
Okay, but whereas the underlying thing does not have to be a syntactically complete sub expression. Or is that not the case?
Well, in fact, the way that underlighted is used in Code Assist and is that it might not be syntactically complete at all. It might you might be underlining under lighting an operator pure box and infix operator.
Right.
And the way underlighted was implemented, it is like highlighted. Now we could change the implementation.
No, I think we've got a box level implementation that can span different sub expressions and we've got a language level implementation which is a pure syntactically correct. Because there's nothing you can do at the language level unless you're down at the level of boxes. You cannot deal with syntactically incorrect. None structured things.
No, that, that, that's not at all correct. Right. I mean, okay, you the. Right. The output is going to be some boxy thing, right, which you can copy, and then you could edit it. And then you could edit it to not be synthetically correct. Maybe you're saying that's not a useful workflow, but, you know, I'm suggesting that.
We have two levels of this. Right. Just like highlighted is always highlighting a sub expression. Right. A syntactically meaningful sub expression. Actually, it's more than syntactically meaningful. It's, you know, semantically evaluationally meaningful sub expression. Because.
But that, but, yeah, but that has nothing to do with the point that John and I are making.
Okay.
Which is you might want to edit that output and you can, you know, we could make it so that what's inside the underlight is, doesn't correspond to a sub expression if we wanted to. Now maybe we don't want to, but.
I understand, I understand. You're saying that you could allow that the box expression. I mean, I don't understand why the thing isn't making the same box expression that it would make were it to be generating raw boxes, but the boxes happen to have a complete sub expression being the highlighted thing, if that makes sense.
Right.
Look, the, the number one issue here is we need a name analog to highlight, analogous to highlighted. That. And I'm not quite sure why we don't have a second argument to highlighted. That is just the manner of highlighting.
Well, so that's possible. Like I said, we would still have to have, you know, the front end option name and the front end option name could continue to be underlighted, and we just don't care about that because it's sort of in a ghetto of front end option names.
Is it an option name or is it a setting?
It's, it's. It's a front end. Well, it's a sub option, actually. It's a sub option. Of what? Of font variations.
Variations as right there in the agenda. We're Complete with screenshot and link to said ref page.
Where are we looking? Here comes. I don't understand. Documented. Oh, I see. Documented here.
Right. On font variations.
Okay, but, but, but styling the. I mean, it's, it's amusing to call it under light in that case, but I mean, if that case is always going to be the red, I mean, where does the color of that get set?
That's the value of the underlight specification.
Oh, the color used for highlighting.
Yep.
So you can't say underlight goes to. True. But for the. The wrapper function we made, we had a default color, which is red corresponding to the spell checker color.
Okay, so look, the obvious thing would be, since we got underline, the obvious name will be under wavy or something. Because an underline is a line underneath something.
Yeah. So there is, you know, aside from the shape, there is another fundamental difference, which is that underline is always the color of the fonts, whereas I see under lights is quite often not the color of the font. And it certainly, you know, the point being it has an independent color specification.
It's a weird name, but it's not. I mean, we have been using it for a number of years and it's not obviously. Well, look, it's all. Is it always going to be a wavy line of unknown color?
So we have talked about, I mean, one specific proposal we had, although I think that proposal may have aged out and, you know, never got implemented, but was a railroad track version, kind of like slant, you know, like a row of slanted lines that look like slanted railroad ties.
Yeah.
I mean, if we want may, you know, maybe we.
Right.
I mean, we could have a second argument to highlight it, which is, I don't know. Again, we'd have to come up with a name for it.
But.
And Right. We could have a string name that's, you know, just the.
Well, but we've only got background colors highlighted, has specifications for background color, does not have a specification. It's going to get weird because it is a. It's a full background highlighting.
Right.
Look, I mean, this is sort of an emphasis thing. We could call it. Emphasis line color or emphasis line style. We could call this thing an emphasis line.
That's not ridiculous.
Okay, so then that option would become emphasis line style, And then the style will be a color. Or we could generalize that to something different.
Yeah, I mean, we don't support this right now, but one could imagine, you know, like thickness or something like that as well.
Right.
I mean, adding the style is a bit weird.
Right.
I mean, none of those things have style in them.
Yeah, but none of them have. They're all true. False.
No, caps type is not true.
False.
Well, but, but it says type at the end.
It's okay.
Right. As opposed to just being a statement.
Okay.
Let'S try emphasis line style. I mean, and we're describing it as a line or emphasis underline style. Maybe that would be the best, the most explicit thing to call it emphasis underline style. So the, the noun form of the thing is an emphasis underlying. Hello? What?
Well.
Okay, let's take a very quick look at these other things. I'm really going to have to go in a second here.
Okay. I had demos that were totally working and then a massive demo breakage on this thing came through, which is a shame because I really wanted to show you this. But the point being, we have support for nested action menus. This is the syntax that we're using right now. I'm hugely in favor of this syntax, but of course, want to run it by you.
Seems sensible to me.
Okay.
I mean, because I don't think it means anything. The only, the only thing that could happen is there's an ambiguity here, obviously. Right.
It evaluates the right hand side in a. In the legacy version. But the evaluation of a list generally is not that useful.
Well, I mean, you're saying that a particular action element. Yes. Because an action menu is doing side effect things.
Yes.
Right. A list is kind of a blah, you know, side. Effectively, it's not very useful because you never get to see the list.
Yes. I mean, it's not even really ambiguous because it's rule versus rule delayed. Well, to be clear, it does work with rule delayed. And it's not like I'm going to, you know, we're going to punish users if they use rule delayed. But yeah, my better guidance is to use rule. Right.
So, sorry, I was trying to quiet a ringing phone, so I missed a transition between the. Those two agenda items. Did we come up with a name for the head version?
Oh, we didn't.
Okay.
Well, we could call it emphasis underlined.
That works.
It's a bit long, but I don't think it's terrible.
Okay. Okay. Yeah.
It's a little weird.
Just call it emphasized. Or is that too.
Yeah, it's not obviously wrong. Not obviously wrong. Particularly if emphasized had multiple, you know, different second arguments that gave different forms of emphasis. It could activate any of these font variations. For instance, outline, shadow. Yes.
Right. So maybe in, maybe in an initial version, it just takes the color and uses emphasize. But then we could extend it to understand these other things or. And even combinations thereof.
Right.
That seems reasonable. Yeah. Okay.
We should wrap it up for now.
Thank you. Yeah. Yeah. The image margins thing is a bit. It will take a bit of time.
To work through, I'm sure. Yes.
And the other stuff is not as urgent.
All right, look forward to seeing it all. See you all soon. Thank you to folks on the live stream for their comments as well.
Okay, great.
More from Guy

Cheryl Strauss Einhorn | The Human Edge: Smarter Decisions in the Age of AI | Talks at Google

Rachel Glennerster | Innovation and the Center for Global Development | Talks at Google

Rebecca Winthrop | Rethinking the Purpose of Education in the Age of AI | Talks at Google

Dr. Robert Wachter | A Giant Leap: How AI Is Transforming Healthcare... | Talks at Google






