Re: 'my int( 1..31 ) $var' ?
Attriel wrote: Well, in general I think it would be good to have some mechanism for determining the type of the data rather than the type of a representation of the contained value. Why? One of the nice things about Perl is that coercian takes care of these kind of things so that you don't have to worry about them. If you pass a string containing a sequence of digit characters when an integer is expected, Perl just works it out. If I have 0, it's possible I might at some point (this having been user input perhaps) have some reason to care whether it was an integer or a string. How would the user distinguish when providing the input? The Perl 5 ways of reading input -- whether from the keyboard, a file, or a form on a webpage -- yield strings. Even if the user thinks she has provided an integer, the program gets a string (but that doesn't matter). For validation purposes things like Regexp::Common are currently handy for determining whether provided input can be treated as a number or an integer or whatever. Perl 6's ability to use its own grammar rules should make those kinds of things considerably easier. I know I hate the fact that, in almost every lang I use, adding the strings 014 and 231 requires me to do ' + string1 + + string2 ' Fortunately Perl isn't one of those languages. In general you need for either variables or operators to be typed. JavaScript has problems with untyped variables and addition/concatenation; PHP has problems with string/numeric comparisons. Many languages 'solve' this problem by ensuring all variables have types. Perl goes the other way and ensures operators are sufficiently typed, having C+ and C., and Clt and C . Perl 5 fell down in having the bitwise operators behave differently with numbers and strings; Perl 6 fixes this by having different operators for each operation. So the type that data has previously been (albeit possibly only in the mind of the user who entered it) isn't particularly useful; if the data can be coerced to that type (or any other required type), then that is sufficient. ... I imagine there might exist cases where the information is useful ... I'm struggling to think of any -- if you come up with some please could you mail them so I can understand your viewpoint better. Needing to know about this kind of thing strikes me as most unPerlish. Smylers
Re: Variable Types Vs Value Types
John Williams wrote: Do they? One is obviously an array, and one is obviously a scalar. You may get an error (cannot alias an array as a scalar) or $b get aliased to the array-in-scalar-context (a reference). This is one of those how we think about the fundamentals things. I am taking the viewpoint that everything is in object. A number is an object; an array is an object, a hash is in object. The only thing that differs is that they implement different interfaces. Perl6 provides syntaxes for those interfaces. $a and @a are both holders of objects. One of the issues I hoped to provike discussion of is the difference between $b = @a; and $c := @a; The former obviously creates a reference to the array; but does the latter? An ArrayRef is an object that provides indirection to an array object. But for $c, I have requested a binding, not an assignment. $c should hold, literally, the same object as @a. If an ArrayRef is a new object, then we shouldn't create this new object as part of a binding operation. But if @a is just an object -- with a vtable + data -- like any other object, then $c should be able to hold that object. Conversly, an Ctie operation should be nothing more than $obj = new ArrayLikeThing; @a := $obj; # the tie $b = @a; # creates arrayRef: \$obj $c := @a; # eq:ID $obj The abstraction I'm getting at is that the @ and $ sigils simply provide different DWIMing behavior: there is no fundamental difference between the objects they can hold: an object is an object. Let us suppose that the type-definition syntax allows us to tell perl: when you use this variable in numeric context, call your object's Csum method.. now, when we code That would happen when you override the .num method, or whatever the value-in-numeric-context method is called. If only objects have types then yes, you'd override the .num method. But that sidesteps the issue: what if a *variable* has its own behaviour. The default scalar type might, indeed, call .num when it is used in numeric context: but this is just a mapping between a static context and a vtable entry. Lets avoid the question of the semantics of @ vs $: lets assume that I can say my Foo $a = ...; my Bar $b := $a; Assuming that Foo and Bar are both compatible with the referenced object, do both $a and $b behave identically? Or can the variable's type influence the behavior of that variable (remember that variable types are always lexically scoped, unlike their values). This type of thing need not be limited to the implicit method calls introduced by perl to DWIM. It might be as simple as type Bar saying that a call to .aaa will actually call .bbb. So $a.aaa will invoke a different method than $b.aaa -- even though both variables hold the same object. This might seem like a silly thing to want to do; but it seems to me that there are often cases where we want different behaviors in different contexts. Sure, we can define multiple interfaces; but then we run into issues with namespace conflicts. I'm not sure how useful this stuff would be; nor how bad the potential for confusion is. But it feels like a good conceptual unification. Dave.
Re: This week's Perl Summary
Piers Cawley wrote: * Thanks to everyone who has given me feedback as a result of these summaries. It's really good to know that people finding these things useful. Me too. I find I no longer read the list because I can pick up the few relevant bits from the summary and follow them up in makeshortlink. Can I just get your summary and drop the rest of the subscription? Paul Kienzle [EMAIL PROTECTED] Perhaps a future implementor of the matlab interpreter in parrot.
Re: Variable Types Vs Value Types
At 1:19 PM -0800 1/3/03, Dave Whipp wrote: I am taking the viewpoint that everything is in object. Then you'll likely be somewhat surprised at times. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Variable Types Vs Value Types
On Fri, 3 Jan 2003, Dave Whipp wrote: John Williams wrote: Do they? One is obviously an array, and one is obviously a scalar. You may get an error (cannot alias an array as a scalar) or $b get aliased to the array-in-scalar-context (a reference). This is one of those how we think about the fundamentals things. I am taking the viewpoint that everything is in object. How you or I think about the fundamentals is a moot point, really. Objects are not covered until apocalypse 20-something, so the main thing we have to go on is Larry's statement to the effect that things will behave like objects if you treat them like objects. One of the issues I hoped to provike discussion of is the difference between $b = @a; and $c := @a; The former obviously creates a reference to the array; but does the latter? That is a good question. Someone wiser that me will have to interpret the true meaning of $c := @a;. An ArrayRef is an object that provides indirection to an array object. But for $c, I have requested a binding, not an assignment. $c should hold, literally, the same object as @a. If an ArrayRef is a new object, then we shouldn't create this new object as part of a binding operation. Saying an Arrayef is a different object from an Array may be taking the analogy a bit too far. They are different things, yes, but since perl6 references dereference automatically, calling an method on an ArrayRef will be the same as calling a method on the Array it references. If only objects have types then yes, you'd override the .num method. But that sidesteps the issue: what if a *variable* has its own behaviour. Well, I suspect that would be a bad idea. One of the really annoying things about most OO languages is that if I call my Geo Prizm a Vehicle, it suddenly forgets that it is a Geo Prizm. So $ParkingLot.Vehicle[38].door.open() would fail because not all Vehicles (motorcycles) have doors. I really hope that a weakly-typed, OO language will free me from type-casting hell. If variables get to have their own behavior, then you have accomplished the same thing in a different way. We will have to typecast our cars/objects every time we go the the parking lot/collection, because we want them to stop acting like generic vehicles/superclasses. my Foo $a = ...; my Bar $b := $a; Assuming that Foo and Bar are both compatible with the referenced object, To be compatible, they have to be the class of the object or a superclass of the object, right? (Have the interface of is like saying it's a superclass for languages that don't have multiple inheritance.) do both $a and $b behave identically? Or can the variable's type influence the behavior of that variable ... This might seem like a silly thing to want to do; Yes. but it seems to me that there are often cases where we want different behaviors in different contexts. There may be cases, yes. Making it the default case is a probably a really bad idea. Hopefully my example above illustrates why. If you are in that case, I imagine you can just do $a.Bar::xxx() or $a.Foo::xxx() to get what you want. ~ John Williams
Re: Variable Types Vs Value Types
[EMAIL PROTECTED] (Dan Sugalski) writes: I am taking the viewpoint that everything is in object. Then you'll likely be somewhat surprised at times. Can you elucidate? -- Halfjack Ah the joys of festival + Gutenburg project. I can now have Moby Dick read to me by Stephen Hawking.
Re: This week's Perl Summary
Paul Kienzle [EMAIL PROTECTED] writes: Piers Cawley wrote: * Thanks to everyone who has given me feedback as a result of these summaries. It's really good to know that people finding these things useful. Me too. I find I no longer read the list because I can pick up the few relevant bits from the summary and follow them up in makeshortlink. Can I just get your summary and drop the rest of the subscription? Just subscribe to [EMAIL PROTECTED] -- Piers
Re: Variable Types Vs Value Types
At 8:43 PM + 1/5/03, Simon Cozens wrote: [EMAIL PROTECTED] (Dan Sugalski) writes: I am taking the viewpoint that everything is in object. Then you'll likely be somewhat surprised at times. Can you elucidate? (I admit to be very tempted to answer this Yes and leave it at that... :) I suppose it depends on what you consider object behaviour. If that definition is I can call methods on it then yeah, I guess everything'll be objects, but even my standards aren't that low, and I don't *do* objects. Things that aren't explicitly objects won't have reference semantics. They won't have attributes. They won't do any of the other dozen or so things objects should do. They will be neither pine fresh nor lemony scented. I can guarantee you that *I* won't be thinking particularly objectly (or objectively, to forestall the obvious rejoinder) about things that aren't objects. An object is a data type, as much as an array or hash is a data type, but that doesn't make an array an object. [insert obligatory all men are Socratese quote here) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
