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 C 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
AW: AW: AW: AW: nag Exegesis 2
> or as useful as:
>
>my DNA %sequence is human size(4) =
>(alpha => 'atgc', beta => 'ctga', gamma => 'aatt',
> delta => 'ccaa'_;
oh , this is damn *PERFECT* !
a) easy reading
b) 'type' and 'property' adjacent without hopping through list
of varnames or complex property-constructs
c) "variable/keys" adjacent to init value
You sold that to me.
Then i could pray to the god of the camel herdsman, that
my DNA human size(4) ($alpha, $beta, $gamma, $delta)
= ('atgc', 'ctga', 'aatt', 'ccaa');
may be activated through perl6 custom parser options 8-) Or even
my DNA human size(4) ($alpha = 'atgc', $beta = 'ctga', $gamma =
'aatt', $delta = 'ccaa')
which i could sell my perl6-beginner classes even easier.
> Perhaps to *your* natural language, but not to mine. :-)
I have a german background. But my litte english-vs-perl6 example sounds
not so odd to me (what doesn't mean to much):
my ( john, james, jim, tony ) are
( 102, 99,88, 79 )
while 'are' stands for '=' and of course the initializing integers
wouldn't match the type 'uncle'.
Thanks for your patience with me,
Murat
Re: AW: AW: AW: AW: nag Exegesis 2
[EMAIL PROTECTED] (Murat Ünalan) writes: > I have a german background. But my litte english-vs-perl6 example sounds > not so odd to me (what doesn't mean to much): > > my ( john, james, jim, tony ) are > ( 102, 99,88, 79 ) Actually, I think this sounds more natural too, but I think it's just a matter of personal taste. And when it comes down to it, the personal taste of the language designers is really all that counts. :) -- "Ah," said Arthur, "this is obviously some strange usage of the word 'safe' that I wasn't previously aware of."
Re: Variable/value vtable split
Mitchell N Charity wrote:
(3) A new reflector/reference class.
void set_integer_native (INTVAL value) {
PMC *object_reflected = SELF->cache.pmc_val;
object_reflected->vtable->set_integer_native(...);
}
Question ONE - What parts of the above code, if any, need to be
changed, simply and solely to address Dan's concern that we are being
"sloppy with variables and values".
You have now just one vtable method. If your reference should work on
all types you have to implement all functions leading to enormous code
duplication.
Please have a look at tt.c add() - no changes needed if the var-vtable
fetches the variable for you.
So a reflector class would just implement the var.get_ and
var.set_ functions - that's all.
Mitchell
leo
Re: GC/DOD feedback & runtime tuning
I'm not willing to go so radically to start, but I did have an idea. I think part of the extra cost is just in cache fluffiness--the sync info just isn't being used much. I don't think that it, or the property info, will be used most of the time. We could yank the metadata and sync fields out of the PMC itself and put them in a separate segment of the PMC's arena, and replace them with a single pointer to the PMC's particular section. It does seem a lot of time is being spent by free_unused_pobjects walking arrays of PMCs (pool arenas) to twiddle flags. An similar alternative might be to yank the gc flags to the head of their arena. It looks like they might even fit in a short. So an arena has an array of flag ints, and a corresponding array of PMCs. The contiguous flags would speed the walk, and _might_ stick in cache enough that the cache miss cost wouldn't just reappear in random PMC access. One would need a fast way to get from a PMC address to its arena address, eg page aligned arenas. Random thought, Mitchell Charity
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 C 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 C 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
[EMAIL PROTECTED] (Dave Whipp) writes: > 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. In which case it makes sense, as I'm sure Larry has said at some point in the past, just to think of the sigils as part of the name. $a[4] and @a[4] do the same thing. If you want to think of $a[4] as doing some dereferencing, feel free. They're both extracting an element from an array object. If a "scalar" variable can hold an array object, then it isn't very "scalar"; the sigils don't have much semantic value. -- As usual, this being a 1.3.x release, I haven't even compiled this kernel yet. So if it works, you should be doubly impressed. (Linus Torvalds, announcing kernel 1.3.3 on the linux-kernel mailing list.)
Re: 'my int( 1..31 ) $var' ?
>> 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 having slept now, the same thought occurs to me ... I think I wasthinking of the user typing "0" to show that they're putting it in in string context ... but then the variable would hold ""0"" ... which seems like it'd solve the problem itself, at that point, since a user defined entity can now /\"\d+\"/ to find out if it's built that way even if it does collapse back to a number >> 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 I should learn not to read/respond when i'm tired :o I was thinking of all the Java & JS I've been doing the last couple weeks. Perl I'd just do "$a$b" and be done with it. >> ... 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. Yeah, since the user would have to in some way dicatate that it was a string value (typing "0" or such), the code will actually receive enough information to build that if the programmer wants it. And I have ZERO idea what I was thinking of as a "useful case" ... But since it is user-garnerable information, and no cases are springing to mind, I retract my earlier comments and say that it might be interesting in some case, but in the same case it is feasible to simply allow the programmer to generate it rather than killing ops generating it automatically ... --attriel (I'll quit posting just before I go to bed now :o)
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: Object semantics
At 6:56 PM +0530 1/4/03, Gopal V wrote:
If memory serves me right, Erik Bågfors wrote:
> >> would a be able to modify itself ? (unfortunately C# allows that)
> >
To clarify here's my example ...
=cut
using System;
public struct MyStruct
{
int val;
public MyStruct(int x){ val=x; }
public void Modify(){ val=42; }
public override String ToString(){ return val.ToString(); }
}
public class FooBar
{
public static void Main()
{
MyStruct m1=new MyStruct(10);
MyStruct m2=m1;
m1.Modify();
Console.WriteLine(m1);
Console.WriteLine(m2);
}
}
=end cut
Which gives
42
10
If in anycase Parrot wants to avoid this , we could always add a special
case to the ILNode_Assign to generate an explicit copy step in parrot for
valuetypes...
Why would we want to avoid this? It looks exactly like what ought to happen.
--
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: Object semantics
> At 6:56 PM +0530 1/4/03, Gopal V wrote:
>>If memory serves me right, Erik Bågfors wrote:
>>> > >> would a be able to modify itself ? (unfortunately C# allows
>>> that)
>>> > >
>>
>>To clarify here's my example ...
>>
>>=cut
>>
>>using System;
>>public struct MyStruct
>>{
>> int val;
>> public MyStruct(int x){ val=x; }
>> public void Modify(){ val=42; }
>> public override String ToString(){ return val.ToString(); }
>>}
>>public class FooBar
>>{
>> public static void Main()
>> {
>> MyStruct m1=new MyStruct(10);
>> MyStruct m2=m1;
>> m1.Modify();
>> Console.WriteLine(m1);
>> Console.WriteLine(m2);
>> }
>>}
>>
>>=end cut
>>
>>Which gives
>>
>>42
>>10
>>
>>If in anycase Parrot wants to avoid this , we could always add a
>> special case to the ILNode_Assign to generate an explicit copy step in
>> parrot for valuetypes...
>
> Why would we want to avoid this? It looks exactly like what ought to
> happen.
I think he was explaining what he meant in another post that someone
questioned, with this example; then the "wants to avoid this" referred to
"avoiding the easy-path error of NOT doing this". I think Gopal was
saying that C#/NET does it that way, and I can't imagine him asking to
have functionality he explicitly needs to be "carefully avoided" :)
OTOH, I may have misread a bunch of things, I'm not doing so hot on my
interpretations the last few days :o
--attriel
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? -- 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
Re: Object semantics
At 3:29 PM -0500 1/5/03, attriel wrote:
> At 6:56 PM +0530 1/4/03, Gopal V wrote:
If memory serves me right, Erik Bågfors wrote:
> >> would a be able to modify itself ? (unfortunately C# allows
that)
> >
To clarify here's my example ...
=cut
using System;
public struct MyStruct
{
int val;
public MyStruct(int x){ val=x; }
public void Modify(){ val=42; }
public override String ToString(){ return val.ToString(); }
}
public class FooBar
{
public static void Main()
{
MyStruct m1=new MyStruct(10);
MyStruct m2=m1;
m1.Modify();
Console.WriteLine(m1);
Console.WriteLine(m2);
}
}
=end cut
Which gives
42
10
If in anycase Parrot wants to avoid this , we could always add a
special case to the ILNode_Assign to generate an explicit copy step in
parrot for valuetypes...
Why would we want to avoid this? It looks exactly like what ought to
happen.
I think he was explaining what he meant in another post that someone
questioned, with this example; then the "wants to avoid this" referred to
"avoiding the easy-path error of NOT doing this". I think Gopal was
saying that C#/NET does it that way, and I can't imagine him asking to
have functionality he explicitly needs to be "carefully avoided" :)
Just because C# does it doesn't mean that he likes it. :)
--
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: Object semantics
If memory serves me right, Dan Sugalski wrote: > >> Why would we want to avoid this? It looks exactly like what ought to > >> happen. If you can provide that in-vm , it would be a lot faster ...(hmm, that's one argument that should convince you ;) But like I said , I need lots of sticky notes for all the opcodes for parrot ...(I'm still in "can't remember all opcodes" mode) > Just because C# does it doesn't mean that he likes it. :) To end all further debate -- *) C# has something like this , *) I can't see what Dan has in head for parrot , *) I don't want feature creep into parrot *) Our C# -> JVM compiler already has the workarounds for this like: invokestatic "MyStruct" "copyIn__" "(LMyStruct;)LMyStruct;" *) I really don't like valuetypes that much :). *) Rhys will be doing most of the design , this is his headache actually :-) So does that cover all bases ? Gopal -- The difference between insanity and genius is measured by success
