Live CEOing Ep 642: Language Design in Wolfram Language [SpokeString, StringTransform & More]

Okay. Hello, everyone. We are doing a Wolfram language design review. This is part of our incremental language development series, and we have a variety of topics here. Spoken string. That is really lame.

Right? So this was an example that was fed to us here. And we have Francisco and I believe, Danielle also potentially talk about this. I wasn't in the meeting where this originally came up, but I got fed in, which is obviously a suboptimal result.

Only to add that we were already doing some changes in spoken string in a branch. We have all these changes and we haven't yet got into this option of real precision limit. So this is a good opportunity to decide what to do.

Well, I think it's pretty simple. I mean, I mean, I don't understand what. What is the. I mean, But I mean, this is just wrong, this thing here. I mean, the default. What? What's the default value? Oh, I see. The default value of real precision limit is three. Well, that's kind of crazy. It should be automatic, right? The default should be automatic. And if there's an explicit precision, I say read all the digits, you know?

Yeah, I agree. So if a number comes with five digits of precision, we show the five, if there are 10, 10 or whatever.

Right?

Yeah. I mean, if it has an explicit precision tagging as opposed to $. Machine precision. But because, I mean, if I say precision of n of PI, it's machine precision, so. Machine precision.

Right. I mean, I think what's weird here, like for example, the option print precision. Right, right. That only affects machine precision numbers.

Yes, Right.

If you do style of N with print precision goes to five, you'll see five digits. But if you do n of PI back, you know, n of PI comma 10 with inside of the same style, you'll see 10 digits.

Yeah. So what's your point?

I mean, look, my point is that I think it's odd that this thing applies to both machine precision and arbitrary precision numbers as opposed to just machine precision numbers.

Yeah, so that's what we should do. I mean, machine precision limit.

So this option will apply only to the machine precision values, like the front end, for example, when you.

Yes, and if you've got some other thing with 10,000 digits, then read 10,000 digits. I can't see any reason why you would want to not do that. See what I'm saying?

Well, if it were actually spoken, you know, if you ran speak of this, you wouldn't want to read 10,000 digits.

Yeah, but I think there's a different thing which is spoken string arguably should have some overall limit. That's a different thing. I mean, I'm not sure that it's worth us worrying about this right now, but I can see that.

There'S a similar issue of integers, right? Like if you have, you know, a million factorial or something, you don't want it to actually, you know, you wouldn't want to speak that giant integer either. I don't know if this. Oh, it has an integer limit.

Yeah. And also there is a string length limit, which I guess that's the one that maybe we should play more with that option.

I mean, strings and symbol names, right? Look, I think this is one of these things where it isn't broken. I mean, let's not hyperventilate about fixing it. Let's fix this particular issue and let's not worry about anything else. Okay?

Okay, that's fine.

And I mean, maybe we should say machine precision limit and we should say real precision limit as a separate thing and default it to infinity.

I'll give him precision number.

What's that?

No, no, that I. I think it would be better to have automatic as value for which. For the real precision limit.

No, but I'm saying that we want. You want to switch if you have machine precision read three digits. If you have arbitrary precision specify just like with integer limit and so on, that you don't want to go on for two years reading stuff. See what I'm saying? So breaking it into two options.

Yeah, that makes sense.

Yeah.

Okay.

So real precision limit and something like machine precision limit. Okay, let's move on. String transform.

So this is partly from going through low hanging and some of our other outstanding tickets, but we have a handful of existing string transformation functions that either deal with capitalization or encoding and a bunch of proposed or semi greenlit functions that deal with variations. And what I'm wondering is, you know, we've looked at those individually, but holistically, do we want to have some sort of parent string transform or text transform function and have different methods of converting it, or do we really want to have a URL encoding a slugifying function, capitalizing?

You know, I think some of these.

What does slugify even mean?

It means.

So a slug is like in typography, like a hyphen or an underscore. It's to connect words together. So like URL slugifying is removing spaces, inputting hyphens or underscores.

Yeah, I think there are different categories of thing here. I think there are things where it is a. I mean something like capitalized decapitalize.

Kind of makes sense as a first class.

Yeah, I think so. Right.

And I also understand what that is. I mean camelize, I can, I can sort of.

Yeah, but these are, these are.

But string smooth and string contract. I have no idea what those are going to do.

Yeah, I have no idea either.

I like string implode and string explode as names. I have no idea what they do.

But yeah, what do they do?

So I believe those ones are actually in low hanging that we'll be looking.

At in a little bit. All right, okay, fine. I personally favor string encode, string decode as a generic thing in which we give, you know, camel case slugified etc etc etc as the destinations. Because I think that a typical thing is you've got text and you want to do something like you want to create a URL, you want to encode that string in some way. Mm. And you know, you choose different things you want to encode for the encoding. But they're all sort of the same idea. So that would be my.

Well, one point might be that there are cases where I don't know if these are really different, but there are cases where it's like you have a big thing of text like the. Where is it? The email quote unquote. And then there are other cases where like for example, I have something in camel case and I want to convert to snake case or something like that where it's more of a. You have like a limited string and it's more of a conversion.

I know, but I think I agree with you and I think that encode decode should probably mostly deal with the short case. You've got one sentence, you want to put dashes, you want to put camel casing, those kinds of things. Because I think that's what most of these are. The email quote unquote thing is a different thing. And I don't know whether there's a category of thing like that. We can decide that later because that to me is more anyway is more text related than it is a string related thing because it's something that involves, you know, lines and things like that as opposed to the, the pure. I want to make this camel case or I want to, you know, put dashes and so on.

Well, so what's the distinction then between camel case making something camel case and capitalize other than just the capitalize is a more common, you know, human understood.

Thing I think capitalizes with separate words. Whereas camel case is. The words are smooshed camel case.

Look, no, I understand what the difference between the Functions would be. But. But the question is if both of them basically take a bunch of words separated by spaces, you know, and one of them capitalizes the first letters in.

Some way, string encode should allow capitalize as a second as a string second argument.

So I'm just asking that what is the. What is the reasoning behind which capitalize also gets its own function when Camel case.

Because it's popular.

Okay, fine.

Camel case. You know, the camel is just not such a popular animal.

Fine. One other thing would be, what about cases where it's more of a conversion operation than just an encoding? Like the case of convert it from snake case to camel case.

Well, what is snake case?

That's like underscores. I mean, there are a lot of cases like that where you can probably figure out what the input encoding is. But there might be other cases where you need to know.

The second argument could be a rule. You could do string encode snake to camel.

But then it sounds like maybe it could be string convert instead of code.

I agree.

Right. And yeah, I was going to also raise the objection that, you know, string encode sounds like it might be similar to base encode, but it's really right.

It's more string convert. Although I don't really completely like the word convert because these are very. And that suggests a very heavyweight operation. These are very superficial operations.

Transform.

No, well, that's what you've got here, but I think that's too fancy. Last transform.

I don't think convert sounds particularly heavyweight. I mean, it doesn't sound any heavier weight than encode.

Translate.

That's languages.

Yeah. So you say string convert.

Yeah, I guess. I don't know.

What other words are there.

I assume if there was a convert, there wouldn't be a decode also.

Yeah, that's right. There wouldn't be a decode. String alter. A little bit too.

A little vague. Alter it how?

Okay, we've got string transform there. Transmute.

String convention.

I think that's really obscure.

Should it be string or text string?

Although there are probably going to be some operations that are very text, like. Like, you know, title case or something like that.

Don't we have a title case mechanism right now?

Well, that's a second argument to capitalize.

I mean, these are all dealing with like words separated by spaces and it kind of feels like text.

Well, no, not if it's the snake case to camel case.

There's not words. They're just separated by different things, like underscores or something. Yeah, it's not just like strings of characters. They're words with semantics.

What is the generic name for things like Snake case.

Cases?

That sounds like grammar, though.

String case convert or text case convert.

I think case the cases. No, I mean.

I mean, I was right. See, this is why I was trying to get convention in there, right? Because you have a camel case convention. You have a.

Right, the Snake is title case a convention, maybe.

Yeah, that's. That's a Chicago Manual of Style.

Style convert String rendering Convert string.

It kind of like style convert.

Yeah, I think style's not bad. Although it does sound a bit like you're gonna make it red.

Exactly.

Yeah. By the way, just the Wikipedia page for, you know, camel case, snake case, etc. Is called naming convention programming.

Yeah.

So we could do string convention convert. Maybe we need a better list of exactly what operations we want to support before we come up with the name.

I mean, they're mostly space, right?

Yeah. I think both Snake case and Kebab case are basically versions of slugifying.

String word. I don't know. Okay, look, it's going to be one of these things like string style convert or string. I just think string transform sounds too general.

Okay, well, like ITAI said, we can work on enumerating exactly the transformer.

I guess we're on to low hanging now. So we bring up low hanging here. And how long have these things been hanging? Have they rotted on the tree yet?

Any of the rotted things? We've basically tried to prune off into the dead category at the bottom.

Okay. All right. Okay. So we just start. Where do we start? Here. We start here.

So reviewed were the ones we looked at already. So, yeah, needs review is our personal identifier. Is our first one.

Huh.

So this is what this is supposed to be.

This is a canonical representation of a person with their honorifics and with their first name, last name, and so on. It's something we've talked about for a long time. It's something that I think in the people data world, this is something that should grow out of the people data, you know, world. Do you see what I'm saying?

Seems like it should also handle. I mean, there are all sorts of other naming conventions that places have. Like, for example. Well, yeah, other than just first name, last name.

No, I know Latin America, you know, with kinds of elaborate things.

Right.

And yeah, I think this should be fed to Alan and people, because this is the place where this will start. Will presumably be, you know, encoding our people data in a way like this, if we care make sense to people.

Yeah, makes sense to me.

Okay, system status. Now this is something we've talked about repeatedly, right?

Well, isn't this. I mean, I suppose it depends on exactly what information we want, but isn't this just a machine tab of system information?

I think so, except that I think it probably runs in real time. See, I'm saying. I mean, I think that's.

Right. I mean, well, so does system information of machine or whatever is the current.

I don't think there's anything here. I think we can move on. Young tableau. I think we finally got this as a wfr, right?

Yep.

I don't really know whether there's anything beyond that that we need right now. I don't think young tableau. I think there's sort of a. Is there anything we particularly need? I mean it seems like we have some young tableau functionality.

What.

What about involutions?

Well, I think. Is Jose here?

I think yes. So there are many things that can be done with gentle plots. I mean they are fairly specialized in the theory of representations of groups. For example, one thing that I would add here is the little boot recharnsor rule to multiply two yantablos. That's a standard computation. But there are many things that can be done with them.

But you think it's basically a WFR story?

For now, yes, for the moment, yes.

Yes. But Brad's comment about involutions. Is there something in the permutation system that should deal with involutions? I needed them recently.

Yeah, I'm just looking at the encyclopedia and it says that the number of involutions is also the number of standard young tableau within cells, but.

I understand, but this is. This has a. I mean there's an evolution count here and that's fine and dandy. I'm not sure that there's. The question is, is it useful to have a way of generating permutations that comes from involutions? Because you know, we have a bunch of permutation functionality in the system. We don't have involution functionality in the system.

Yeah, and the involutions were in combinatorica last time I checked. And I also, I think parity pairings is now on the function repository.

Okay, well, fine, but okay, look, bottom line here is. And this question for Jose, do we think that there's an addition to the built in system functionality for permutations that should include things with evolutions?

We could and there are. I mean I have a full package to work with yontoplus Can I share for a moment? And you see this type of thing that it does.

Yeah, go ahead. You sure?

Yes. Okay, so this is. Yeah. So there are lots of relations with respect to partitions and then.

Looks to me like ripe to be a packlet.

Yes, yes. And they have nice type settings. There is Q tableaus.

What is this? This is part of exact.

Yes, yes. There are relations to various things and manipulations of words. Some games. Symmetric polynomials. Yes, they are very important in symmetric polynomials. And then various computations. These precisions are like powers and the little boot Richardson rule is the products. Let's see if I have examples.

Yes.

So this is like multiplications.

Well, this is quite magnificent. I mean it will be great to have this be a package and to expose some of these things in the function repository. Looks like a good project. I mean maybe that's a project. Maybe it's something Brad could get involved with at some point. And if there is a design, I mean do you think there is a built in function design that's in the making there or not?

Well, my point of view was always with respect to manipulations of tensors. This could be generalized and made a thing by itself, but it would require substantial work, I think.

All right, fine. So I think what we are thinking about now is a packlet with exposure of certain functions through the function repository. Okay, all right, onward. You know, this should be spherical, not sphere, spherical distance, spherical graphics, etc. In my opinion. I can update that, but I think this is a very fine thing and I, and I hope Brad is going to be working on it. And it's similar to geo, but it's only spheres and it's in radians. Right guys?

Yes. There is also the relation with astro functionality. So, so we would have like three families of functions that do similar things. So perhaps there is some connection or we can use functions that work in the three cases or something like that.

I think we should.

What would be the word? I mean, if, if we wanted to have. If we had a function that worked in all three cases and we didn't want to, you know, make three symbols for it, what would we call it?

I think it's a mistake. I think that they all have their own little tentacles and I think people think of them somewhat differently. I mean, I think spherical, you know, I think this is really for dealing with things on, on conceptual spheres. Like spherical triangle is something that we definitely want here. But spherical triangle on the sky or on the earth is really not that important.

So the only thing I worry about is situations where you kind of have to convert from one to the other because, oh, well, there's this function, there's this. What is fundamentally a geometry operation. And so that's why it's only in the spherical world and not in the astro world. But obviously you can do it in the astroworld. And maybe I want to do it and so I have to do some annoying conversion.

Well, we should talk about how the conversions work. I mean, so in other words, let's say you have spherical position and you say geoposition of spherical position. What happens?

I think that case is worse than the Astro case because there's some issue about oblateness. Right?

Yeah, I know, right, right.

Geo is the hardest, you know, but.

We could have, you know, if you say geoposition of spherical position, you know, it could simply take a. A geomodel that is a sphere. I mean, it's going to do something somewhat goofy because it's going to say it's going to be a geomodel of a sphere that has a, you know, radius of, you know, whatever it is, 6,000 kilometers or whatever, 8,000 kilometers.

Well, or maybe one. I mean, you could just do. What is it? Geomodel era one I think does that, doesn't it? It makes a, you know, a spherical model of diameter of 1 meter or radius of 1 meter or something.

That seems really horrifying.

It would get all the same results as, you know, spherical geometry. Functions like spherical distance and so on would presumably return, you know, the. Well, actually, I guess I think spherical distance would return the same thing as geodistance. But that might be pretty bizarre.

I think it will be crazy. I think it's better to just admit we live on the Earth and convert, if you do geoposition of spherical position to just convert to the corresponding angle position on the Earth. I mean, I think Astro is a little different because there, there's genuine spheres involved. But again, you know, on a sphere, spherical, whatever, we're not worrying about relativistic corrections. We're not doing any of that stuff. It's just a conceptual mathematical sphere which itself will be very useful. And I have a feeling that other forms of geometry, like hyperbolic geometry, we might eventually want to have, you know, hyperbolic distance and things like that. Just like. Go, go ahead.

So, so when you are talking about this ideal sphere, so it wouldn't have a radius.

So it's not radius 1, is radius 1. Spherical distance would by default be radius 1, I would assume.

But it would take also a radius, just in case you want Another sphere.

Absolutely. Yeah. Okay, now, and I think you're living on a single sphere. So you know, anything that is like you're going out into the region world, if you want to know the distance between points on two different spheres and all kinds of things like that.

Well, we would have to distinguish, and we do this in Astro already. Astro distance from Astro angular separation. Right. Because you want to distinguish the distance as an angle from the physical distance.

Right. Well, so it's probably a spherical angle difference or something. But I also think we really need spherical triangles which are, you know, definitely a thing. Much more so than they are a thing on GEO and all those kinds of places.

Right. In GEODE you would just use a generic geopolygon with three vertices.

Right. But you know, the spherical trigonometry that we really want to support properly on a sphere.

Yep.

All right, let's keep going. All strings.

Oh, sorry, one more question. If we're going to do spherical triangles, would we do hyperbolic triangles too?

I'd like to, I'd like to do hyperbolic geometry as well.

Yes, well, I mean, I suppose we could do the distance. Right. But you can't embed hyperbolic geometry in three dimension, three Euclidean dimensions. So.

Right, but then we, but we have a purely symbolic hyperbolic distance and hyperbolic, you know, you have a whole set.

Of hyperbolic projections and so on.

No, the hyperbolic geometry is actually useful in classical algebraic geometry too, through the Riemann uniformization theorem. So there would be lots of interesting examples.

Well, and also the fact is that we can obviously have projections, we can have models, you know, the puncture disk and so on. You know, it's clearly useful because we can have things where there are things that have coordinates in hyperbolic space and then we can render them in a kind of hyperbolic, the analog of geolist plot, hyperbolic list plot with projections. It really does seem like a useful thing to be thinking about. It's something, you know, it's a well understood 150 year old kind of mathematical concept of hyperbolic space which I think we should support, particularly with the rendering through projections and so on.

Yeah, Felix Klein and all of that.

Indeed. So I mean, I think that's the, you know that Brad, that's the future for this project of yours with spherical, you know, geometry, trigonometry, hyperbolic, et cetera. Let's move on here. Okay. This particular thing finds strings in a byte array. I assume that that's a WFR function already, is it? If it isn't, it should be.

I Don't think that makes any sense.

Well, it's the same thing that strings does in the UNIX operating system. You take a binary and you look for things which are coherent sequences of ascii, like characters. Yes. In the world of modern Unicode, it makes less and less sense.

And also if you, you know, if you've ever run strings, you know, it returns a lot of garbage in addition to meaningful stuff.

Indeed, this is not a profoundly important function. And I know people have worked on this at the summer school and I'm sure we can find one of those implementations and turn it into a wfr. And I think that's what we should do.

Okay.

Yeah.

Okay, let's continue here. Are these in WFR now? Yes. Do we think we want to have these as system functions? It seemed mildly useful, but I haven't been profoundly.

Well, actually, do we have. This is a naive question. Do we have like built in functions for like partial sums and partial products?

What do you mean by so?

Well, I mean, so returns the list of, you know, if you have a series, you know, returns each sort of as it's summing them up, you know.

Each element in the series, like the opposite of differences.

Accumulate.

I'm just going to say accumulate, but I don't think that's what you want. Something more symbolic or I mean, something.

With the syntax of sum. Maybe this isn't relevant to this, but I mean like we have sum. But the question is there a version of sum that's like some list where it returns the list of the partial.

Sums, which is like what accumulate is to an explicit list. Some list would be to a symbolically specified set of list elements. Right.

Presumably you'd give it a length, how many you want or something like that, Christopher?

I'm guessing, yeah, I mean, similar syntax.

In other words, you're not looking for a symbolic representation.

Well, I hope that would be basically like a symbolic fold or symbolic fold list where instead of the fold elements being generated by, you know, explicitly, you're imagining there's a generator of the successive fold elements.

I guess. I mean, I was thinking this is related to the function you have on screen. I don't think it's actually that related. I guess in some case it's just a cumulative table. In the product case, I guess it's fold of times of table or something. So I'm not sure it makes that much sense.

Okay. Do we care about built in geometric and arithmetic sequences?

So we have already power range.

Power range, yeah.

It's almost the same thing.

Yes. I mean I think the people who should be asked about these are Roger and the rsolve folk because I can imagine them being excited about having symbolic geometric sequences where you can have geometric sequence with symbolic parameters here and where you can including one where you don't have the number of elements here.

Yeah, it sounds like that would be something that could work with the lazy stuff too.

It could, but it's also relevant just for the rsolve thing. So can somebody feed that please to. I guess it's Roger and Adam.

Yeah, we'll check in.

Okay, but otherwise. Otherwise we're, you know, we've got WFRs for this and we're good. Should be done post version 11. Well, I have to say this thing turned out to be much messier than we expected and I think it's happily in WFR and shouldn't go anywhere else.

Okay.

The heck is this? And it isn't subsets. Isn't this just substance?

No, it's keeping order.

Well, doesn't strike me as profoundly important. I don't see a use case.

I have a similar functions heavily used in patterns, what they called splits. And it also included an empty list like in one of them.

No, because they're.

Oh, oh.

Anytime you include an empty list, you can include two empty lists.

Yeah, I was going to say that that's not well defined.

No, it's like you start with the. You also have a second argument to these functions. How many splits you want. So it's like list partitions 2. So can you partition on list? No possible ordered sub list including an empty one.

Right, but that's relevant for your pattern utilities. And it could be that the better way to specify this is just by giving some pattern and having it be able to generate, you know, like triple blank comma, triple blank comma, double blank or something. Which is a richer language that lets you specify things like oh, I want a minimum size partition of this thing, et cetera, et cetera, et cetera.

How is it related to groupings?

I'm not sure it's a good question.

I don't think I'd be able to.

Do this with groupings.

Well, in any case, I don't think there's any place to go with this here. I think this is happily WFR for now. Natural language string. I see. I mean this is kind of like the synthesized. Like what WolframAlpha Notebook Edition does of synthesizing a natural language input for something. I believe that there are functions like this that Michael and those guys have found useful. Can we ask them about this, please. They may already have some function like this. Makes sense. Avery, take that. Okay. This thing is important and we've never gotten around to it. This is basically doing natural language lookups on data sets. This project should be in the global project list. And it just. It's something we need to get to at some point. I don't think there's a small lightweight function to be built around it. Is this like the data container stuff? Not quite. This is. This is. No, it's. It's more like semantic import related. It's part of the gaggle with semantic import.

Okay.

And I don't know where that's getting worked on. I mean, Jeremy, I think was working on some of that stuff. But this is. This is not dead. And this should. We should make sure that this gets, you know, attached to the appropriate thing in the global project list. Yep, I can do that. Index by. I haven't a clue what it is. Anybody know? No.

That's pretty much what the question marks were. We didn't have any extra notes on that one. So most of the talk we're talking about these days with indexing has to do with supplied.

So. Yeah, let's just kill that one. I don't know what it is. Sequence select. What is this? I see.

Yeah, it's kind of.

But is it in WFR or is it not?

Our proposal was to put it in wfr. A lot of these suggestions predate WFR existing.

Obviously not all of them have Right.

Index there.

So. Sorry. Does this consider every possible subsequence?

Presumably considers contiguous sequences?

Yeah, the idea was. Sure.

I mean, this function. Don't we already have sequence cases?

Yes.

Is it the same type of meaning? Is the analogy. Does the analogy hold, in other words?

Yes. Although I guess that you want to use, you know, double hash like. Like instead of hash, if you know what I mean, in sequence select to be very consistent.

I think I agree.

Actually. Sorry, that wouldn't be consistent with sequence cases. I misremembered because sequence cases has the list on the left hand side of the rule.

But sequence select seems like it goes naturally with sequence cases.

Yeah. The main difference though is just that sequence cases can be a lot smarter than sequence select camp because it, you know, it can use pattern matching. You know, it can. It can reason about the pattern so it doesn't have to actually consider all N squared cases or whatever it is.

But sequence cases is not contiguous.

Yes, it is. It is.

Yeah.

We have. Then subset cases. Is the other one you are thinking about?

Oh, yeah. Yeah, right, right, right, right.

Which could have been maybe an orderless version of sequence cases or is effectively.

It is effectively. Okay. I don't know why sequence select doesn't exist.

It's perhaps a historical.

Sorry, go ahead.

I was going to say that it's probably a historical thing. We created sequence cases, positions and count together and then split and we didn't continue with the family.

Although I have to say I haven't missed it.

Right.

Well.

And if we added it, would we also have to add. If we also have subset cases, would we also have subset select.

Let's put this in WFR and not worry about it for right now.

Okay.

Who.

Who does that?

What says bracket wfr, does that mean it's already in wfr?

No, it doesn't.

That means we're proposing to put it in WFR rather than as a system function.

So I guess, Avery, you make a ticket. And.

So, I mean, this is. Does not look to me like it's more than a 15 minute job.

I. Sure, it's more than a 15 minute job.

Then it may help.

In fact, I think when you say something like it's not more than a 15 minute job, that, that, that makes it exponentially worse.

Okay, fine. I'm.

I'm convinced of that.

I don't think this is high priority. I think it's one of these things that we could have as a, you know, as a things to put in WFR when. When there's an opportunity to do it. Okay. Deep pattern is sort of interesting. And that has to do with head matching.

I mean, not as it's being proposed here.

No. Okay, it doesn't. I see. Not.

Well, maybe there could be a second argument to the deep pattern that matches the sequence of heads going down or something like that.

Yeah. I think there's a family of things that we have never done, which is just like we have double blank representing an arbitrary sequence of things in a sort of space like direction. We do not have things in a tree like direction. We don't have a way of specifying a. You know, if I have a thing where I'm saying, you know, F of F of F of F of F of X. Right. We have no pattern that will match that with an arbitrary sequence of Fs.

Yes. And F of bracket F of bracket F. I think we don't have that either.

Or some other. You mean this, that type of thing?

Yes.

I mean with other symbols other than Fs.

What do you mean? But we don't have this particular thing. We don't have a way of saying dot, dot. You know, if this was list fff, then we can just say F dot, dot, and that will match that. Right. But we don't have a similar way. We don't have an analog of dot, dot, or blank blank that represents tree like, you know, that represents these tree like cases.

So it probably should be, instead of repeated, something called something like nested.

Indeed.

With a similar argument, like how many times you can nest this thing.

Yes, I think it would be interesting to explore. I don't know how difficult such a thing would be to implement, and I do wonder whether it is relevant to the generalization of UP values, which is something we've been meaning to do for 35 years. In other words, if we had such a thing, could it generalize UP values? Because right now UP values are one level. You know, you can say F of G of X and you can associate that value with G, but if it's F of G of H of X, you can only go one level there.

Mm.

I think this should be explored nested, you know, these two cases. I think this is worth exploring, and I think that's deeply related to this. You know, it's a good ILD LCC thing to explore. Okay.

Yeah, we'll add it to the roadmap.

Okay. This wasn't proposed by Dave, I assume? No.

I do like this idea of naming functions for longtime employees. We have gray, we have light blue, which is almost for me.

So it is. I'd never even noticed that. Wow. In all these years. The. And.

And how is this different from quiet?

Because it's a block. Because it's temporary.

So it's quiet.

So it is. It doesn't seem like it's different, does it? Having a message off is different from one that's quieted. Right. I mean, it's probably rare that code cares, but it could be.

Right.

Let's throw this into the error handling discussion. It's probably not relevant, but just in case there's something here, let's put it in the error handling agenda. Okay. Well, we've got this. This is threaded. Yep. Yep.

Right.

Yeah.

Initialization option for module. I think that's what we've got now with. With cleanup and so on, isn't it?

That's what this seems to be hinting at. I'm not absolutely sure, but I think that's what this is getting at.

Okay, let's assume it max for rules.

That just seems bizarre.

It's bizarre, and I think it's handled by association. Well, I Don't know what it is, but it seems bizarre to me. Pattern equal. Well, this is something related to Nick's pattern unification work. And I mean there's a whole gaggle of pattern utility functions which we definitely are interested in. And I think that the pattern utility functions, if they're not in the global project list, they should be. And there's a gaggle of them and Nick I think already has drafts of a bunch of them. That's where this should be. Infix match queue. I'm not. It's not floating my boat post set. Isn't that. I have not been using this thing. But isn't. Isn't the. Isn't slash equals something like this.

No.

Right.

Because it.

Right.

That applies something to X and returns the new value.

Right.

That's no different from X equals F of X. F equal X. I guess X equal F is equal to X equals F of X. This is saying.

Are you saying if I say XX equals list ABC and then I say X, slash, slash equals reverse.

Missing a slash.

But what, where, where am I missing a slash before? No, slash equals. Isn't that right?

No, it's slash, slash equals. You just divided by.

What the heck I did here.

Right? You divided all the elements by reverse.

Okay. And now I've got this. Has anybody been using this thing?

A little.

I like it.

Yeah. Okay, good. Well, I'm glad it's got some fans.

Okay, so this is right, this is saying you do X equals. You have x equals 1 and then you have x equals 2 x and it returns 1 instead of 2, which I suppose is theoretically useful. And. But I. I have a hard time getting.

My boat is not being floated here. Let's move on. I don't know. Anybody excited about this? Seems hard to find.

Yes, I think length is too important to complicate.

Agreed.

Don't we have this now have this.

Right, That's.

Yeah.

Remaining.

Remaining time remaining.

Yeah, yeah. So it's a.

It's a wait time remaining polls. The time constraint.

Yeah.

Yeah. So if I say time constrained of.

Time remaining comma 5, you should get 5 or very close to 5.

Out of curiosity, does time remaining work inside of functions with the time constraint option?

Good question.

Well, it should, I would guess. Yes, it should. It should detect the nearest time constraint.

I would guess that those are implemented using time. Constrained.

Well, but they're ones like. I mean this is a pretty impossible case. I mean there's stuff like full Simplify, for example, which has a time constraint which I think only which constrains you how long it spends in each branch and weird stuff like that.

Right. So time remaining would tell you how much it is doing. If you could somehow get that into full simplify. It would tell you how much time remains in the current transformation that's being attempted.

Well, you can. It could be a side effect of some kind of thing. Okay, this looks good. And. But we can by the way, Avery, in. In. In annotating this, please note when these things were implemented. Right. Just so we know that for if we ever come back to this notebook. Okay. I can go through and update that.

Or at least where what they're implemented as.

Yes. Or you know, we decided it was a bad idea or whatever else. Okay. String difference. I think that seems like a sequence alignment thing.

Yeah.

I was thinking isn't that something we have or with various methods, distance metrics.

I think we do. I think we should ignore that. Okay.

Yeah.

Is this in WFR or is it not?

It's not currently in wfr. It is. You know, you can basically select things from word list based on a part of speech. Our proposal was just to have a WFR function for vowels, consonants, syllables, etc.

But now there's two things in the. There's string vowels, which presumably gets the vowels from, you know, the list. But is the idea of the first thing to be to give you the list of vowels that are used in English?

Yeah. And I don't understand why English vowels, which I got here with capital letters. That seems just completely wrong to me. I have to say. I would argue that this could be an actual just like we have Alphabet. You know, it just seems like a useful thing to have the list of vowels, the list of consonants. They're really pretty. I mean. Or possibly that it is part of Alphabet.

Yeah, I mean that's what I was going to suggest. Just like random word, right. You can say part of speech, then Alphabet. You should be able to say, Oh look, there's a two argument form.

Now what does it do that gives you properties associated with it, but it doesn't say what they are. Which is a bit upsetting here.

Well, but as you also saw with the when you asked.

But wait a minute. It's simply not freaking documented here. Okay. This needs to be fixed.

Okay, I'll take a look at that. I'm guessing that's an oversight from Constantine, but yeah, I'll go through and figure.

Out that probably should be right. We probably need just a better scope section and not hide this. And generalizations and extensions.

Well, and we also need it in the documentation at the top here. Just so I.

Well, I agree with that, but.

Right, but I mean, to me, Alphabet English, common vowels is not crazy. I mean, given that this says index characters. Right. And I'm very confused here that that is capital letters there. I don't understand that at all.

Yes. And these properties of Alphabet comes from the entity values. And I think we should. We could add the vowels and consonants there as properties in the same way you have these index characters.

No, I agree, but these shouldn't be capital letters here. There's no reason why index characters should be capital letters, I think. Unless there's some special thing about indexes.

Yeah, I can check that because that came from the. From a source that. From the ICU library that they use this in uppercase. All these index.

Let's examine all of this. Okay.

Could we also support automatic as the first argument? That's the same as the zero argument.

Form, I would assume. Yes. I don't know what happens if you do this and if I set the language to, I don't know, French or something, do I get a different Alphabet for Alphabet? Open, close.

What's. Options of Alphabet. So what you'll get.

Yeah, long ago we said that we will use English as the ocean.

I think we should. I think we should use English as a default. All right, so Francisco and others, please check into this. I don't think it's totally obvious that we shouldn't have a vowels open, close. I think it's such a common thing. It seems like it might be useful and there are enough kind of like neat little algorithms that make use of the vowels, et cetera, that it seems worthwhile to me potentially.

Right, but that could be a handy function calling Alphabet behind because.

Yes, that's fine. All right, so, Francisco, can you look at this and look at the. I mean, you know, there's clearly a goof up with this here.

Right?

Yeah, we should explain that the properties are the properties from the entity type Alphabet.

Yeah.

Well, we should list them here is what we should do. We should look somewhere else and probably.

Link in the C also the. The alpha identity type.

Yes, for sure.

It's not there.

Yeah, it's goofed up. So we'll fix. Oh, boy. These are things for string matching, right?

Yeah, they would basically correspond to regular expressions.

Well, I certainly do not support having Japanese character. I mean, yeah, you could. I could possibly, you know, accept ASCII character and non ascii or printing character versus non printing character, but.

Well, you could have katakana. Hiragana, as proper character sets, which there are no.

I understand, but where's my cuneiform character or something like that?

Yeah, no, that's.

I mean, it rapidly devolves.

Right. Look, I think here that what we should do is we should have, instead of all of these different things, we should have a generic, you know, character match. I don't know what we should call it.

Well, it's character, character class, character pattern, Just a standard term.

Well, fine, so let's just do that. Character class, ascii, character class, Japanese. That seems highly sensible to me.

And it doesn't evaluate.

Right, doesn't evaluate.

Well, one other thing, that's one other quick question is. So I was looking at Alphabet when we were talking about this. So in Alphabet, you know. Right. So one thing is you might want this to relate to Alphabet where it's similar to alternatives at. At Alphabet. But there are differences because there are some languages that make hair splitting distinctions about whether their umlauted letters are actually letters or whether they're just letters with diacritical marks. So like, for example, Alphabet of German doesn't show any of the umlauts, but Swedish does. And I think that's a real distinction the languages make. I don't think it's a bug. But then we might want a version of something like Alphabet.

No, all that was created. Yes, yes, all the alphabets were created.

Right. But I'm saying just that maybe this is something that may already be in this undocumented second argument of Alphabet. But presumably there should be a way of getting the actual list of all the characters that this pattern matches, if that makes sense. Like give me all of the characters, including the umlauts, even if they're not letters. Just give me all the characters that you would expect to see in German text.

Right. So there's probably a character class or something, character class members or some such other thing. That's the second argument to Alphabet. But there's two different things here. One is introducing character class in the string patterns world, which does seem worthwhile to me and definitely is what we do. Instead of the millions of these, right. We have a few special ones that, that are, you know, have their own thing, but otherwise it's just the generic character class and otherwise support describing whatever is a character. Whatever is a valid character class should be capable of being listed by some Alphabet thing. I mean, arguably you should just say Alphabet of character, class of blah, blah, and that would be one way to do it.

Right. We have this full characters property also for Alphabet, which is Kind of similar.

We don't have any frigging properties for Alphabet because we didn't document any of them.

I know, I know, but there is these full characters.

Well, I'm sorry, but nobody's ever going to have known that. I mean, how did that happen? We just didn't document it. Come on. Sigh.

Are the character classes just going to be Unicode blocks?

Well, they're not contiguous ones.

They're going to be regular expressions under the hood.

And I don't know what this is, and I've never seen this before, really.

All right, well, I guess, Francisco, you're a native Spanish speaker. I mean, do those dietrical combinations actually appear in Spanish?

What the heck is this for English? No.

Yeah. The problem is that, for example, when I was looking at this property, they include everything that will be valid in a document. For example. And because the European Union considers all the characters valid in documents, they include, for example, all the special characters in English. In German.

Excuse me. I mean, this is like Ethelred, you know, I'm sure Ethelred is now. You know, compatibility with 1000 years ago can be written like this. Right? Or more than 1,000 years ago. I mean, that's not English, is it?

No, that's right. So that's the list of all the characters that might appear in documents that are valid.

And not necessarily.

According to Ethelfred.

Ethelfred, I believe he was.

But now it was just derived empirically by just looking at a bunch of text and getting the letters out. Or where this comes from, I'm not sure.

That comes also from the CLDR project.

Okay. And maybe now that Brexit has happened, the set of four characters in English might.

English is still official in the ua, so.

Yeah, okay, fair enough. I don't know. What? Maybe the Faroe Islands? No, I don't know. They probably have Danish. I don't know. Okay, right.

But probably. We will need a created list of actual characters with the valid combinations of native words.

Fine. So there's work to be done here. That's. We'll.

Yes, I agree.

Okay, let's move on a bit. Set file attributes. I thought we had that. That's the CHMOD type functionality. I thought we built that. Finally.

I haven't found that functionality implemented. I mean, Constantine added ways to read it. So if you do like information of file of something, you'll get the file attributes listed out.

But seems useful. I mean, it's not the highest priority, but it seems useful. I think we should preserve that as a thing we want. Could that Also extend to set permissions having file this as a first argument. Yes.

Right. I mean, yeah, that was the problem that we ran into. Right. That the permissions as you know, defined by the cloud is different from permissions on the file systems become ambiguous.

I personally think what we should do is just say set permissions and this P string thing should work for files and if we can convert some of the cloud permissions symbolic structure to the desktop, so be it. But what we can't convert, we should just error out on. So what I'm saying, I mean, something like this read, owner, read, write, execute, that we can do, you know.

Yeah, I mean we're gonna have to have error handling no matter what.

Yeah. So I think we should try and put it in. I agree. I'm. I'm changing my mind. I agree. We should try and put into set permissions and just have it work as best it can given that there is a P string thing here anyway. Surely we show an example of that. Surely we show an example. Oh gosh.

I think.

Oh, for goodness sake. Come on, guys. Okay, another bug.

Okay, nobody here is responsible for cloud documentation.

I don't think this is cloud, but I mean this is.

Yes, yes, this is, this is exclusively for cloud objects.

Yeah, those two examples and basic examples covered, I think for public and private. Oh, I see that. That's what they mean by strings, not, you know, you know.

Rwx.

Yeah, right. Okay. This requires investigation and perhaps we can, you know, we have to decide if we're supporting RWX or whatever it is for the cloud and perhaps we need a separate thing. Set file permissions. I'm not sure requires investigation, but this is alive. All right, let's try and do just a couple more.

I mean, I mean this was on the LCC agenda, so I don't know why, why, why that wasn't noted here, but.

Okay, what was a goof, a minor goof. Okay. And activate. Complete. I don't think this, this is another Angels, you know, impenetrable irresistible forces, immovable objects, etc type situations. And I don't think we should. I don't think there's any more. I don't think there's anything useful we can get from doing that. Further inflected Forms is a long time project that we really want to see done. Francisco, maybe you could speak to that. That's a linguistic curation project, right?

Yes, I think that will be related to all the things we are doing about language, data, et cetera.

Okay, so I'm going to assume you Will take this and we'll see that in. And it should be in the global project list. This is currently a lower priority than 2017.

Because.

That's.

Right, because also there was this project of world data that they were factoring all these world entity type. That's under Alan's actually. But yes, I can grow it with him.

Okay. Phonemes. Now, I thought we were making this active because now it was being dovetailed with the audio stuff.

I haven't heard that part of the discussion. I mean, we talked some years ago about phonemes and phones as being linguistic data.

This. This is supposedly active. Alan Johan should be consulted on this.

We also start designing an entity type for phonemes, but we never finished that. So maybe we should continue on that project.

That is what should be done. Yeah. Cyclic arrays. We have discussed this multiple times and I think it's something that deserves further discussion and it's possibly related to the future of arrays project.

What, what is this exactly?

This is more like a structure array type.

Okay.

And. And I think John will get at some point. It's just that he's working on more important linear algebra related structure types.

Is it in fact of that type? I mean, is it. Cyclic array would be a wrapper, you're saying.

Yes. So we store one block and then we say this is a block of three by three. But the array is a million by a million and it knows how to extract any element, et cetera.

So a little bit related to a Toklit matrix or something like that.

It's the same kind of idea storing a much smaller piece of information to reconstruct.

Yeah. And we've got. I mean even yesterday we were reviewing Vandamon matrices and things like this. So this seems like a concept that is much simpler than many of these linear algebra type concepts. So it seems like a good thing. So you say this is on the path?

Yes, I think it is.

Let's make sure that we know that. Okay. CyclicArray is probably the name that we want for it. How are we doing here? Let's see. Export string. Did we ever get this?

I haven't seen a fully functional version of it. I know there were discussions of this.

With.

At various points in the past, but I haven't seen a user.

Maybe we in fact have this. But from having external evaluate. Maybe we built this and maybe we should just expose it.

I think we at least have import string for these. I think I've used it.

Okay, well so somebody investigate, please. Ask the import export team. Avery, I think that's for you.

Yep.

Got it. This whole thing, this is something we've asked for for millions of years. It still seems useful to me. Comments?

Yeah, I would find it useful, too. And being able to read numbers in E's and D notations.

Yeah, I think we want this. All right. We should wrap here. To be continued another time. This has been a useful. I mean, it's actually fairly encouraging. I mean, a lot of the stuff we've discussed here is either been done or, you know, this is really good.

Okay. Yeah, we'll follow up on those items.

And I mean, I don't know how much, when we get down to something like this. Yeah.

None of these sections are enormous, even like Regens or Charles or a handful of things. So when we get there, we'll have those individual people here as well.

The second largest group is the UAFE one. I see. This is all sensible stuff. This is really good for us to go through this. All right, thanks a lot, everybody, and see you later.