From calamitas at advalvas.be Tue Oct 4 15:28:19 2005 From: calamitas at advalvas.be (Peter Vanbroekhoven) Date: Tue, 4 Oct 2005 21:28:19 +0200 (CEST) Subject: [suby-talk] "Is" and ideas for moving foward In-Reply-To: <4b6f054f050925145185205cf@mail.gmail.com> References: <4b6f054f050924124660760250@mail.gmail.com> <4b6f054f05092417191bff2d60@mail.gmail.com> <4b6f054f05092508333e4366bf@mail.gmail.com> <4b6f054f050925145185205cf@mail.gmail.com> Message-ID: On Sun, 25 Sep 2005, TRANS wrote: > With #is and #as and units.rb I start to feel as if Nano/Mega is > becoming a ... dare I say it? ... a Framework. It doesn't matter whether you dare say it, you already did :-) > Right, I recall now why it is impossible: b/c of the way Ruby parses > and b/c Ruby is dynamic. So Ruby can't be sure a method even exists > until it is defined, yet it must be able to parse the code that calls > that method even it hasn't been defined yet. Just as you mentioned > before, Python has an advantage in this regard. Er... Well, I don't know Puthon, but unless it has type declarations, it doesn't quite help. > Oh no, I don't intend that we get rid of singleton class, only that it > be reduced to one level only --no scary door. The upshot is simply > that modules always "extend self". It would be almost exactly as if > one did this themselves whenever they used a module: > > module Foo > extend self > ... > end And for classes? > Well it's definately complicate. I've been using Ruby for years now > and I still get confused. I may not be the smartest guy around, but it > certainly needs something to either simplify or at least make the > various levels explict. include vs extend isn;t the problem pers e. > After all what does extend do? it includes a module at the singleton > level. > > class X > class << self > include M > end > end > > The problem simply is the difference between including a module and > inheriting a class --i.e. the class method aren't included. But I can > see a use for that, so I just want to fix the problem while still > allowing a way to do that. I know, it's the difference between inheriting a class and including a module that bothers me too. >> Hmmm, maybe... Aren't classes and modules about inheritance? Question is >> them: do the non-inheritable methods actually belong in a class or module >> then? > > Well, they're like local vars. They are utility functions. But maybe > you are right, maybe non-inheritable methods have no business being > there. You see, but utility functions is a weird word as local methods would be visible from the outside. But perhaps I'm not so right. We're talking here about specific instances of Class or Module. I mean, the fact that class methods are inherited in subclasses is something extra. Normally, the singleton class of an object is a direct subclass of the object's class. Except when that object is a class, because a class' singleton class is a direct subclass of the singleton class of its superclass. That's in my opinion exceptional behavior. But let's say that for class methods you should have a choice of inheritability. Then what's the defaults: inheritability of non-inheritability? I'm just wondering what is needed most often. I've never really encountered problems with class methods being inheritable. Either I want them to inherit, so there is no problem. Or I don't want them to inherit, but even if they do, I'm not calling these methods on the subclasses, only on my own class, so there is no problem. I must say though that the latter case is rather the rule, the former case the exception. As for how it would look underneath the hood, that's the picture you've once drawn for me (although that was about private methods). So it would look like this: c1 --c--> LocalC1 --s--> GlobalC1 --s--> Class ^ | s | c2 --c--> LocalC2 --s--> GlobalC1 At this point one must wonder though. This can actually be done in Ruby now. When defining a class C1, define a GlobalC1 (or just C1) that is intended to be subclasses, and a LocalC1 that is not intended to be subclassed. I don't know if it would work for classes though; I think not. But this raises the question of how explicit this is going to be. Do we allow people to get hold of both LocalC1 and GlobalC1? If so, which is returned when asked for C1 tout court? I think for meta-programming, it would be nice if it were possible to return "the object containing the non-inheritable methods". Could be a module, or class (no matter what it is internally). > The last we discussed we had layed out that inheirtance hierarachy, > which was interesting. I would say we were leaning toward a separate > space, would you? I think that's better. IMO, it allows cleaner separation. > Arghh!!!!!!!!!!!!! I know they are private but had totally forgotten > #instance_methods is an alias for #public_instance_methods. I was > thinkning it returned all of them. Sigh. It's that kind of thing that > kills me. I can't believe not one person bothered to tell me that on > ruby-talk or ruby-core --I was so frustarated by it --and became > rather confused. Well, thanks for finally removing my confusion. Did I miss something on ruby-talk or ruby-core? I'm skipping a lot these days; it's the only way I can keep up with the volume. Peter From calamitas at advalvas.be Tue Oct 4 15:38:41 2005 From: calamitas at advalvas.be (Peter Vanbroekhoven) Date: Tue, 4 Oct 2005 21:38:41 +0200 (CEST) Subject: [suby-talk] Symbolic Logic In-Reply-To: <4b6f054f05092515022a765825@mail.gmail.com> References: <4b6f054f05092515022a765825@mail.gmail.com> Message-ID: On Sun, 25 Sep 2005, TRANS wrote: > Only that !, &&, || are not definable methods, but ~, &, | and ^ are. Ah, right. Something we should correct in Suby? It does not help for Nano/Mega, although I hope you will have a version of Nana and Mega that will make use of Suby's features! Well, some day :-) >>>> This could possibly be extended to polynomial things, so "5 * >>>> :x * :y" would work too. >>> >>> Interesting. Hadn't though of that. Symbol could be Symbolic Formula? >>> Well, we do call it Symbolic Logic after all :-) >> >> Yup. So, another addition to Mega? I wouldn't mind trying to implement all >> this you know. > > Sure thing! That'd be great! In fact w/ your Prolog background I > imagine this is your cup of tea. Er... It does not have that much to do with Prolog. But it is my cup of tea. Actually I'll probably need this for the precision stuff. I have part of the implementation. For example I could do this: 1.to(5) # => a value with 3.0 as best guess ((1.0 + 5.0) / 2.0), # 1.0 as minimum value and 5.0 as maximum value. # #to_s gives: 3.0 (1.0..5.0) 3.pm(2) # => same thing 3.pm(5) * 3.pm(5) # => 9.0 (-16.0..64.0) However what I have is not entirely accurate. For example a = 3.pm(5) # => 3.0 (-2.0..8.0) a * a # => 9.0 (-16.0..64.0) Note that a * a, or a squared, can never be negative. Yet my library says so because it sees both a's as separate values. They are not though, and it is not that easy to do this right in general. Hence I need to track the history of operations as a symbolic expression. Which is where the symbolic stuff comes in. Peter From calamitas at advalvas.be Tue Oct 4 16:11:56 2005 From: calamitas at advalvas.be (Peter Vanbroekhoven) Date: Tue, 4 Oct 2005 22:11:56 +0200 (CEST) Subject: [suby-talk] "Is" and ideas for moving foward In-Reply-To: <4b6f054f050925151369503793@mail.gmail.com> References: <4b6f054f050924124660760250@mail.gmail.com> <4b6f054f05092417191bff2d60@mail.gmail.com> <4b6f054f05092508333e4366bf@mail.gmail.com> <4b6f054f050925151369503793@mail.gmail.com> Message-ID: On Sun, 25 Sep 2005, TRANS wrote: > I was thinking that in the future only mathods starting a new line (or > after a semi-colon) could forgo the parens. So > > irb(main):003:0> a b 1 > (irb):3: warning: parenthesize argument(s) for future version > => 1 > irb(main):005:0> a( b 1 ) > (irb):5: warning: parenthesize argument(s) for future version > => 1 > > but > > irb(main):004:0> a b( 1 ) > => 1 > > So "m(a b)" isn't allowed. It would have to be one of the two: > > m(a(b)) or m(a,b) > > That's seems to leave the door open for > > m(a b) === m(a,b) > > I'm trying to think of a case were there is an ambiguity and no > reasonabe default interpretation --or no way to use parens to > disambiguate b/c it causes further ambiguity, but I can't yet think of > one. Well, I think your proposal will work. The version without brackets causes trouble when it is nested, so if you only allow it at the toplevel of the expression then there should be no problem. I don't know how easy it is though to convince bison of that... Peter From transfire at gmail.com Tue Oct 4 17:45:18 2005 From: transfire at gmail.com (TRANS) Date: Tue, 4 Oct 2005 17:45:18 -0400 Subject: [suby-talk] Symbolic Logic In-Reply-To: References: <4b6f054f05092515022a765825@mail.gmail.com> Message-ID: <4b6f054f0510041445v2a3798fcu774225e7a1742e61@mail.gmail.com> On 10/4/05, Peter Vanbroekhoven wrote: > On Sun, 25 Sep 2005, TRANS wrote: > > > Only that !, &&, || are not definable methods, but ~, &, | and ^ are. > > Ah, right. Something we should correct in Suby? It does not help for > Nano/Mega, although I hope you will have a version of Nana and Mega that > will make use of Suby's features! Well, some day :-) If we can. I plan to port the choice parts of Nano/Mega to Suby. And I hope to start doing some work on Suby here in a few weeks or so. > >>>> This could possibly be extended to polynomial things, so "5 * > >>>> :x * :y" would work too. > >>> > >>> Interesting. Hadn't though of that. Symbol could be Symbolic Formula? > >>> Well, we do call it Symbolic Logic after all :-) > >> > >> Yup. So, another addition to Mega? I wouldn't mind trying to implement all > >> this you know. > > > > Sure thing! That'd be great! In fact w/ your Prolog background I > > imagine this is your cup of tea. > > Er... It does not have that much to do with Prolog. But it is my cup of > tea. Right. I just ment logic oriented. > Actually I'll probably need this for the precision stuff. I have part of > the implementation. For example I could do this: > > 1.to(5) # => a value with 3.0 as best guess ((1.0 + 5.0) / 2.0), > # 1.0 as minimum value and 5.0 as maximum value. > # #to_s gives: 3.0 (1.0..5.0) > 3.pm(2) # => same thing > 3.pm(5) * 3.pm(5) # => 9.0 (-16.0..64.0) > > However what I have is not entirely accurate. For example > > a = 3.pm(5) # => 3.0 (-2.0..8.0) > a * a # => 9.0 (-16.0..64.0) > > Note that a * a, or a squared, can never be negative. Yet my library says > so because it sees both a's as separate values. They are not though, and > it is not that easy to do this right in general. Hence I need to track > the history of operations as a symbolic expression. Which is where the > symbolic stuff comes in. Cool. It will be interesting to see how this pans out. BTW I just leraned an interesting knew method today: Symbol.all_symbols (There's a lot of em!) T. From transfire at gmail.com Tue Oct 4 17:50:19 2005 From: transfire at gmail.com (TRANS) Date: Tue, 4 Oct 2005 17:50:19 -0400 Subject: [suby-talk] "Is" and ideas for moving foward In-Reply-To: References: <4b6f054f050924124660760250@mail.gmail.com> <4b6f054f05092417191bff2d60@mail.gmail.com> <4b6f054f05092508333e4366bf@mail.gmail.com> <4b6f054f050925151369503793@mail.gmail.com> Message-ID: <4b6f054f0510041450o34531686jc3388fe76e11c4c@mail.gmail.com> On 10/4/05, Peter Vanbroekhoven wrote: > Well, I think your proposal will work. The version without brackets causes > trouble when it is nested, so if you only allow it at the toplevel of the > expression then there should be no problem. I don't know how easy it is > though to convince bison of that... Ye. no big deal I just thought it was interesting b/c I've never known of a lnaguage they might be able to have both. But I tried it out with some code and you know what? It hardly changes anything --and really only serves to obscure. T. From calamitas at advalvas.be Tue Oct 4 18:25:07 2005 From: calamitas at advalvas.be (Peter Vanbroekhoven) Date: Wed, 5 Oct 2005 00:25:07 +0200 (CEST) Subject: [suby-talk] Symbolic Logic In-Reply-To: <4b6f054f0510041445v2a3798fcu774225e7a1742e61@mail.gmail.com> References: <4b6f054f05092515022a765825@mail.gmail.com> <4b6f054f0510041445v2a3798fcu774225e7a1742e61@mail.gmail.com> Message-ID: BTW, as for the precision stuff, which of the following behaviors would you prefer? (I can't decide) It's about division by zero. Say I divide 5.pm(1) by 1.pm(2). Because 1.pm(2) can be anywhere between -1 and 3, this could cause a division by zero. So what should this do? * raise a ZeroDivisionError * 5 / 0.0 is Infinity according to Ruby, but it depends. 5/e approaches +Infinity when e is larger than 0 and approaches 0. 5/e approaches -Infinity when e is smaller than 0 and approaches 0. So technically 5.pm(1)/1.pm(2) can lie between -Infinity and -4 or between 4/3 and +Infinity. This is a range with a hole in it, which isn't supported yet. We could support it, but it gets more complex. * We make the behavior configurable, with a number of options to choose from. Another question is whether we include support for complex numbers. The reason I'm asking is because I plan to override things like Math.sqrt, which could return complex numbers. This would be nice, but it makes things a lot more complex again. The reason is that complex number are actually couples of numbers, and there could be an uncertainty in both components. Hence we get multi-dimensional precision. This could be approximated using Euclidian distance, but even that is not that simple. Of course the same kinds of questions arise when other mathematical entities besides real numbers are considered. For example matrices. Or vectors. I don't know a general way to do precision for these kinds of things by only using the basic operators like +, -, *, /. If we want to do this, we need a way of specifying the general mathematical structure of these things. But the problem that returns is that of multi-dimensional precision. I don't even know whether that would work. Problem is that like complex numbers, matrices don't have a complete order that makes sense. And that is needed when working with ranges. Well, I don't know, while it is interesting from a mathematical viewpoint, I don't know how useful this would be in practice. Peter From transfire at gmail.com Tue Oct 4 18:33:31 2005 From: transfire at gmail.com (TRANS) Date: Tue, 4 Oct 2005 18:33:31 -0400 Subject: [suby-talk] "Is" and ideas for moving foward In-Reply-To: References: <4b6f054f050924124660760250@mail.gmail.com> <4b6f054f05092417191bff2d60@mail.gmail.com> <4b6f054f05092508333e4366bf@mail.gmail.com> <4b6f054f050925145185205cf@mail.gmail.com> Message-ID: <4b6f054f0510041533g45cef892nb0328f8520ced794@mail.gmail.com> On 10/4/05, Peter Vanbroekhoven wrote: > On Sun, 25 Sep 2005, TRANS wrote: > > > With #is and #as and units.rb I start to feel as if Nano/Mega is > > becoming a ... dare I say it? ... a Framework. > > It doesn't matter whether you dare say it, you already did :-) :-) > > Right, I recall now why it is impossible: b/c of the way Ruby parses > > and b/c Ruby is dynamic. So Ruby can't be sure a method even exists > > until it is defined, yet it must be able to parse the code that calls > > that method even it hasn't been defined yet. Just as you mentioned > > before, Python has an advantage in this regard. > > Er... Well, I don't know Puthon, but unless it has type declarations, it > doesn't quite help. Just that is has indention based syntax. > > Oh no, I don't intend that we get rid of singleton class, only that it > > be reduced to one level only --no scary door. The upshot is simply > > that modules always "extend self". It would be almost exactly as if > > one did this themselves whenever they used a module: > > > > module Foo > > extend self > > ... > > end > > And for classes? No. With this idea modules differ from classes more then they do now. With this, self-shimmying also comes into play b/c if a method uses self it would be of little use in the extended context. module Foo extend self def bar; self; end end Foo.bar => Foo But if there was a way to pass a new self then it would useful as either an instance method, when included in a class, or as a module method. It's an interesting idea. I especailly like the fact that it shuts the Scary Door and also one can write module methods without having to do the 'class << self' crud. On the other hand these might be easily had if we had a construct like: object foo ...def singleton methods... end Hmm... maybe that's telling. > You see, but utility functions is a weird word as local methods would be > visible from the outside. They would? hmm... yes, I guess they could. > But perhaps I'm not so right. We're talking here about specific instances > of Class or Module. I mean, the fact that class methods are inherited in > subclasses is something extra. Normally, the singleton class of an object > is a direct subclass of the object's class. Except when that object is a > class, because a class' singleton class is a direct subclass of the > singleton class of its superclass. That's in my opinion exceptional > behavior. > > But let's say that for class methods you should have a choice of > inheritability. Then what's the defaults: inheritability of > non-inheritability? I'm just wondering what is needed most often. I've > never really encountered problems with class methods being inheritable. > Either I want them to inherit, so there is no problem. Or I don't want > them to inherit, but even if they do, I'm not calling these methods on the > subclasses, only on my own class, so there is no problem. I must say > though that the latter case is rather the rule, the former case the > exception. > > As for how it would look underneath the hood, that's the picture you've > once drawn for me (although that was about private methods). So it would > look like this: > > c1 --c--> LocalC1 --s--> GlobalC1 --s--> Class > ^ > | > s > | > c2 --c--> LocalC2 --s--> GlobalC1 > > At this point one must wonder though. This can actually be done in Ruby > now. When defining a class C1, define a GlobalC1 (or just C1) that is > intended to be subclasses, and a LocalC1 that is not intended to be > subclassed. I don't know if it would work for classes though; I think not. > But this raises the question of how explicit this is going to be. Do we > allow people to get hold of both LocalC1 and GlobalC1? If so, which is > returned when asked for C1 tout court? I think for meta-programming, it > would be nice if it were possible to return "the object containing the > non-inheritable methods". Could be a module, or class (no matter what it > is internally). I'm with you on this. Let the module inherit like the class, then there would a "inner" module of sorts that extends the module but doesn't inherit: module M module UninheritedMethods ... end end (the exact opposite of what's done today to get them to inhrit, i.e. ClassMethods module). But with a better built-in notation, of course. It's a compatability issue with Ruby, but I think we should go for this one. > > The last we discussed we had layed out that inheirtance hierarachy, > > which was interesting. I would say we were leaning toward a separate > > space, would you? > > I think that's better. IMO, it allows cleaner separation. Cool. How do we treat protected btw? Another space? > > Arghh!!!!!!!!!!!!! I know they are private but had totally forgotten > > #instance_methods is an alias for #public_instance_methods. I was > > thinkning it returned all of them. Sigh. It's that kind of thing that > > kills me. I can't believe not one person bothered to tell me that on > > ruby-talk or ruby-core --I was so frustarated by it --and became > > rather confused. Well, thanks for finally removing my confusion. > > Did I miss something on ruby-talk or ruby-core? I'm skipping a lot these > days; it's the only way I can keep up with the volume. Oh, it was nothing. I just moaned about a couple of things one ngiht --ranted a little and that was one of the things I spouted off about. T. From transfire at gmail.com Tue Oct 4 19:39:10 2005 From: transfire at gmail.com (TRANS) Date: Tue, 4 Oct 2005 19:39:10 -0400 Subject: [suby-talk] Symbolic Logic In-Reply-To: References: <4b6f054f05092515022a765825@mail.gmail.com> <4b6f054f0510041445v2a3798fcu774225e7a1742e61@mail.gmail.com> Message-ID: <4b6f054f0510041639i56ec9ebam70b5979054a95b85@mail.gmail.com> On 10/4/05, Peter Vanbroekhoven wrote: > BTW, as for the precision stuff, which of the following behaviors would > you prefer? (I can't decide) It's about division by zero. Say I divide > 5.pm(1) by 1.pm(2). Because 1.pm(2) can be anywhere between -1 and 3, this > could cause a division by zero. So what should this do? > > * raise a ZeroDivisionError > * 5 / 0.0 is Infinity according to Ruby, but it depends. 5/e approaches > +Infinity when e is larger than 0 and approaches 0. 5/e approaches > -Infinity when e is smaller than 0 and approaches 0. So technically > 5.pm(1)/1.pm(2) can lie between -Infinity and -4 or between 4/3 and > +Infinity. This is a range with a hole in it, which isn't supported yet. > We could support it, but it gets more complex. > * We make the behavior configurable, with a number of options to choose > from. I'm not sure. Seems like #2 is the most proper? If its too complex for the time being I would probably make is raise an error, perhaps something a little more specialized then divide by zero, then come back to it. If you want to represent general solution ranges though, eventually "mulitranges" will need to be supported. How are you representing Infinity btw? > Another question is whether we include support for complex numbers. The > reason I'm asking is because I plan to override things like Math.sqrt, > which could return complex numbers. This would be nice, but it makes > things a lot more complex again. The reason is that complex number are > actually couples of numbers, and there could be an uncertainty in both > components. Hence we get multi-dimensional precision. This could be > approximated using Euclidian distance, but even that is not that simple. Hmm. Ruby has a Complex class already. I would guess that doing the precision for a couple of numbers would be readily exrapolated from the single number cases, but obviously I'm not there to know. Nonethless, I would probably take the same approach. Get the main of it down and come back to complex numbers later. > Of course the same kinds of questions arise when other mathematical > entities besides real numbers are considered. For example matrices. Or > vectors. I don't know a general way to do precision for these kinds of > things by only using the basic operators like +, -, *, /. If we want to do > this, we need a way of specifying the general mathematical structure of > these things. But the problem that returns is that of multi-dimensional > precision. I don't even know whether that would work. Problem is that like > complex numbers, matrices don't have a complete order that makes sense. > And that is needed when working with ranges. Well, I don't know, while it > is interesting from a mathematical viewpoint, I don't know how useful this > would be in practice. Oh wow. That's really going the distance! You're going to be half way to RubyMathematica before you're though ;-) Hmm... Maybe we should package up all this units/math stuff into it's own project? Or do you think it better being a part of Mega? BTW I'm thinking of reviving the name Facets --I have gotton a lot of people wrtting me about Facets recently. Seems more people are using Facets then Nano/Mega. Just have to figure out the best way to handle this smoothly --which is the main reason Roll came about, so I could give parts of a lib different aliases, versioning was actaully just a side effect. T. From calamitas at advalvas.be Wed Oct 5 17:56:46 2005 From: calamitas at advalvas.be (Peter Vanbroekhoven) Date: Wed, 5 Oct 2005 23:56:46 +0200 (CEST) Subject: [suby-talk] "Is" and ideas for moving foward In-Reply-To: <4b6f054f0510041450o34531686jc3388fe76e11c4c@mail.gmail.com> References: <4b6f054f050924124660760250@mail.gmail.com> <4b6f054f05092417191bff2d60@mail.gmail.com> <4b6f054f05092508333e4366bf@mail.gmail.com> <4b6f054f050925151369503793@mail.gmail.com> <4b6f054f0510041450o34531686jc3388fe76e11c4c@mail.gmail.com> Message-ID: On Tue, 4 Oct 2005, TRANS wrote: > Ye. no big deal I just thought it was interesting b/c I've never known > of a lnaguage they might be able to have both. But I tried it out with > some code and you know what? It hardly changes anything --and really > only serves to obscure. I'm wondering. When do you leave out the brackets? I only do that at the top level of an expression, and only when there's a single argument. Otherwise I usually find it ugly and want to add the brackets. Peter From transfire at gmail.com Wed Oct 5 20:06:21 2005 From: transfire at gmail.com (TRANS) Date: Wed, 5 Oct 2005 20:06:21 -0400 Subject: [suby-talk] "Is" and ideas for moving foward In-Reply-To: References: <4b6f054f050924124660760250@mail.gmail.com> <4b6f054f05092417191bff2d60@mail.gmail.com> <4b6f054f05092508333e4366bf@mail.gmail.com> <4b6f054f050925151369503793@mail.gmail.com> <4b6f054f0510041450o34531686jc3388fe76e11c4c@mail.gmail.com> Message-ID: <4b6f054f0510051706o2c9c2454g4224a54526ac4c5b@mail.gmail.com> On 10/5/05, Peter Vanbroekhoven wrote: > On Tue, 4 Oct 2005, TRANS wrote: > > > Ye. no big deal I just thought it was interesting b/c I've never known > > of a lnaguage they might be able to have both. But I tried it out with > > some code and you know what? It hardly changes anything --and really > > only serves to obscure. > > I'm wondering. When do you leave out the brackets? I only do that at the > top level of an expression, and only when there's a single argument. > Otherwise I usually find it ugly and want to add the brackets. Yep. I do the same. T. From calamitas at advalvas.be Thu Oct 6 14:02:13 2005 From: calamitas at advalvas.be (Peter Vanbroekhoven) Date: Thu, 6 Oct 2005 20:02:13 +0200 (CEST) Subject: [suby-talk] "Is" and ideas for moving foward In-Reply-To: <4b6f054f0510041533g45cef892nb0328f8520ced794@mail.gmail.com> References: <4b6f054f050924124660760250@mail.gmail.com> <4b6f054f05092417191bff2d60@mail.gmail.com> <4b6f054f05092508333e4366bf@mail.gmail.com> <4b6f054f050925145185205cf@mail.gmail.com> <4b6f054f0510041533g45cef892nb0328f8520ced794@mail.gmail.com> Message-ID: On Tue, 4 Oct 2005, TRANS wrote: >>> Right, I recall now why it is impossible: b/c of the way Ruby parses >>> and b/c Ruby is dynamic. So Ruby can't be sure a method even exists >>> until it is defined, yet it must be able to parse the code that calls >>> that method even it hasn't been defined yet. Just as you mentioned >>> before, Python has an advantage in this regard. >> >> Er... Well, I don't know Puthon, but unless it has type declarations, it >> doesn't quite help. > > Just that is has indention based syntax. Ah, so the end of a block or method or class definition is clearly marked. That may help. >>> Oh no, I don't intend that we get rid of singleton class, only that it >>> be reduced to one level only --no scary door. The upshot is simply >>> that modules always "extend self". It would be almost exactly as if >>> one did this themselves whenever they used a module: >>> >>> module Foo >>> extend self >>> ... >>> end >> >> And for classes? > > No. With this idea modules differ from classes more then they do now. > With this, self-shimmying also comes into play b/c if a method uses > self it would be of little use in the extended context. > > module Foo > extend self > def bar; self; end > end > > Foo.bar => Foo > > But if there was a way to pass a new self then it would useful as > either an instance method, when included in a class, or as a module > method. > > It's an interesting idea. I especailly like the fact that it shuts the > Scary Door and also one can write module methods without having to do > the 'class << self' crud. On the other hand these might be easily had > if we had a construct like: > > object foo > ...def singleton methods... > end > > Hmm... maybe that's telling. Well, I agree that module methods seldom make sense as instance methods and vice versa. Still I'm not sure they really belong in the same namespace then. It means there can be no module methods with the same name as an instance method. And module methods can wrongly be called as instance methods and vice versa. This is not a big deal per se as long as they don't get called like that. But then we get back to non-inheritable methods: there's no problem if they are inherited, as long as they don't get called. So maybe that's OK in both instances. But I still wonder though what makes modules so special that module methods and instance methods should fall in the same namespace, and for classes they are spearate. Actually, doing it that way for classes brings us a step closer to protype-based OOP. I mean, the class of an object would be the prototype it was copied from. So the instance methods and the class methods are the same. >> You see, but utility functions is a weird word as local methods would be >> visible from the outside. > > They would? hmm... yes, I guess they could. Hmmmmm. We should clear up our terminology, I guess. I assumed that local methods and non-inheritable methods are the same. > I'm with you on this. Let the module inherit like the class, then > there would a "inner" module of sorts that extends the module but > doesn't inherit: > > module M > module UninheritedMethods > ... > end > end > > (the exact opposite of what's done today to get them to inhrit, i.e. > ClassMethods module). But with a better built-in notation, of course. > It's a compatability issue with Ruby, but I think we should go for > this one. Something likewise I've been wondering about today. It's in a sense the inverse of the above. I was just thinking of making class method lookup the same as constant lookup. This means that class methods are looked up in the class, then in its superclass, and so on, and if not found in the enclosing class/module, its superclass/included module, etc. This could allow for interesting possibilities. > Cool. How do we treat protected btw? Another space? I think so. Somewhere between a class and its subclasses. > Oh, it was nothing. I just moaned about a couple of things one ngiht > --ranted a little and that was one of the things I spouted off about. :-) Peter From calamitas at advalvas.be Thu Oct 6 15:39:46 2005 From: calamitas at advalvas.be (Peter Vanbroekhoven) Date: Thu, 6 Oct 2005 21:39:46 +0200 (CEST) Subject: [suby-talk] Symbolic Logic In-Reply-To: <4b6f054f0510041639i56ec9ebam70b5979054a95b85@mail.gmail.com> References: <4b6f054f05092515022a765825@mail.gmail.com> <4b6f054f0510041445v2a3798fcu774225e7a1742e61@mail.gmail.com> <4b6f054f0510041639i56ec9ebam70b5979054a95b85@mail.gmail.com> Message-ID: On Tue, 4 Oct 2005, TRANS wrote: > I'm not sure. Seems like #2 is the most proper? If its too complex for > the time being I would probably make is raise an error, perhaps > something a little more specialized then divide by zero, then come > back to it. If you want to represent general solution ranges though, > eventually "mulitranges" will need to be supported. I know. Although I could always approximate by filling the gaps. I've got the impression that multiranges would go beyond what I intended at first. I mean, that's no longer about precision. Of course that doesn't mean I can't do it of course. > How are you representing Infinity btw? I'm not yet. I assume you want to point out to me that Mega has an Infinity class ;-) Well, seems it has a bug though: irb(main):008:0> Infinity[1] NoMethodError: private method `new' called for Infinity:Class from /home/peterv/local/lib/ruby/gems/1.8/gems/mega-0.3.1/lib/mega/infinity.rb:55:in `[]' >From what I can see, seems you want it to be more than just infinity. Isn't Aleph0 and so on supposed to be different from infinity? I thought they invented the Aleph numbers because infinity is way too crude a measure for this. Besides, if you want to go all the way, use ordinal numbers; they're much more fun! Even the Aleph numbers can't match ordinal numbers. > Hmm. Ruby has a Complex class already. I would guess that doing the > precision for a couple of numbers would be readily exrapolated from > the single number cases, but obviously I'm not there to know. > Nonethless, I would probably take the same approach. Get the main of > it down and come back to complex numbers later. Well, I think I've got an idea of how to do this. It's an approximation, but at some point we'll have to revert to approximations anyhow. It looks like this: Complex.new(5.pm(2), 7.pm(3)) # => Complex(5.0 (3.0..7.0), 7.0 (4.0..10.0)) It's an approximation because of this: Complex.new(1, 1) # => Complex(1, 1) Complex.new(1, 1) * 5.pm(2) # => Complex(5.0 (3.0..7.0), 5.0 (3.0..7.0)) This would include Complex(3.0, 7.0) among the possibilities, although this is not a multiple of Complex.new(1, 1). I don't know how to do better in general. Maybe I'll figure it out yet. > Oh wow. That's really going the distance! You're going to be half way > to RubyMathematica before you're though ;-) Yeah, that's the goal, definitely! (It really helps to pose realistic goals, doesn't it? ;-) > Hmm... Maybe we should package up all this units/math stuff into it's > own project? Or do you think it better being a part of Mega? BTW I'm > thinking of reviving the name Facets --I have gotton a lot of people > wrtting me about Facets recently. Seems more people are using Facets > then Nano/Mega. Just have to figure out the best way to handle this > smoothly --which is the main reason Roll came about, so I could give > parts of a lib different aliases, versioning was actaully just a side > effect. Well, it seems like once we're through with our plans, this thing will be quite big. So maybe a separate project is better indeed. But we'll see, it's a lot of work and it may very well never get finished. Peter From transfire at gmail.com Sat Oct 8 21:11:38 2005 From: transfire at gmail.com (TRANS) Date: Sat, 8 Oct 2005 21:11:38 -0400 Subject: [suby-talk] Symbolic Logic In-Reply-To: References: <4b6f054f05092515022a765825@mail.gmail.com> <4b6f054f0510041445v2a3798fcu774225e7a1742e61@mail.gmail.com> <4b6f054f0510041639i56ec9ebam70b5979054a95b85@mail.gmail.com> Message-ID: <4b6f054f0510081811r2318af4fj9d96bacf4245942c@mail.gmail.com> On 10/6/05, Peter Vanbroekhoven wrote: > On Tue, 4 Oct 2005, TRANS wrote: > > How are you representing Infinity btw? > > I'm not yet. I assume you want to point out to me that Mega has an > Infinity class ;-) Well, seems it has a bug though: > irb(main):008:0> Infinity[1] > NoMethodError: private method `new' called for Infinity:Class > from > /home/peterv/local/lib/ruby/gems/1.8/gems/mega-0.3.1/lib/mega/infinity.rb:55:in > `[]' Thanks, I'll have to look at that. Actually I brought it up wondering if you have a better solution than the one in Mega. > >From what I can see, seems you want it to be more than just infinity. > Isn't Aleph0 and so on supposed to be different from infinity? I thought > they invented the Aleph numbers because infinity is way too crude a > measure for this. Besides, if you want to go all the way, use ordinal > numbers; they're much more fun! Even the Aleph numbers can't match ordinal > numbers. Well, I tried to give it a little bit "extra". I'm thought the alephs were measures of infinity. So Aleph0 is your standard first-tier infinity. aleph1 is the next tier, bigger then aleph0, and so (not that they are actually bigger quanitatively). But maybe I'm misinformed. Ordinal numbers? Please I'm after the Transfinites ;-) > > Oh wow. That's really going the distance! You're going to be half way > > to RubyMathematica before you're though ;-) > > Yeah, that's the goal, definitely! (It really helps to pose realistic > goals, doesn't it? ;-) :-) > > Hmm... Maybe we should package up all this units/math stuff into it's > > own project? Or do you think it better being a part of Mega? BTW I'm > > thinking of reviving the name Facets --I have gotton a lot of people > > wrtting me about Facets recently. Seems more people are using Facets > > then Nano/Mega. Just have to figure out the best way to handle this > > smoothly --which is the main reason Roll came about, so I could give > > parts of a lib different aliases, versioning was actaully just a side > > effect. > > Well, it seems like once we're through with our plans, this thing will be > quite big. So maybe a separate project is better indeed. But we'll see, > it's a lot of work and it may very well never get finished. I'm including units.rb in Mega for now --by the way George is going to hate me, but I've gone back to the original names Facets and Carats. As much as I like Nano and Mega, I think its more b/c they are "trendy". When I was talking to my grandmother about them, she thought they were stupid names :-) The main reason is simple though. More people write me about Facets every day! I've been thinking about putting Carats(Mega) into Facets also, but the lib layout just dosn't lend itelf. So I may just have to live with the name Carats unless I can think of something better to go with Facets ASAP. Oh, one other thing. In the end I settled on your solution for meta-methods (huh, now that's ironic), but instead of #__ I called it #__meta__. T. From calamitas at advalvas.be Sun Oct 9 17:46:19 2005 From: calamitas at advalvas.be (Peter Vanbroekhoven) Date: Sun, 9 Oct 2005 23:46:19 +0200 (CEST) Subject: [suby-talk] Symbolic Logic In-Reply-To: <4b6f054f0510081811r2318af4fj9d96bacf4245942c@mail.gmail.com> References: <4b6f054f05092515022a765825@mail.gmail.com> <4b6f054f0510041445v2a3798fcu774225e7a1742e61@mail.gmail.com> <4b6f054f0510041639i56ec9ebam70b5979054a95b85@mail.gmail.com> <4b6f054f0510081811r2318af4fj9d96bacf4245942c@mail.gmail.com> Message-ID: On Sat, 8 Oct 2005, TRANS wrote: > Thanks, I'll have to look at that. Actually I brought it up wondering > if you have a better solution than the one in Mega. Well, I need to think about it some more. It will be part of the 'more mathematical structure' stuff. Division by zero is a tricky thing. For floats, dividing any number (except zero) by zero gives infinity (+ or -, can be both depending on 'what side you look at it'). However dividing a complex number by zero gives a different answer for different complex numbers. For example while 1+i and 2+2i give the same result when divided by 0, 1+2i and 2+i give different results. The reason is very simple: for floats you can go infinitely far in two directions (towards +infinity en towards -infinity), but with complex numbers being two-dimensional, there are infinitely many directions to go in, hence there are infinitely many infinities. I haven't decided yet how I'm going to approach these in general. I would like to though. > Well, I tried to give it a little bit "extra". I'm thought the alephs > were measures of infinity. So Aleph0 is your standard first-tier > infinity. aleph1 is the next tier, bigger then aleph0, and so (not > that they are actually bigger quanitatively). But maybe I'm > misinformed. Ordinal numbers? Please I'm after the Transfinites ;-) Hmmmm, I guess I was nitpicking. Formally Aleph0 is not infinity as there are infinitely many infinities. (Actually, the set of infinities is not even countable infinite.) I would probably have introduced the Aleph numbers separately. And Ordinal numbers? Well, while there are (infinitely many) 'finite' ordinal numbers, once you get past omega, the resolution is better than the Aleph numbers. Actually it is _much_ better since the resolution of the Aleph numbers gets worse as they get bigger. You could say that the set of infinities between Aleph(n) and Aleph(n+1) has Aleph(n+1) as cardinal number. Ordinal numbers can represent each of these infinities. Of course ordinal numbers make no sense as cardinal numbers, and the Aleph numbers make no sense as your standard, run-of-the mill infinity which can be created by dividing one by zero. In the other direction, infinity could pass for Aleph0, and Aleph0 could pass for omega, Aleph1 for omega**omega, and so on. So I don't know, I just feel it's dangerous to intermix these just like that. > I'm including units.rb in Mega for now --by the way George is going to > hate me, but I've gone back to the original names Facets and Carats. > As much as I like Nano and Mega, I think its more b/c they are > "trendy". When I was talking to my grandmother about them, she thought > they were stupid names :-) The main reason is simple though. More > people write me about Facets every day! I've been thinking about > putting Carats(Mega) into Facets also, but the lib layout just dosn't > lend itelf. So I may just have to live with the name Carats unless I > can think of something better to go with Facets ASAP. Okidoki. Pity though, I got kind of attached to the names Nano and Mega. I haven't made any progress yet on the precision and symbolic libraries. A friend of mine told me about a simple yet addictive little game and it's so hard to give up ;-) > Oh, one other thing. In the end I settled on your solution for > meta-methods (huh, now that's ironic), but instead of #__ I called it > #__meta__. Lengthier, but at least the name conveys some idea of its purpose. Peter From transfire at gmail.com Sat Oct 15 18:09:14 2005 From: transfire at gmail.com (TRANS) Date: Sat, 15 Oct 2005 18:09:14 -0400 Subject: [suby-talk] "Is" and ideas for moving foward In-Reply-To: References: <4b6f054f050924124660760250@mail.gmail.com> <4b6f054f05092417191bff2d60@mail.gmail.com> <4b6f054f05092508333e4366bf@mail.gmail.com> <4b6f054f050925145185205cf@mail.gmail.com> <4b6f054f0510041533g45cef892nb0328f8520ced794@mail.gmail.com> Message-ID: <4b6f054f0510151509t95d0c84i619ce4a736624845@mail.gmail.com> On 10/6/05, Peter Vanbroekhoven wrote: > Well, I agree that module methods seldom make sense as instance methods > and vice versa. Still I'm not sure they really belong in the same > namespace then. It means there can be no module methods with the same name > as an instance method. And module methods can wrongly be called as > instance methods and vice versa. This is not a big deal per se as long as > they don't get called like that. But then we get back to non-inheritable > methods: there's no problem if they are inherited, as long as they don't > get called. So maybe that's OK in both instances. > > But I still wonder though what makes modules so special that module > methods and instance methods should fall in the same namespace, and for > classes they are spearate. Actually, doing it that way for classes brings > us a step closer to protype-based OOP. I mean, the class of an object > would be the prototype it was copied from. So the instance methods and the > class methods are the same. > > >> You see, but utility functions is a weird word as local methods would be > >> visible from the outside. > > > > They would? hmm... yes, I guess they could. > > Hmmmmm. We should clear up our terminology, I guess. I assumed that local > methods and non-inheritable methods are the same. Well there's two factors. Visibilty and inheritability, so we have have a grid I think Inhertiable Non-Inheritable public protected private But maybe we can remove protected, maybe an inheritable private is the saem as protected? And should there be such a thing as public non-inhertiable? BTW I would also like make instance vars local too, although I know that will break code. > Something likewise I've been wondering about today. It's in a sense the > inverse of the above. I was just thinking of making class method lookup > the same as constant lookup. This means that class methods are looked up > in the class, then in its superclass, and so on, and if not found in the > enclosing class/module, its superclass/included module, etc. This could > allow for interesting possibilities. Hmmm like this? class X def self.x ; "hello" ; end class Y def self.q ; x ; end end end X::Y.q #=> "hello" I wonder how that would effect things. Likewise I've sometimes wondered how things would be effected if that alos reperesented subclassing, i.e. in the above Y would be a subclass of X. T. From transfire at gmail.com Tue Oct 18 16:11:39 2005 From: transfire at gmail.com (TRANS) Date: Tue, 18 Oct 2005 16:11:39 -0400 Subject: [suby-talk] Patches now on devsite Message-ID: <4b6f054f0510181311l6a721320icfe5454744aefa62@mail.gmail.com> I've moved the patches from the old Suby site at Berlios.de to the new one on Rubyforge. http://rubyforge.org/frs/?group_id=137 T. From calamitates at gmail.com Tue Oct 18 16:55:01 2005 From: calamitates at gmail.com (Peter Vanbroekhoven) Date: Tue, 18 Oct 2005 22:55:01 +0200 (CEST) Subject: [suby-talk] Patches now on devsite In-Reply-To: <4b6f054f0510181311l6a721320icfe5454744aefa62@mail.gmail.com> References: <4b6f054f0510181311l6a721320icfe5454744aefa62@mail.gmail.com> Message-ID: On Tue, 18 Oct 2005, TRANS wrote: > I've moved the patches from the old Suby site at Berlios.de to the new > one on Rubyforge. > > http://rubyforge.org/frs/?group_id=137 Did you specify the type of these patches to be an archive, or does rubyforge do that automatically? At Berlios, I could view those patches in my browser, but at Rubyforge it thinks they are tar archives. Peter From transfire at gmail.com Tue Oct 18 17:25:05 2005 From: transfire at gmail.com (TRANS) Date: Tue, 18 Oct 2005 17:25:05 -0400 Subject: [suby-talk] Patches now on devsite In-Reply-To: References: <4b6f054f0510181311l6a721320icfe5454744aefa62@mail.gmail.com> Message-ID: <4b6f054f0510181425n511fc36ds5a5864ceda02541e@mail.gmail.com> On 10/18/05, Peter Vanbroekhoven wrote: > On Tue, 18 Oct 2005, TRANS wrote: > > > I've moved the patches from the old Suby site at Berlios.de to the new > > one on Rubyforge. > > > > http://rubyforge.org/frs/?group_id=137 > > Did you specify the type of these patches to be an archive, or does > rubyforge do that automatically? At Berlios, I could view those patches in > my browser, but at Rubyforge it thinks they are tar archives. Doesn't seem to allow it. I can change their type from "Other" to "text" but they still do not seem to be viewable in the browser :-( T From calamitates at gmail.com Tue Oct 18 17:31:44 2005 From: calamitates at gmail.com (Peter Vanbroekhoven) Date: Tue, 18 Oct 2005 23:31:44 +0200 (CEST) Subject: [suby-talk] Patches now on devsite In-Reply-To: <4b6f054f0510181425n511fc36ds5a5864ceda02541e@mail.gmail.com> References: <4b6f054f0510181311l6a721320icfe5454744aefa62@mail.gmail.com> <4b6f054f0510181425n511fc36ds5a5864ceda02541e@mail.gmail.com> Message-ID: On Tue, 18 Oct 2005, TRANS wrote: > Doesn't seem to allow it. I can change their type from "Other" to > "text" but they still do not seem to be viewable in the browser :-( That's something we'll have to live with then. Seems I missed a post from you while my email forwarding was out. Reply coming right up! Peter From calamitates at gmail.com Tue Oct 18 17:54:20 2005 From: calamitates at gmail.com (Peter Vanbroekhoven) Date: Tue, 18 Oct 2005 23:54:20 +0200 (CEST) Subject: [suby-talk] your mail In-Reply-To: References: Message-ID: On Tue, 18 Oct 2005, Peter Vanbroekhoven wrote: > Well there's two factors. Visibilty and inheritability, so we have > have a grid I think > > Inhertiable Non-Inheritable > public > protected > private > > But maybe we can remove protected, maybe an inheritable private is the > saem as protected? And should there be such a thing as public > non-inhertiable? I think that depends. In a way they all make sense. Public non-inheritable methods for example can give a certain class some methods, callable from the outside of the class, but that subclasses do not get. Inheritable private is a weird thing in the sense that defining a private inheritable method blocks methods by the same name from superclasses. Whether that's useful or not, I don't know. Unless we can prove that it doesn't make sense, I wouldn't dismiss it. > BTW I would also like make instance vars local too, although I know > that will break code. Well, making them local is not the problem, but allowing a mix is tougher, and possibly very expensive. > Hmmm like this? > > class X > def self.x ; "hello" ; end > class Y > def self.q ; x ; end > end > end > > X::Y.q #=> "hello" > > I wonder how that would effect things. Likewise I've sometimes > wondered how things would be effected if that alos reperesented > subclassing, i.e. in the above Y would be a subclass of X. alos = also? Well, then the same would work for instance methods. But I don't know what the problems with that are. In a sense our proposals add extra methods in places where there were none before, and I don't know how many problems that may give. Peter From transfire at gmail.com Wed Oct 19 19:40:49 2005 From: transfire at gmail.com (TRANS) Date: Wed, 19 Oct 2005 19:40:49 -0400 Subject: [suby-talk] Comment on cut-based AOP Message-ID: <4b6f054f0510191640t3f368c9drbe7a77b7b2267cd1@mail.gmail.com> I'm copynig this from the posting this from RCRchive comment in order to discuss. --- I am not opposed to AOP in Ruby. Nor am I opposed to the principle of "cuts" for the implementation of AOP in Ruby. I however voted opposed to the RCR in its current form due to a major flaw (in my mind) of the current implementation of cuts. The flaw is this: a cut made on a base class is always inserted immediately under the base class in the inheritance heirarchy; that is, advice from the cut is always imposed between the aspected classes method and any redefinition/extension of that method in subclasses. In my view of AOP, it should be possible to have the advice atomically surround the method, no matter the depth below the actual cut point. Take this (contrived) example: class Foo def name "Foo" end end class Bar < Foo def name "Bar < " + super end end cut BracketName < Foo def name "[" + super + "]" end end Bar.new.name In the current implementation, the advice is applied strictly to Foo#name, including the call to super from Bar#name. Result: "Bar < [Foo]" In some cases this is fine, but in other cases I would expect the advice to be applied around the call to Bar#name with the internal call to super (Foo#name) untouched, yielding: "[Bar < Foo]" In order to vote in support of an implementation of AOP in Ruby, I would require both versions of advice to be supported, with a reasonable way of distinguising the two. I *do* want AOP in Ruby, and like the concept of "cuts" you have introduced here. Congratulations and many thanks for the work you've done so far. If you expand the RCR to include the functionality described above, I will gladly change my vote in favor of the RCR. Jacob Fugal lukfugl at gmail.com