t 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
.. 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
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)
..
>
> 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
... 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
ly, 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
ably 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
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
on, |> 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
... } 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
gle-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
ram-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
d 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 prop
he 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
lt, 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 ... )
,
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
hink 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?)
ok 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
params between, and assuming
there was no ambiguity ...
Ow, my head hurts now :o
--attriel
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
20 matches
Mail list logo
