Extracto de la transcripción automática del vídeo realizada por YouTube.
- OK, this is a talk about soft typing. Now, soft typing is something that Mark spoke about at RubyConf last year. And he spoke about it as one of the possibilities for Ruby three. So, what is soft typing? Well, in essence, it's a way of combining the benefits of static typing with the flexibility of dynamic typing.
So, to give you an example what this might mean, here's a little piece of Ruby code, a very simple thing. It's just a method that takes an argument, anything, and then calls times two in it. Now, because this is Ruby, we don't need to tell it anything about the types.
But this also means we don't know much about the types. But there are some things that we can work out. So, for example, just by looking at the code, we can say that this thing, whatever it is, has to respond to the times two. And can we go a little bit further.
We can say if we call this method, parsing in some kind of object, this object also has to respond to times two. And we know that if it doesn't respond to times two, then our code is gonna explode with some kind of runtime error. So, the important thing to get across here is, when I say soft typing, static means that we can work stuff out without having to run the code.
And this is a huge idea for Ruby. Previously in Ruby, there's no way of thinking about things like correctness without running the code. But this is a big philosophical shift in the way that we think about things like correctness in Ruby. So given that this is a candidate for Ruby three, and given that it's such a big deal, you'd think a lot of people would be talking about soft typing.
But nobody really seems to be. There was one talk by Tom Stuart at RubyConf Australia called Consider Static Typing. And this serves as a kind of primer on types, and what they're useful for. At the end, he says a little bit about soft typing in Ruby, but not that much.
But apart from that, I've heard nothing. And even worse than that, going to conferences and speaking to people, nobody seems to be thinking about it and nobody seems to be talking about it. So I'd like to address that today. And I thought it would be a good idea to give a talk about what soft typing is, and how it works.
And that really means talking about type reconstruction for a late binding, structurally typed language, such as Ruby, and then working out how we deal with the inevitable failures. I thought it would be a good idea to talk about this. But then I wrote the talk, and it turns out, it's actually really boring.
There's an awful lot of really heavy academic theory in there, and I think a lot of you would just get up and leave. And worse than that, it's boring, and it's also really difficult. I mean, I'm not sure I actually could talk to you about how soft typing works.
It's too hard for me. And if that wasn't bad enough, it's also really impractical. I mean, even if I could teach it to you, by the end of it, all you'd know is some mathematics about type systems in functional languages, like ML, that have never left academia.
And you couldn't really take that and apply it to your everyday Ruby work. Boring, difficult, and impractical. This is gonna be like the best talk you've ever seen. Now, I think this is the way a lot of people think about type theory in general. And certainly, if you've read the soft typing paper, these are some words that are very good for describing it.
But this isn't the way that I feel about type theory. And it's not the way that I feel about type theory in Ruby. I think it's actually a really exciting areas. I think it's something that we can engage with as Rubyists. And I think it's something that cam improve our Ruby code.
So what I want do today is try and make is more accessible. I can't tell you everything you need to know about soft typing, but I can maybe tell you where to start. Or give you an idea of how to explore this topic. And I'm gonna do this today by writing a static type analyzer.
So, what is a static type analyzer, and how do you write it? Well, there's a talk by a guy called Matt Might, and he's a professor at the University of Utah. And the talk is What is static analysis? And quite early on in this talk, he gives a sort of general formula for how we'd write a static analysis tool, like a static type analyzer.
And he says what we do is, we take an interpreter, and we make it more abstract. So, to give you an idea of what this means, imagine you've written a program. And you feed it into the interpreter, and what the interpreter is designed to do is run the code and produce a resultant value.
OK, so you might run your program, and it produces the value 42. Now, to make this more abstract, we still return the same kind of thing. Just with less detail. So instead of saying, "The answer is 42," we'd say, "The answer is just a number. " It's something more abstract about the value.
And it doesn't have to be as clearly about types as a number. You can say it's a number greater than 10. Or maybe we just say it's a value. And that can be a useful thing to know on some occasions. So I'm gonna write a static type analyzer by writing an interpreter, but I'm not gonna do this for Ruby.
Ruby is a very complicated language, and we get bogged down in the details very quickly. So, instead of that, what I'm gonna do is create a very simple language, a very simple programming language. Then I'm going to write an interpreter for this in Ruby. Then I'm gonna write a static type analyzer by making my interpreter more abstract.
OK, so this is the language I wanna start with. And it is very, very simple, OK. I can take some numbers, and I can assign it to a variable. And then later on, I can recover that variable. So, how do we write an interpreter for this? I think it's kind of helpful to think about how we interpret this as human beings.
And the first thing I want to observe is that we don't just see this as some kind of big amorphous blob of code, we break it down in our minds into some structure. And we say, "OK, these different lines are different expressions in our language. " And they're not the same kinds of expressions.
We can say that the top line is probably an assignment, and the second line is just using a variable. Let me look at this assignment line. Well, the reason we think it's an assignment is probably 'cause it's got the equals in the middle of it. And once we recognize this being an assignment, we can say the thing on the left hand side is some kind of identifier, and it's telling us where to store the value.
And the thing on the right hand side is the value we're gonna store. And it's not just any value. We can look at this and say, "This is clearly a number. " So, that's maybe how we see it, but for a computer, it looks entirely different, it just look like an undifferentiated sequence of characters.
Like an A, and then a space, and an equals, and so on. So the first challenge is to take this and impose the structure back on it. And the way we do this is by running a parser. So we're gonna take this string of characters, feed it into a parser, and it's going to spit out some kind of structured data.
So, how do we write a parser? Well, this is Ruby, so of course, there's a gem for it. In fact, there are many gems for it. The one I'm gonna use today is called Parslet. I find it quite easy to work with. And I'm almost ready to get started. But before we get start, I need to work out a name for this.
Just for practical reasons, I need to name some classes. So I'm gonna give a name to my language. And what do we call this? Well, maybe we can pick a name based on the characteristics of our language. So, like, it's simple, OK. But it's not just simple, it's like, really, really, obscenely simple.
And this makes it kind of accessible at the start. But after awhile, you realize this is actually quite limiting. And not only is it limiting, the more we work with it, the more frustrating it becomes. Alright, so we want to name this after something that's, like, obscenely simple, and really very limited, and just becomes more and more frustrating.
Oh, sorry, that shouldn't be in there. So, for no particular reason, I'm going to call this language Trump. OK. So, let's start running our parser. (laughs) To do this, I'm just gonna write a class. And I'm gonna call it TrumpParser. And it's gonna inherit from Parslet parser.
And the way that Parslet parser works, whoops, is you give it a set of rules that describe how to match the input string, OK. And we're gonna start by telling it where to begin. You give it something called a root. And the root we identified, when we first selected the program was, it was a series of expressions.
So we just say, to start parsing this program, look for expressions. OK, now we need to tell it what we mean by expressions. So we'll write a rule for that. We'll have a rule that says expressions or a single expression, but we're gonna repeat this. So, there could be more than one of these things.
OK, and this is how we tell Parslet that this thing repeats at least one time. So now we need to tell it what we mean by expression. So again, we just write another rule. We say an expression. And now there are different types of expression in our language, but we're gonna start by just assuming it's always gonna be a number.
This helps us get started, then we can add in the structure later. So I'm gonna say an expression is just a number. And finally, we'll tell it what we mean by number. OK, so number. And in this case, we're gonna say a number is one or more digits. So, we can tell it to match a digit by saying match, and then passing backslash, D.
Which will match zero to nine. And then we say there may be more than one of these. So we'll say repeat, and there's gonna be at least one. OK, so now what we can do is, we can create, like, a sample program, a source string for our program. We'll just set it to be a number for now.
And then we can create an instance of our parser class. We'll just call new on that. Then we can tell it to parse the input string. OK, and if we look at what this, oops. . . If we look at what this produces, we can see it gives the string back to us, followed by this at zero.
[ ... ]
Nota: se han omitido las otras 5.102 palabras de la transcripción completa para cumplir con las normas de «uso razonable» de YouTube.