On Tue, Dec 10, 2002 at 10:37:10PM -0700, Luke Palmer wrote:
> Why use regexen when you can just use junctions?
>
> my $foos = 'foo' ~ any(0..9) ~ any(0..9);
At what moment does a junction actually create all of its states?
Hmm...perhaps a clearer way to say that is "At what moment does a
ju
-ness
(I use the latter frequently: but I write a lot of code for testing and
debugging -- its my job). So perhaps the C<===> operator could
be used for comparison under the default equivalence-class of the
operands. I'd find it unintuitive, but I'm could get used to it.
Dave.
s all the other parts of
the language. Sometimes people seem to think that the only alternative
is to add built-ins: but this really shouldn't be the case -- not in a
language as powerful as Perl6.
Dave.
ative:
just
explaining why we keep proposing built-ins instead of using the methods
on objects.
Dave.
On Wed, Dec 11, 2002 at 12:13:49PM -0700, Luke Palmer wrote:
> [Dks wrote:]
> > So...are we intending that types and type safety will be like 'use
> > strict' (optional and only on request), or will they be like sigils
> > (mandatory, can't be turned off)? Or, perhaps, on by default but able
> >
On Thu, Dec 12, 2002 at 10:35:47AM +1100, Damian Conway wrote:
> Dave Storrs wrote:
> > - the ability for the programmer to set "limiters" (??better name??)
> > on the junction, which will specify how the junction should
> > collapse--e.g. always collapse to the l
On Wed, Dec 11, 2002 at 02:54:18PM -0800, Dave Whipp wrote:
> "Michael Lazzaro" <[EMAIL PROTECTED]> wrote:
> > After thinking about it a little more, I'll set myself on the "yes"
> > side. And propose either '===' or ':=:'
... [ time passes ] ...
if $an_object.id == $remembered_id { ... }
If memory addresses can change over time, then we
need a more fundamental concept to act as the ID!
Dave.
header stays constant.
> This is to minimize the insanity of pointer chasing in C.
The address may be constant for the life of the process: but some
objects persist a bit longer. These cases can probably be covered
by a C<.guid> method. Is this method a member of C,
or only of C?
Dave.
ct.
Brent indicated that he could think of no reason for the "header
address" to change: but that isn't strong enough. We need a cast-
iron guarantee. Otherwise we can't compare identity using .id.
Dave.
On Thu, Dec 12, 2002 at 09:39:18PM -0500, James Mastros wrote:
> On 12/12/2002 8:07 PM, Larry Wall wrote:
> > Ordinarily you'd test for subs with one of
> >
> > exists &Main::foo
> > &Main::foo.exists
> I thought that was now spelt exists %Main::{&foo} -- that the symbol
> tables were now
On Fri, Dec 13, 2002 at 09:56:15AM -0500, John Siracusa wrote:
> Using the method/attribute named "id" for "this is the same object"
> comparisons is just plain bad Huffman coding. The "this is the same object"
> method/attribute should have a name that reflects the relative rarity of its
> use.
On Fri, Dec 13, 2002 at 09:49:44AM -0600, Garrett Goebel wrote:
> Other common names for the proposed .id are:
>
> UUID: Universal Unique Identifier (DCE)
> GUID: Globally Unique Identfier (EFI)
>
> Of the 2, usage of "GUID" seems to be more common IMHO. Both of the above
> are identical in imple
On Fri, Dec 13, 2002 at 09:32:02AM -0800, Michael Lazzaro wrote:
>
> $obj.ID;
> $obj.IDENTITY;
FWIW, I favor the latter.
--Dks
On Mon, Dec 16, 2002 at 06:47:39PM +, Piers Cawley wrote:
> Michael Lazzaro <[EMAIL PROTECTED]> writes:
>
> > Mind you (purely devil's advocate), I'm not entirely sure the R-to-L
> > syntax truly _needs_ to be in Perl6. It's true I use it all the time,
> > but I can retrain to use L-to-R meth
t is the lack of symmetry. Is there any reason why
an adverb syntax can't work:
$a eq : ID $b # yes, I would want to generalize that
This infix style might separate the operands visually. So perhaps
eq:ID($a, $b)
Dave.
$a eq:w $b # compare, ignore whitespace differences
$a eq:ID $b # compare identities
I think that the modifier concept is too useful to be limited to the
rx// operator. But there is the issue of passing parameters to
modifiers. I could live with a restriction that forces me to use
the prefix (cf infix) form of the modified operator.
Dave.
On Mon, Dec 16, 2002 at 08:26:25PM +, Piers Cawley wrote:
> Dave Storrs <[EMAIL PROTECTED]> writes:
> > On Mon, Dec 16, 2002 at 06:47:39PM +, Piers Cawley wrote:
> >> Michael Lazzaro <[EMAIL PROTECTED]> writes:
> I haven't been arguing against his syn
On Mon, Dec 16, 2002 at 03:44:21PM -0500, Dan Sugalski wrote:
> At 11:12 AM -0800 12/16/02, Dave Storrs wrote:
> >You find R2L easier to read, I find L2R
> >easier. TIMTOWDI. Perl6 should be smart enough to support both.
>
> Why?
>
> Yes, technically we can do bo
On Wed, Dec 18, 2002 at 09:31:41AM +, Piers Cawley wrote:
> Dave Storrs <[EMAIL PROTECTED]> writes:
> > It seems like Perl6 is moving farther and farther away from Perl5's
> > (almost) typelessness.
>
> It depends what you mean by typed. Perl has always had
Attribution lists are getting a bit complex. This is in response to what Piers wrote
on Wed, Dec 18, 2002 at 03:50:44PM +.
DKS
> > [specifying types]
> > Hm. I'm way short on sleep today, so I'm probably missing something,
> > but I don't see why Perl can't sort this out without a specific
estion: can I use C inside a
recursive implementation of the iterator?)
Dave.
CHSIZE + $b.sum;
and prints 9.
We don't need the variable-type magic, of course. We could have just said
print @a + @a.sum;
and gotten the same result. But the ability to express the behaviour of
variables, independently of values, could be useful (and more powerful
than a c).
Dave.
s 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.
is a primitive "array" type that is promoted to an
objectified Array class when needed. This would be analogous
to the int/Int distinction for primitive numbers. This would be
visible to programmers, but may be acceptable for the same
reason as the int/Int types are.
Of course, it's up to Dan to clarify his own intent: these are just
my opinions.
Dave.
y.new(1,2,3); # calls MyArray.new(Array)
print int(@c); # calls MyArray.new()
This could easily be extended to Scalars: we could autovivify on
first use of an uninitialized variable. The default Scalar class's
.new method would create an undef value; but other classes could
do something
arentheses:
@a = 1, 2, 3; # newbie error
@a <~ 1, 2, 3; # would work
Something else springs to mind. Consider the C syntax:
for 1,2,3 ~> foo -> $a { ... }
Is there any way we could unify these two operators without creating
ambiguities? If we
could, then using straight arrows would be nicer to type than the squiggly
ones.
Dave.
gt; is an L2R pipe into a
block: not an anonymous sub composer. Similarly, the C function is
a strange thing sends its elements down the pipe, one-by-one -- its not
a loop at afterall! (A junction, in contrast, would send its elements down
the pipe in random order, or concurrently).
Dave.
p.s. has Larry finished with those LoTR DVDs yet?
v, helping perl5 people. Ah, well. :-/
Not exactly equivalent: C would have a higher precedence than ->:
Dave.
for 1,2,3 -> { print };
would naturally behave correctly. But by defining a special type of
sequentially distributed junction, we can do all sorts of clever (and
therefore nasty) things.
Dave.
--
mailto:[EMAIL PROTECTED]; http://dave.whipp.name
ave them like so: [...]
I wasn't thinking of a sacrifice: just an adjustment of perception to
integrate with pipelining.
Dave.
elsif" -- so this isn't a problem.
> >
>
> I think the point of having C as a sub rather than as a separate
> syntax is so the parser doesn't have to do anything special for
> special keywords.
The specialness could be generalized, so that its no longer a parser hack:
#define elsif else if
Dave.
t the basic C to work.
And then we can replace the ~> with ->:
for 1,2,3,4
-> sub ($a, $b) { $a+$b }
-> sub ($a) { $a**2 }
-> { $^foo - 1 }
-> print;
And this begs the question: what exactly does the C contribute to
the semantics of the pipeline? What would C (in void context)
do differently?
Dave.
-> print
The "obj ~> method args" form calls the method on the object. C
is then a method (called on the entire list) that calls its codeblock for
each member
The "for list -> sub" would call the sub for each member of the list. Hence
an equivalence:
for list -> { per-elem code }
eq
list ~> map { per-elem code }
But remember, this is all getting very hypothetical: -> doesn't (currently)
mean "L2R pipe into sub"
Dave.
"Michael Lazzaro" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
>... if such capabilities exist, what are their real names? Can
> anyone think of any that are absolute must-haves? Are any of the above
> must-haves?
I think that the only must-have is the a
"Damian Conway" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> Dave Whipp suggested:
>
> > The size constraints are probably C properties, as is C.
The
> > exception behavior probably deserves to remain an C prope
f an object wants to have
properties that apply to all references (to a given instance), then that
property must be defined as an attribute of the object. An instance, itself,
doesn't have postIt style properties.
Dave.
"infinite" array still get an exception thrown when trying
to access an infinite [Inf] or [-Inf] index?
STRAWMAN ANSWER: Yes, it does.
Should follow (3a): the generator can through the exception if desired.
Now, what about @a[2.5]: can my generator do interpolation?
Dave.
--
http://dave.whipp.name
bject which, if assigned to, will
create the required element.
Dave.
--
http://dave.whipp.name
there's a cost, but if
the programmer asks for something, then they pay for it. But the
implementation guys aren't allowed to play bait-and-switch!
Dave.
--
http://dave.whipp.name
On Fri, Jan 31, 2003 at 05:59:46PM +0100, Leopold Toetsch wrote:
> A lvalue param is not strictly reading, but here has to happen something
> differently - yes:
>
> IMHO some sort of proxy could be passed here, saying: "if you write to
> me, this will be at @a[0]". Or auto-vivify the entry.
Thi
On Mon, Feb 03, 2003 at 06:25:09AM -0800, Austin Hastings wrote:
> The only time this doesn't change type (arguably a bad thing in its own
> right) is when you're doing boolean ops. And for those, there exist
> boolean operators.
Changing type is a very Perlish thing to do.
> > How 'bout a shortc
"Michael Lazzaro" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> Along those lines, the closest I've been able to come so far to a
> usable two-sentence definition is:
>
> -- A list is an ordered set of scalar values.
quibble: that's an "ordered bag", isn't it?
"Mark J. Reed" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
>
> On 2003-02-11 at 17:44:08, Mark J. Reed wrote:
> > pop @{[@a,@b,@c]}
> >
> > It creates an anonymous array, then removes the last element, leaving
two
> > elements in the array - which is i
"Michael Lazzaro" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> What is the utility of the perl5 behavior:
>
> \($a,$b,$c)
>
> meaning
>
> (\$a, \$b, \$c)
>
> Do people really do that? I must say, given that it looks *so
> obviously* like it instead
in perl 5:
$value = (1,2, @ARGV,3,4)[$i]
That's a list, and its length is not known at compile time.
Dave.
--
Nothing ventured, nothing lost.
n much the same was
as classes:
class Assoc1
is association(
Type1 $source,
Type2 @target is sorted { $^a cmp $^b } is unique
)
{
...
}
#later
my @type2_objs = $type1_obj.target;
(Or perhaps the Perl5 arrow syntax would be more appropriate here).
Dave.
much of an issue for
single scalars/ints/strs.
If the coercion is lazy, then its not really any more expensive than
coercing individual scalars, as needed.
Dave.
$db.select * FROM Foo WHERE Foo.bar LIKE a%b;
Could I implement this with the select function being a macro on the
Database base class: but invoked via the $db invocant? I am aware that
the macro would be a compile-time operation: but it could resolve into a
run-time mechanism that uses the invoc
macros in
it will be expanded. How would an infix macro indicate that it didn't
want to handle the "$io.select" example? If it returns its input,
unchanged, then that would be an infinite loop.
Dave.
--
http://dave.whipp.name
c
methods in a standard sequence. I would consider my "macromethod" in a
similar vain.
Dave.
--
http://dave.whipp.name
t looking like Perl6 code.
Perhaps I should back off a bit: Perl6 *will* be powerful enough support
the "Macros::macromethod" module, so perhaps I'll be able to write it in
a year's time, or so. It'll be a good test of the extensability mechanisms.
Dave.
--
http://dave.whipp.name
Brent Dax wrote:
Dave Whipp:
# But you're right, there are situations where the (base) type
# might not
# be knowable: and these could result in syntax errors.
Except they wouldn't, at least not always.
[snip]
The only part of that I'm not sure about is infix:LIKE, since such an
Foo is Bar;
typedef Baz is Bar;
Foo.isa("Baz") == TRUE;
The problem biols down to the fact that inheritance hierarchies are, um,
hierarchies -- trees. The lightwieght mechanism provides aliases for
nodes within the tree, thus all descendent nodes are also descendents of
the ali
ld be a simple prefix operator to enable
coercion of typed things. Perhaps the "splat" operator could serve here:
my Str $a = <>;
my Int $b = $a;# Error -- $a is explicitly typed as Str
my Int $c = $a.num # OK -- explicit corcion
my Int $d = *$a; # OK -- splat permits implicit coercion
Dave.
--
http://dave.whipp.name
Michael Lazzaro wrote:
3) If an "untyped" var is used for a typed parameter, a simple dataflow
analysis is used to determine whether the compiler can guarantee that,
at that point, an "untyped" var will _always_ contain values of a known,
specific type. If so, the type is inferred (silently or
Uri Guttman wrote:
talking about nested subs brought up another related idea, static (not
on the stack) lexicals inside subs.
Doesn't C give you this?
Dave.
--
http://dave.whipp.name
one value -- there
should be no expectation that it should behave like an integer, etc. So
my Scalar $a = 1;
should be an error -- you'd have to call the STORE method explicitly to
store the value into the scalar value.
Dave.
--
http://dave.whipp.name
ot;eq:id"
is much easier to generalize/extend.
Dave.
--
http://dave.whipp.name
Joe Gottman wrote:
Alternatively, there might be a new parameter type that indicates that the
parameter is not evaluated immediately:
sub infix:!! ($lsh, $rhs is deferred) {...}
A nice concept! So nice, in fact, that it would be a shame to limit it
to function args. I could see myself writing:
Reading A6, I was wondering if the following would work:
sub return_if_true ($value)
{
if ($value)
{
leave where=>caller(1), value=>$value
}
}
cros.
I tend to agree; but I note that it is possible to implement (1) over
the semantics of (2) by simply assigning to a tmp variable. The reverse
is not true. So if only one of the two is provided, then it should be
(2). Multiple properties can be applied, so "is deferred is cached"
On Tue, Apr 01, 2003 at 08:44:25AM -0500, Dan Sugalski wrote:
> There isn't any, particularly. We're doing preemptive threads. It
> isn't up for negotiation. This is one of the few things where I truly
> don't care what people's opinions on the matter are.
Sorry, I haven't been following this to
be a synch message that you're expected to reply to.
* halt (aka wait for finalize) -- the thread has nothing more to do.
* destroy execution context -- not needed if GCed.
Dave.
nts), the code for C and C
would be broadly independent of the execution mode. Though there could
clearly be an expectation:
for thread { my $a=0; sleep 1 and yield ++$a while $a<10 } -> $t
{
print "time=$t\n"
}
then s/thread/coro/;
Dave.
be a coroutine as
an idiom whereby user-code becomes a thread-scheduler).
The problem I see with the general approach is that it might not make the
common cases sufficiently trivial.
Dave.
nes themselves.
My summary is that yes, coroutines and threads are very different
things. But most of the language-infrastructure needed to support one,
is also needed for the other.
Dave.
On Tue, May 27, 2003 at 02:05:57PM -0700, Michael Lazzaro wrote:
> If we could think about "threads" not in terms of forkyness, but simply
> in terms of coroutines that can be called in parallel, it should be
> possible to create an implementation of "threading" that had to do a
> whole heck-of-
On Wed, May 28, 2003 at 07:58:37AM -0700, Austin Hastings wrote:
> On a single-CPU box, the OS level threads could easily be used to
> support blocking operations feeding back to async I/O, while all "real
> work" (execution of opcodes) was done in a single thread. Parrot could
> elect to implement
terms of liberated coroutines, you
could instead try to understand coroutines in terms constrained threads ;-).
If a fork-like behavior is useful for threads, it may also be useful for
coroutines. But fork is a bit like goto -- its an unstructured primitive.
Dave.
thread foo is input($a,$b,$c) is output($x,$y,$z)
{
when $a { $x.yield $a+1 }
when $b & $c { $y.yield $b+$c; $z.yield $b-$c }
}
Dave.
"Austin Hastings" <[EMAIL PROTECTED]> wrote
> --- Dave Whipp <[EMAIL PROTECTED]> wrote:
> > "Austin Hastings" <[EMAIL PROTECTED]> wrote:
> > > 1. C always acts the same way -- stores args in
> > CurThread.result
> > > and gi
ts, e.g. "why should
> the caller care if what they're doing invokes parallelization, so long
> as it does the right thing?")
Indeed: why should be callee care, either?
Dave.
change. There are some obvious hacks that
could work here: but is there a really nice solution. Ideally, we won't need
the low level details such as C<$tid>
Dave.
ult }
default => { status_monitor $tid.progress }
}
Perhaps a different keyword would be better: C as the looping
counterpart to C -- then extend C to accept a code block.
Dave.
p @_ };
loop {
timeout(60);
return $result;
CATCH Timeout { print "...$(time)\n" }
}
At last, no C! (Reminder: the suggested semantics of the threaded
variable were that a FETCH to it blocks until the result of the thread is
available).
Dave.
I think this hides the threads pretty effectively. Is a parrot-level timer
to much to ask for? How about resumable exceptions? But perhaps I'm still
being too clever, when a simpler solution exists:
sub slow_fn {
my $tick = Timer.new(60, { print "..." });
return slow_fn_imp @_;
}
Now if I could just get the compiler to not complain about that unused
variable...
Dave.
not sure that the GC guarentees that. I might need
sub slow_fn {
my $timer is last { .stop } = Timer.new(60, { print "." });
return slow_fn_imp @_;
}
but that's starting to get cluttered again.
Dave.
uld this work correctly maybe?
>
> sub slow_fn {
> my $timer is last { .stop } = new Timer secs => $_=1,
>reset => {$_++},
> code => {print "."};
> return slow_fn_imp @_;
> }
>
> Isn't that $_ proprietary to slow_fn such that it *would* work?
I had to stare at it for a few moments, but yes: I think it should work (if
we define a .reset attribute that accepts a codeblock).
Dave.
s no possible way the coerce it back into the coroutine (i.e. to
"un-launch" it).
Now here's another semantics question: would we want the following to be
valid?
sub slow
{
timeout(60) { return undef but "Error: timed out" };
return @slow_imp;
}
How about:
sub slow
{
timeout(60) { throw TimeoutException.new("Error: slow_fn timed out") };
return @slow_imp;
}
Dave.
, but I'm still not sure how it would fly.
Actually, I think that both have pretty-much the same problems. I assume
@Dan could work out a way to get the mechanics to work (basically a mugging:
we kill a thread/coro and steal its continuation point). But the semantics
of the cleanup could cause a world of pain. But realistically, a common use
of a timeout is to kill something that's been going on too long. I suppose
we could require some level of cooperation the the "dead" code.
Dave.
Luke Palmer wrote:
I think it would fall trivially out of the events mechanism, which is
planned for Parrot.
I have heard rumours of such a thing, but no details of how it will be
exposed in the language...
Dave.
with the main point you were wanting to make: a class-based
multimethod really should make the primary invocant ($self) implicit -- if
doing so doesn't make things even more confusing/ambiguous/nasty.
Dave.
"Piers Cawley" <[EMAIL PROTECTED]> wrote
> Threads and Progress Monitors
> Dave Whipp had some more thread questions, and wondered what would be
a
> good Perl 6ish way of implementing a threaded progress monitor. Whilst
> the discussion of all this was in
Michael Zedeler wrote:
This is exactly why I keep writing posts about Ranges being defunct as
they have been specified now. If we accept the premise that Ranges are
supposed to define a kind of linear membership specification between two
starting points (as in math), it doesn't make sense that
Moritz Lenz wrote:
Dave Whipp wrote:
for 0..10 -> $x { ... }
is treated as
for (0...10).pick(*) -> $x { ... }
Sorry, I have to ask. Are you serious? Really?
Ah, to reply, or not to reply, to rhetorical sarcasm ... In this case, I
think I will:
Was my specific proposal en
Moritz Lenz wrote:
I fear what Perl 6 needs is not to broaden the range of discussion even
further, but to narrow it down to the essential points. Personal opinion
only.
OK, as a completely serious proposal, the semantics of "for 0..10 { ...
}" should be for the compiler to complain "sorry, t
Aaron Sherman wrote:
On Wed, Jul 28, 2010 at 11:34 AM, Dave Whipp wrote:
To squint at this slightly, in the context that we already have 0...1e10 as
a sequence generator, perhaps the semantics of iterating a range should be
unordered -- that is,
for 0..10 -> $x { ... }
is treated as
Darren Duncan wrote:
Dave Whipp wrote:
Similarly (0..1).Seq should most likely return Real numbers
No it shouldn't, because the endpoints are integers.
If you want Real numbers, then say "0.0 .. 1.0" instead.
-- Darren Duncan
That would be inconsistent. $x ~~ 0..1 means 0
Matthew wrote:
use base 16;
my $a = 10;
say $a;
puts the number 0x10 into $a, and outputs `10'. Here, say $a.fmt('%d')
would output `16'.
As someone who has implemented, and used, mini-languages with such a
feature, I'd say that the confusion that it would cause does
significantly outweigh
Damian Conway wrote:
Perhaps we need to think more Perlishly and reframe the entire question.
Not: "What threading model do we need?", but: "What kinds of non-sequential
programming tasks do we want to make easy...and how would we like to be
able to specify those tasks?"
The mindset that I u
Damian Conway wrote:
I've been thinking about junctions, and I believe we may need a small
tweak to (at least) the jargon in one part of the specification.
When this issue has been raised in the past, the response has been that
junctions are not really intended to be useful outside of the narr
lete
implementation of a module implementing them, which runs successfully on
the current release of Rakudo*. I append said model for your amusement
(and suggestions!).
++
Dave.
Damian Conway wrote:
Yes, Ted Z. pointed out to me that, as the name of this construct,
"every" has ambiguity and synonym issues. Other possibilities are:
select(@values) < one(3..7)
those(@values) < one(3..7)
whichever(@values) < one(3..7)
itemize(@values) < one(3..7)
extra
uot;core" functionality that I'll be able to implement something
like this as a module. So I don't push it except when someone else
starts a thread about the "values of a junction" :).
Dave.
On 11/17/2010 10:08 PM, Martin D Kealey wrote:
Dimensioned numbers as restrictive types are useful, for uncovering bugs,
including sometimes latent ones in ported code.
Duration is a fairly clear example of a dimensioned quantity, and I think we
should think twice about abandoning its dimension
401 - 496 of 496 matches
Mail list logo
