Re: Apocalypses and Exegesis...
> Apocalypses and Exegesis are not an 'official' specification for Perl6, > I mean, they are subject to change. Is there any idea when will we have > a freeze on the syntax and features for perl6? Since the A/E gig is where the design team is getting a handle on what it is they want to be doing and how (and then trying to explain it to the rest of us using small words :), I think they won't freeze anything until they're much further along on the series OTOH, I think they aren't planning to make sweeping changes to whats there already and most of it can be considered 'slushy', which may not be as good as frozen, but it's closer :o That's my take on it, of course; I could be entirely wrong, too --attriel
Re: Perl 6's for() signature
> Anyone but me feel the need for non-greedy slurpy arrays? similar to
> non-greedy RE matches?
> Then we could do:
>
> sub for ([EMAIL PROTECTED], &block) {...}
>
> Proposed behavior of *?@ : All Arguement to Parameter mapping left of it
> are processed Left to Right. Once seen, the mapping starts over right to
> left. Everything remaining is slurpable.
With obvious restrictions on "no other slurpy/semi-slurpy arrays" in the
param list, b/c that would make things go insane, IMHO. Although, I guess
with typing, you could do splits on the typed params between, and assuming
there was no ambiguity ...
Ow, my head hurts now :o
--attriel
Re: Objects, methods, attributes, properties, and other related frobnitzes
>>Just to confuse things more, there is a question I have reguarding >> multi-methods and inheritance. >> >>Consider class A defines foo() as a multi-method with 3 different >> signatures >> >>If class B then sub-classes A and defines a method foo() does it >> >>1 override all foo() methods in A >>2 get added to the foo() methods in the dispatch, so we now have >> a multi-method with 4 signatures >>3 override only the method in A that has the same signature >> >>My guess would be (1) and that multi-method distpatch would >>only happen if B called ->SUPER::foo >> >>In which case you could consider that there is only one method >>named foo(). That method does the dispatch to the others. > > D'oh! That's a good question--I'll ask in a few minutes and find out. -- Based on normal OO behaviour, I would assume (3) (which is the same as (2) if there's no override). the ->SUPER::foo would be called to invoke the overridden/shadowed version of that signature ... I would also think that'd be easiest on the parrot, since then it just has to look for the first thing that matches the signature in all cases, rather than having logic that checks to see if it needs to invoke the multimethod logic ... I guess it might slowdown if the override is handled as a multimethod that goes to the new or callst he next level's multi, instead of sucking it down and collapsing it for one giant multi ... --attriel
Re: newline as statement terminator
>> I don't mean to be abrupt here, especially seeing as how this list has
>> been so patient with some of my ideas but... PLEASE NO. The rules you
>> suggest for keeping track of when a semicolon is required sound more
>> confusing than the simple rule of "end of statement, put semicolon".
>
> As Luke Palmer said, in perl6, semicolon is a statement separator not a
> statement terminator. So there is no such simple rule in Perl but you
> are free to imposit it on yourself. Perl allows it but it does not
> requires it.
Er. What is the difference between a "statement seperator" and a
"statement terminator" for the majority case?
Seperator means I can leave off the last one in a {} b/c there's no
following statement ... But is there any other place I can "optionalize"
the ; by calling it a seperator vs a terminator?
I like having ;'s at the end of my bits, b/c then I know where a line
ends. When someone's pasting me bad (and I mean BAD) perl5 code, I like
having those ;'s there to tell me what ended where, since (The case i'm
thinking of offhand) was doing a print qq|| that printed out a BUNCH of
things and then ended with an if .. that ; was important b/c I kept
thinking hte if was part of the next line (it was on a seperate line,
making it even more fun)
Yes, this would make that program entirely not work, but I'm sure the new
version wouldn't be much prettier since there'd be no ;s at all
>> I like to break up my long statements in all sorts of arbitrary
>> places, and adding the worries of when a newline might be significant
>> puts a knot in my stomach just thinking about it (literally).
>
> I agree that be obliged to check the next line to see if the newline is
> or is not a statement terminator is not the nicest thing.
lookahead parsing is tolerable in a compiler, but in an interpreted/jit
environment, I'd HATE for my code to change meaning b/c i forgot a \n ...
esp if it's in generated code ... e
> On the other hand, if the programmer is correctly indenting the program
> it should stand out that the next line is part of the courant statement.
>
>
> print "---" # must read the next line to
> # figure out if new line is statement terminator or
>if $condition";
>
>
> Here indentation is a mere clue but has no syntactic meaning.
So, is the indentation required as a parser-hint (ewww, I hated mandatory
indents in fortran, and I can't see any good reason to bring them back;
stylistically I still think they're mandated, but not dictated by the
language) or is it just there to help people ?
And why is there a "; there? i presume the " is a typo, but since this
whole discussion is getting rid of the ;, I cna't see why it's there ...
Summary: ;'s good, indentation necessary but not parser-graphically
dicatated :o
--attriel
(parsergraphically?)
Re: Arrays: Default Values
> Solution 1: If you attempt to SET a cell to it's 'empty value', it
> will be set to it's default:
>
> my int @a is default(5); #
> @a[5] = 0;# actually sets it to it's 'empty value',
>
> 5
> @a[5] = undef;# autocnv to 0, + warning, still sets to
> 5
>
> my Int @a is default(5); # NOTE difference in type!
> @a[5] = 0;# THIS really does set it to 0
> @a[5] = undef;# and this sets it to 5
>
> So you can't set something to its type's own empty value, because it
> will, by definition, thereafter return it's "overloaded" empty value,
> .
> -
>
> In spite of the perhaps surprising nature of solution 1, I think it is
> probably the more correct solution, if you really insist on putting a
> default value on a primitive-typed array. As it points out, you can
> still get both behaviors, simply by choosing int vs. Int, str vs. Str,
> etc.
OK, it sounds reasonable to me, for those cases where the 'empty value' is
undef ...
but if I have an array of #s ...
I have the list of people I invited to my wedding.
I default the # of people attending to 2 (inviting couples or "& Friend") ...
Joe responds, he's coming alone (ok, so i set him to a 1)
Karen is bringing her kids (so 4)
Fred can't come. That's a 0. Which is a 2. But he's not coming, so the
2 is really a 0, but I can't say 0, b/c 0 is "empty" and becomes "default"
2 ...
Likewise for strings. I default it to explicitly say "UNKNOWN" so I know
what's not known, but now when I find out it doesn't exist ("What's John
Doe's middle name?") I can't say that. The answer then is "UNKNOWN" so
"John Doe" became "John UNKNOWN Doe" due to a flawed (IMO) functional
limitation ...
This is also why i (somewhat facetiously) suggested "undef but really",
although it doesn't help in this case b/c I'm wanting to set it to 0, and
saying "attendees[23] = 0 but really" looks wrong ... so maybe the "but
really" would be for setting to default ('empty value') if you had need
and used it in assignment (but undef @attendees[23] would, i think, still
make it 'empty val' b/c i'm not assigning a value to it, i'm unassigning
the value I've given it, which is a distinction that I think may be
relevant ...)
--attriel
Re: Arrays: Default Values
So ... with the discussion of "what if i really wanted to put an undef in there b/c it's not just that i haven't defined it but rather that it really isn't defined. I KNOW it's not defined, and i'm now explicitly saying it's undefined as opposed to before when i was implicitly suggesting that i didn't know what it was and used a default 'unknown'" discussion ... What we really need is: @a[2] = undef but undef; or, possibly (more tongue-in-cheek-y) @a[2] = undef but seriously; so the ... property? would say "you have a default, maybe, but i don't care. this is REALLY undef" is that possible? aside from it being disturbing to write "undef but undef" :o --attriel (the first suggestion is serious, but the syntax is flawed; the second suggestion has better syntax but is tongue-in-cheek suggested ... )
RE: Objects, finally (try 1)
> Perhaps I'm misunderstanding Dan's meaning when he talks of invalidating
> method handles. In Perl5:
>
> package Foo;
> sub bar { print "hello world\n" }
> package main;
> my $cref = Foo->can('bar');
> undef *Foo::bar;
> Foo->$cref();
> Foo->bar();
> 1;
>
> would result in:
>
> hello world
> Can't locate object method "bar" via package "Foo" (perhaps you forgot
> to load "
> Foo"?) at [...] line 7.
>
> As you can see, this is something you can do this in Perl5. And as Perl6
> is supposed to be able to run Perl5... I'd think this'd be something
> parrot'd be required to support.
Hrrm. I didn't know that case worked :o
I guess then that we'd be returning a code-object and calling the (nifty
new) compile opcode on it when we wanted to actually run it ... from what
I understood of Dan's last reply, though, we're getting "yes/no" and this
entire subtree got pruned :o
I guess we'd be, effectively, looking at ref counters (like with memptrs
and GC), so we can say "oh, we deleted that, but I have this reference, so
I'll invalidate the real call, but leave it there so the ref works",
effectively like hard links on unix, i guess ...
Would that work as an option to resolve it? I don't know the memory or
data-store values (especially not of objects that are still just words :o)
but would it be possible to keep a refcount for the items, set at 1 (b/c
it's defined :) and then if someone does a can() we increment it until the
$val that can() went into either gets undef'd, descoped, or otherwise
loses it's reference? (those two are static events, I think, and $var
could just tell it's ref that it's going away, quit counting me ... )
random mumblings that I don't really understand how they'd work in parrot:
If we have a FPtr PMC, and we provide it as a return to can(), after
incrementing the internal refcount ...
Then on an "undef *Foo::bar;" it invalidates the name in the PMC (and
Foo's meth tables?) and decreases it's refcount ...
Then set whatever kinds of traps (I guess they'd be compiler level) so
that whenever the value of the $var that took the result of can() is
changed, it decrements the refcount ... I think that's compiler level, so
it just takes longer to compile, while it tosses in the extra opcodes for
decrements ...
and then if the refcount == 0 we just mark it for GC and forget about it
entirely ...
Like i said, no idea how all that ACTUALLY works out in parrot, though :o
--attriel
RE: Objects, finally (try 1)
>> > >I think what Jonathan asked for was an operator for >> > >returning a method (as an object) which can be invoked >> > >later with some arguments (or even applied with a >> > >partial list of arguments for currying). >> > > >> > >This would be a lot more useful than a yes-or-no >> > >answer about the existence of a method. > > Exactly. 'Yes' might be valid one moment, and invalid the next. Not a > very useful operation... Returning a coderef on the other hand is > useful. Er. How could "Is it possible to call this method" become invalid, but the fptr remains valid? I'm not sure that I follow that ... > I don't see it as a problem. In Perl5, you get back a coderef. And > despite whether the method is modified or removed from the class in the > meantime, that code reference is still valid. I think the issue is that Perl is interpreting things, whereas the parrot would be quoting back actual memory locations saying "ok, this is RIGHT HERE. when you want to do it, go RIGHT HERE" and then we up and moved "here" to "there" and all hell breaks loose when I try to "callmethod" on a pure number :o Although, I guess Parrot could still be doing memory management at the VM level and the PASM would still be getting lookup refs instead of actual physical pointers, at which case I'm not sure I see the problem ... I guess if "who's 'foo()' am I calling" is determined by some property of the object, then it's possible to get a fptr P to function F from object O at time T, do stuff with O (some of which might cause P' to be the proper F fptr instead of P), and then calling P is no longer "legitimate" ... But I'm not entirely convinced that's not the coder's problem, since that would, imo, be a side-effect of whatever calls were made between "can" and "call", which means either (a) they're documented properly and the coder missed that step and forgot to get a new P for F (making P <- P') or (b) it's NOT documented, at which point it's still the coder's error, just a different coder :) since the side-effect is important and (possibly) break-a-licious ... --attriel (so, at the level we're talking about right now, are we getting fptr P as a memory location that has the function and we want to jump there (or has the function ref, etc); or is P a ref that parrot will then look up in the object and dig up the right answer (but has already done some level of lookup to make this lookup easy; we've already found where it is in the object the first time; now I have to find out where that is in memory/load that into memory and call it)
Re: Objects, finally (try 1)
> Dan: >> Yep. There should be a can operator, though I'm not sure how often one >> wants to check for the existence of a method in an object without >> calling it. But no reason not to. More for rev 2. Adriano: > I think what Jonathan asked for was an operator for returning a method > (as an object) > which can be invoked later with some arguments (or even applied with a > partial list > of arguments for currying). > This would be a lot more useful than a yes-or-no answer about the > existence of a method. I think just knowing it exists would be useful (ala java's "reflection") since you might want to know if it exists in order to do some set of calculations before calling it, since if it doesn't exist there's a better/different set of calcs you need to do that have no use for the first set. I also like currying functions, which I can see kindof wanting the funcall pointer (although ... would it also need some way of garnering what the parameterlist (quantity or types) is?) ... Luckily the former (yes/no) can be easily inferred from the latter (funcall ptr) simply by "if the pointer is null, that'd be a no" :) although, with the parameter info that may be encapsulated and returned in some way with the fptr (if any is returned, that is), it might also be beneficial to have a seperate opcode for "just tell me if it exists", depending on how much overhead the fptr & param-info incurs ... Short version: I think both are good. Yes/No is inferrable from a pointer, but if the pointer has to include other information (and thus be a full PMC or however, precisely) seperate might be good. --attriel
Re: Objects, finally (try 1)
> On Thu, 9 Jan 2003 16:40:20 -0500, Dan Sugalski wrote: >> #10 We do MI, but we don't instantiate a class' attributes multiple >> times if its in the hierarchy for a class more than once. If it is, >> the leftmost instance is real, the rest are virtual My only question here is: What is leftmost? Is that the same as "closest to the actual class we're looking at" or is it "first time it appears in the inheritance structure, and thus the furthest from the relevant class" ? (or something else entirely?) > This will mean we can't support Eiffel, which allows repeated real > inheritance of the same class. It does this by allowing renaming at the > feature level (thats attributes and methods in perl) when inheritance is > declared. Repeated inherited features are shared if they keep the same > name (and they really are the same feature), or split if they don't. I'll admit to never having gotten to looking at eiffel, just hearing about it from some other folks ... But what is the point of explicitly inheriting from the same class multiple times? I mean, sure, if it's in the inheritance tree multiple times, fine, but then you ignore most of them generally; what benefit/use comes from having it actually be in the tree multiple times as distinct entities? I'm just wondering there ... But if it's renaming the structure anyway, wouldn't it still be possible with the single-MI structure that dan proposed? as in, if B inherits from A and then C inherits from A and B directly (and assuming there's a need to separately retain the individual inheritance directions), wouldn't the compiler then say that B inherits from A and C inherits from A2 and B, to retain them both in the parrot? --attriel (I could, of course, be horribly wrong, had I stated a firm opinion rather than requests for more information :)
Re: L2R/R2L syntax (was Re: Everything is an object.)
> print sort { ... } <~ mymethod(42) <~ @b;
>
> call sort on what comezouta calling mymethod(42) on what comezouta @b.
> I think. Indirect objects are still somewhat confusing. :)
>
> If I'm reading the info right on <~, then we want to make it clear
> that you _don't_ put it between print and stuff you want to print, or
> in other words that "this ain't cout".
If I read the conversations right, I think that line is trying to do:
print (to stream mymethod(@b,42)) sort { ... }
I think to make it work like you wanted, you need ()'s
print (sort { ... } <~ mymethod(42) <~ @b); so that the <~ is directly
associated with the sort; otherwise sort is a param to the print, and
we're comezouta'ing the "where do i print sort"
and sort takes the "how do i sort" first and the "What do i sort"
second, yes? which makes me now wonder about all the sort { ... } <~
examples, and my understanding of the whole "where do <~ and ~> stick
things?" thing ...
OK, looking back, <~ binds to the "indirect object" ... and Damian's
examples use map { ... } and grep { ... } with <~'s, so I guess the
indirect object would work the same for sort { ... }, but now I'm not real
sure on what the indirect object IS in all these calls ...
Could someone explain how to know what's the indirect object? (who knew
the "sentence diagramming" would be USEFUL!!)
--attriel
Re: L2R/R2L syntax (was Re: Everything is an object.)
>> I'm just suggesting the same for the ~ character:
>>
>> ~~ smart-match
>> ~concatenate
>> ~| stringy bitwise OR
>> ~> append args
>> <~ invocate
>
> This is where I get lost. I see 4 different concepts being overloaded
> onto '~'.
>
> In the first it indicates 'match' just as it always has for =~ and !~.
> In the second, it is being used for concatentation - nothing to do with
> matching. In the third it is being used to cast stringwisely - nothing
> to do with matching or concatenation. In the fourth and fifth it is
> being used to re-order arguments - nothing to do with matching,
> concatenation (well, possibly concatenation of argument lists) or
> stringwise casting.
Well, I always used =~ // for strings, and (from what I gather) ~~ is the
uber =~ in that it can figure out types and meaningfully guess what
"matches" means, so I see the first 3 as "string toys", just as the -- -
and -= were all "subtraction"
I'll give you that ~> and <~ don't do stringy things, though :) But I
think they'd be read, once it's more than theories in email messages ;o,
as single ops (like the ->) rather than "squiggly and arrow" it'd be
"squigglyarrow" ... I think the major concern would, to me, be that ~> and
-> are kinda close, visually, and I imagine nearly indistinguishable in
some fonts :/
> I would like to see '~' kept for matching and just matching. It is well
> known in this role and is analogous to the "roughly equals" operator in
> the Real World (extended ASCII character 247 - just don't ask me to type
> it).
Now you've given them ideas :) we're all gonna be typing ≈ (OK, so,
all I can get is that it's unicode 2248; still haven't figured out how to
ACTUALLY type it :o Alt-247() seems to be the wrong character though and
I don' see it anywhere on my HTML ascii chart :/
> I also think '_' should be used for concatenation because it's in
> keeping with the existing use of 123_456.
That actually reads like _ is a null character "This is not the character
you are looking for. There is no character, there is only zool" kinda
thing ... I know it's concat, but it reads more like a "visual separation
character that is COMPLETELY ignored by the parser, except insofar as to
explicitly ignore it"
> As a prefix character to indicate stringwise (numberwise, bitwise, etc)
> casting, can we not use a single character prefix, e.g. 's' for string,
> 'n' for number, 'b' for bitwise, 'v' for 'vector', and so on?
>
>$a s| $b;# stringwise
>$a b| $b;# bitwise
>$a n| $b;# numberwise
>@a v| @b;# vector
>@a vsn| @b; # vector stringwise bitwise
I think this was brought up during the operators thread (I admit, I only
skimmed it ... I had 6 or 7 versions in my inbox when I got to it :/) and
the "against"s pointed out that it would mandate whitespace separation
(although, some of the coders I know could live with some mandatory style
guidelines, ugh) ...
>> I mean, compare:
>> @a ~> grep {...} ~> map {...} ~> sort ~> @a;
>> with:
>> @a |> grep {...} |> map {...} |> sort |> @a;
>>
>> I don't know about *your* font, but in mine the ~> and <~ versions are
>> at least twice as readable as the |> and <| ones.
>
> In my font, or perhaps more importantly, to my eye, the |> and |< are
> more readable. But regardless, I think it's more important to make the
To me, for some reason, |> reads as a forward gate "Do not continue unless
the previous item was true; if it was, feed the result here" ... <|
doesn't read like much, and |< looks like some 1337 h4xx0r trying to be
cool, honestly :o It just looks broken! As an op, I would expect it to
translate to "OR Less Than" and I can't come up with how to use that "$a
== 7 |< 200" I guess :o
And would the consistency rules require them to be:
~> ~< ? so that the ops look similar? (If so, I'm gonna vote that ~<
looks like a fish and is just weird :)
--attriel
Re: Variable Types Vs Value Types
> my Set of Apple $a; > my Basket of Fruit $b; > > and a generic assignment: > > $c = $a; > $c = $b; > > Now we can fill in your list (which is somewhat expanded): > AssignmentOK?Because... ======== my Basket $c = $a no $c's type: Basket (of Object) X ^ | | $a's type: Set of Apple my Basket of Apple $c = $aok $c's type: Basket of Apple ^ ^ | | $a's type: Basket of Apple Now, just to be sure I didn't miss a step: That second entry is wrong, sin't it? it should be OK? no b/c: C's Type : Basket of Apple X^ || A's Type : Set of Apple yes? (I'm trying to make sure I didn't miss a majikal mystery conversion step that seems contradictory but somehow exists anyway :o) --attriel
RE: L2R/R2L syntax (was Re: Everything is an object.)
Note 1) This is the second time I'm typing this Note 2) Ctrl-Shift-Capslock apparently closes all current instances of mozilla ... that was weird > I'm not even sure how that would parse, though that: > @keep <~ grep /good/ <~ @list ~> grep /bad!/ ~> @throw; > would go like: > ( @keep <~ grep /good/ <~ @list ) ~> grep /bad!/ ~> @throw; > > which is probably not what i wanted... I would, from the descriptions, imagine that: @keep <~ grep /good/ <~ @list ~> grep /bad!/ ~> @throw; Would parse as: @keep <~ grep /good/ <~ @list; @list ~> grep /bad!/ ~> @throw; Due to that being what is almost always going to be intended, I think. Also, since we'd want $a <~ 2 + 4; to be $a = 6;, I would imagine that <~ and ~> would need low priorities. Further, since <~ stars at the end of the list and works its way left, it would need a lower priority than ~> which starts at the beginning and works its way right. So if it did have a parenthetical variation, I would imagine it would be @keep <~ grep /good/ <~ (@list ~> grep /bad!/ ~> @throw); Which is, still, probably not what you wanted. OTOH, I'm still new at posting here, and I may not be following all the bits that came before :o --attriel
RE: L2R/R2L syntax (was Re: Everything is an object.)
>>(b) Can <~ and ~> be used at the same time? >> >>I'm not entirely sure of what functions take two array params >>meaningfully, but could we do: > > Damian's proposal didn't say anything about array params. If I > understood him correctly, then this should print "FOO" on standard out: DOH! All the examples were using @'s, and somehow that translated to "this is an array opthingy" :o > $foo ~> print <~ STDERR; That makes a fair amount of sense (and certainly more than any of my array-based flawed examples :) Thanks for clearing up my fogginess :o --attriel
Re: L2R/R2L syntax (was Re: Everything is an object.)
> Can I suggest that an alternative solution might be the following:
>
> Suppose Perl 6 had two new very low precedence operators: ~> and <~
> (a.k.a. "bind rightwards" and "bind leftwards")
>
> @out = @a ~> grep {...} ~> map {...} ~> sort;
>
> @out = sort <~ map {...} <~ grep {...} <~ @a;
>
> That way, everything is still a method call, the ultra-low precedence of
> <~ and ~> eliminate the need for parens, and (best of all) the
> expressions actually *look* like processing sequences.
(a) OOh, shiny!
(b) Can <~ and ~> be used at the same time?
I'm not entirely sure of what functions take two array params
meaningfully, but could we do:
@a ~> grep (...) ~> sort ~> for <~ map (...) <~ @b {
(for content goes here)
}
With the understanding that
(1) EWWW, that is horribly ugly, but it was the first thing I could come
up with that meaningfully takes two list args
(2) Anyone who ACTUALLY does this with a for be shot on sight?
It would be more meaningful in another function that takes two lists and
does something useful, but without a body block ... More of a
@a ~> grep (...) ~> apply <~ sort <~ @b ;
So that the grep'd elements of @a are applied, 1:1, to the sorted @b ... ala
apply (grep (..., @a), sort(@b));
(again, more useful for a longer chain)
--attriel
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: '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: 'my int( 1..31 ) $var' ?
>> print "date" if $var.isa(int); >> print "date" if isa $var: int; >> print "date" if $var ~~ int; >> >> Those should all work. IMO the first reads the best. That will also >> work for Cs, as C is a subclass of C (I think). > > These only determine if $var is of type int or Int. However: > > my $var = 0; > # or my $var = "0"; > # or my int $var = 0; > # or my num $var = 0; > > # all 4 cases should print "is integer" > print "is integer" if int $var == $var; > > This should work as a more generic method to test Integer *value*, > rather than type, which IMHO is more useful (and more commonly wanted). 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. 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. 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 ' since if I 'string1 + string2' I get integer addition and end up with a single number 245, or '"" + string1 + string2' becomes the string "245". I've come to accept it, and I realize that 'var-typed(string1) + var-typed(string2)' takes more characters, looks uglier, and is generally more annoying in all ways for that problem, but I imagine there might exist cases where the information is useful ... I suppose it could be stored at input time as a ... variable property (?) that the program sets, but once it's read, I'm not sure the information exists in any meeans to produce the information FOR the property, so it would have to be set in the input functions themselves ... Admittedly, the value-type is goin to be more interesting in a large majority of the cases, so it probably SHOULD continue being the default low-effort result ... I had a point. I think I made it in there. --attriel
Re: AW: AW: AW: nag Exegesis 2
> (1)
>
> my size(4), human DNA ($alpha, $beta, $gamma, $delta ) = ( 'atgc',
> 'ctga', 'aatt', 'ccaa' );
>
> is so perfect, vs
>
> (2)
>
> my DNA ($alpha, $beta, $gamma, $delta) is human, size(4) = ( 'atgc',
> 'ctga', 'aatt', 'ccaa' );
If I were concerned about this, I would either do it the way Damian
suggests
my DNA ($alpha, $beta, $gamma, $delta) is human size(4)
= ('atgc', 'ctga', 'aatt', 'ccaa');
Or I would just make it two lines:
my DNA ($alpha, $beta, $gamma, $delta) is human size(4);
($alpha, $beta, $gamma, $delta) = ('atgc', 'ctga', 'aatt', 'ccaa');
And then expect the compiler to do precisely the same thing. The
benefit I find in the second case is that I can now move it somewhere
else and have separate declarations and initializations.
the example in (1) looks like it's beind declared as a "size(4)" , with
"human" and "DNA" being somehow modifiers on "size(4)" (admittedly, if
it were the stated style, people would be expected to understand it, but
it would still be counterintuitive, IMO)
--attriel
