[EMAIL PROTECTED] (Larry Wall) writes:
> While no assumption is going unquestioned for Perl 6, I do still
> believe that the decision not to overload + for concatenation is one
> of the few things I did right in Perl 1.
Fair enough. And maybe I'm getting ahead of myself (or behind myself)
anyway
On Sat, Nov 23, 2002 at 07:34:47PM +, Simon Cozens wrote:
: [EMAIL PROTECTED] (Smylers) writes:
: > >... they believed that the + should concatenate the two strings.
: > >
: > > Makes perfect sense to me.
: >
: > Makes sense in a language where variables are typed
:
: It also makes sense
On Sat, Nov 23, 2002 at 07:34:47PM +, Simon Cozens wrote:
>I could mention some other
> languages (or at least, a language (of which I'm becoming considerably
> more fond as I get to know it (especially having just come back from
> Japan (excuse the
[EMAIL PROTECTED] (Smylers) writes:
> >... they believed that the + should concatenate the two strings.
> >
> > Makes perfect sense to me.
>
> Makes sense in a language where variables are typed
It also makes sense in a language where values are typed. They just
have to be slightly more stro
On Thu, 2002-11-21 at 06:57, Mark Biggar wrote:
> Martin D Kealey wrote:
> > I want Perl to run 128 times faster on a 128 CPU machine... now I know
> > that's not entirely realistic, but it should be able to run at least say
> > 60 times faster.
>
> Amdahl's law applies here: "no amount of parale
Dan Sugalski wrote:
Whups, misunderstanding there. I realize that we need to throw an
exception (or a junction of exception and not exception) if evaluating
one of the junction members. The question is whether we should evaluate
them all regardless and then figure it out at the end, and what t
Martin D Kealey wrote:
On Mon, 2002-11-18 at 18:10, Dave Whipp wrote:
Why do we need to use preemptive threads? If Parrot is a VM, then surely
the threading can be implemented at its level, or even higher.
And what about *lower*? Like down among the CPUs?
I want Perl to run 128 times faster
On Mon, 2002-11-18 at 18:10, Dave Whipp wrote:
> Why do we need to use preemptive threads? If Parrot is a VM, then surely
> the threading can be implemented at its level, or even higher.
And what about *lower*? Like down among the CPUs?
I want Perl to run 128 times faster on a 128 CPU machine...
At 6:09 PM +1100 11/19/02, Damian Conway wrote:
Dan Sugalski wrote:
We're definitely going to need to nail the semantics down. Would
one thread throwing an exception require all the threads being
aborted, for example?
I would imagine so. You can't reasonably build a junction out of values
tha
Dan Sugalski wrote:
We're definitely going to need to nail the semantics down. Would one
thread throwing an exception require all the threads being aborted, for
example?
I would imagine so. You can't reasonably build a junction out of values
that weren't successfully created. If you write:
$
At 3:45 PM +1100 11/19/02, Damian Conway wrote:
Dave Whipp wrote:
Does the exception get deferred until after all the threads have completed?
I would doubt it.
We're definitely going to need to nail the semantics down. Would one
thread throwing an exception require all the threads being abor
Dave Whipp wrote:
Under my junctive semantics it is. It simply calls C twice, with
the two states, and returns a conjunction of the resulting filehandles.
Though you probably really want a *dis*junction there.
The thing that's worrying me is: what happens when one of them throws an
exception?
"Damian Conway" <[EMAIL PROTECTED]> wrote > >my $file = open "error.log"
& "../some/other.log"; # I hope this is legal
>
> Under my junctive semantics it is. It simply calls C twice, with
> the two states, and returns a conjunction of the resulting filehandles.
> Though you probably really wan
matt diephouse wrote:
sub foo($param is junction) {...}
Doesn't that go against perl's dynamic philosophy?
???
That requires me to type my methods where I may not want to.
> Let's say I have a sub that logs errors:
sub log_error($fh, $error) { # filehandle and error msg
$
On Monday, November 18, 2002, at 05:47 PM, Luke Palmer wrote:
It's either that or have your functions, which were perfectly logical
suddenly be subject to junction logic. That is, if $x == 2 and $x
== 3 both being true, when your code relies on them not both firing.
I think it's a very good d
> Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
> Date: Mon, 18 Nov 2002 18:59:58 -0500
> From: matt diephouse <[EMAIL PROTECTED]>
> X-SMTPD: qpsmtpd/0.12, http://develooper.com/code/qpsmtpd/
>
> Damian Conway wrote:
>
>> matt diephouse wrote:
> >
> >>> $junction = $x | $y | $z;
> >>>
Dan Sugalski wrote:
Hrm. What happens if the junction is then used as an iterator?
$junction = File::Open("foo") | File::Open("bar);
for (<$junction>) {
...
}
In Larry's formulation that's just the same as:
while $_ := $junction.next { ... }
which, when called on a junction, Cs e
Damian Conway wrote:
matt diephouse wrote:
$junction = $x | $y | $z;
foo($junction);# Call foo($x), foo($y), and foo($z)
# in parallel and collect the results
# in a disjunction
Looking at that code, I'm w
At 9:05 AM +1100 11/19/02, Damian Conway wrote:
matt diephouse wrote:
$junction = $x | $y | $z;
foo($junction);# Call foo($x), foo($y), and foo($z)
# in parallel and collect the results
# in a disjunction
Lo
matt diephouse wrote:
$junction = $x | $y | $z;
foo($junction);# Call foo($x), foo($y), and foo($z)
# in parallel and collect the results
# in a disjunction
Looking at that code, I'm wondering how you pass a
Damian Conway wrote:
BTW, in thinking about it further, I realize that Dan is going
to have to tackle this issue anyway. There's fundamentally no
difference in the exigencies of:
$junction = $x | $y | $z;
foo($junction);# Call foo($x), foo($y), and foo($z)
At 2:57 PM + 11/18/02, Nicholas Clark wrote:
But I'm not sure if parrot is going to give the perl interpreter cheap
threading. (Does the async IO mean that one parrot interpreter could
internally co-operatively thread perl in some cases?)
Oh, it could do it preemptively. And parrot can (and,
At 9:10 PM -0800 11/17/02, Dave Whipp wrote:
Dan Sugalski wrote:
The expensive part is the shared data. All the structures in an
interpreter are too large to act on atomically without any sort of
synchronization, so everything shared between interpreters needs to
have a mutex associated with i
On Mon, Nov 18, 2002 at 08:22:45AM +1100, Damian Conway wrote:
> Luke Palmer asked:
>
> > Of course, there will be a pragma or something to instruct it to
> > operate serially, yes?
>
> I doubt it. Unless there's a pragma to instruct threads to operate
> serially.
>
> In any case, I'm not sure w
Dan Sugalski wrote:
The expensive part is the shared data. All the structures in an
interpreter are too large to act on atomically without any sort of
synchronization, so everything shared between interpreters needs to have
a mutex associated with it. Mutex operations are generally cheap, but i
At 8:22 AM +1100 11/18/02, Damian Conway wrote:
Luke Palmer asked:
Of course, there will be a pragma or something to instruct it to
operate serially, yes?
I doubt it. Unless there's a pragma to instruct threads to operate
serially.
In any case, I'm not sure what such a pragma would buy you. T
At 1:00 PM +1100 11/18/02, Iain 'Spoon' Truskett wrote:
* Dan Sugalski ([EMAIL PROTECTED]) [18 Nov 2002 12:56]:
[...]
Perl's standard threading behaviour's going to be
rather heavyweight, though.
Silly question time: Why is it going to be rather heavyweight?
(Not complaining or berating, jus
* Dan Sugalski ([EMAIL PROTECTED]) [18 Nov 2002 12:56]:
[...]
> Perl's standard threading behaviour's going to be
> rather heavyweight, though.
Silly question time: Why is it going to be rather heavyweight?
(Not complaining or berating, just wanting information =) )
> (Though the presentation on
At 7:39 AM +1100 11/18/02, Damian Conway wrote:
Dan Sugalski wrote:
Creates a disjunction of three classnames, then calls the C<.run>
method on each, in parallel, and returns a disjunction of the results
of the calls (which, in the void context is ignored, or maybe
optimized away).
I was afr
Luke Palmer asked:
Of course, there will be a pragma or something to instruct it to
operate serially, yes?
I doubt it. Unless there's a pragma to instruct threads to operate
serially.
In any case, I'm not sure what such a pragma would buy you. The
ordering of evaluation would still be inherent
> Date: Mon, 18 Nov 2002 07:39:55 +1100
> From: Damian Conway <[EMAIL PROTECTED]>
>
> It would be *vastly* better thought integrate junctive calls with
> the standard threading behaviour.
Of course, there will be a pragma or something to instruct it to
operate serially, yes?
Luke
Dan Sugalski wrote:
Creates a disjunction of three classnames, then calls the C<.run>
method on each, in parallel, and returns a disjunction of the results
>> of the calls (which, in the void context is ignored, or maybe
>> optimized away).
I was afraid you'd say that.
Then you shouldn't ha
At 12:46 PM +1100 11/17/02, Damian Conway wrote:
Dan Sugalski pondered:
What does:
>
$foo = any(Bar::new, Baz::new, Xyzzy::new);
$foo.run;
do?
Creates a disjunction of three classnames, then calls the C<.run> method on
each, in parallel, and returns a disjunction of the results of
Dan Sugalski pondered:
What does:
>
$foo = any(Bar::new, Baz::new, Xyzzy::new);
$foo.run;
do?
Creates a disjunction of three classnames, then calls the C<.run> method on
each, in parallel, and returns a disjunction of the results of the calls
(which, in the void context is ignored, o
On Thu, Nov 14, 2002 at 09:10:07PM +, Richard Proctor wrote:
: On Thu 14 Nov, Michael G Schwern wrote:
: > On Thu, Nov 14, 2002 at 12:19:47PM +, Andy Wardley wrote:
: > > Can we overload + in Perl 6 to work as both numeric addition
: > > and string concatenation, depending on the type of th
On Thu, 14 Nov 2002, Ken Fox wrote:
> Andy Wardley wrote:
>
> > Can we overload + in Perl 6 to work as both numeric addition
> > and string concatenation ...
>
> Isn't there some nifty Unicode operator perl6 could enlist? ;)
>
> How about concatenating adjacent operands? ANSI C does this
> with
From: Dan Sugalski [mailto:dan@;sidhe.org]
> At 5:57 PM -0500 11/14/02, Ken Fox wrote:
> >
> >Wasn't one of the main problems with Jarkko's juxtaposition
> >proposal that it would kill indirect objects? Have we chased
> >our tail on this subject after the colon became required for
> >indirect objec
At 5:57 PM -0500 11/14/02, Ken Fox wrote:
Michael G Schwern wrote:
Before this starts up again, I hereby sentence all potential repliers to
first read:
"string concatenation operator - please stop"
http://archive.develooper.com/perl6-language@;perl.org/msg06710.html
The bike shed thing is like
Michael G Schwern wrote:
Before this starts up again, I hereby sentence all potential repliers to
first read:
"string concatenation operator - please stop"
http://archive.develooper.com/perl6-language@;perl.org/msg06710.html
The bike shed thing is like Godwin's Law. Only I don't know
which side
On 2002-11-14 at 16:47:15, Michael G Schwern wrote:
> "string concatenation operator - please stop"
> http://archive.develooper.com/perl6-language@;perl.org/msg06710.html
BTW, the first link there - to the bikeshed story - is broken.
This is the correct link:
http://www.freebsd.org/doc/en_US.ISO88
On Thu, Nov 14, 2002 at 09:10:07PM +, Richard Proctor wrote:
> There have been times when I have wondered if string concatination could be
> done without any operator at all. Simply the placement of two things
> next to each other as in $foo $bar or $foo$bar would silently concatenate
> them.
On Thu 14 Nov, Michael G Schwern wrote:
> On Thu, Nov 14, 2002 at 12:19:47PM +, Andy Wardley wrote:
> > Can we overload + in Perl 6 to work as both numeric addition
> > and string concatenation, depending on the type of the operand
> > on the left?
There have been times when I have wondered i
On Thu, Nov 14, 2002 at 12:19:47PM +, Andy Wardley wrote:
> Can we overload + in Perl 6 to work as both numeric addition
> and string concatenation, depending on the type of the operand
> on the left?
>
> I realise the answer is "probably not", given the number/string
> ambiguity of Perl varia
Andy Wardley wrote:
> Quoted from "Seven Deadly Sins of Introductory Programming Language
> Design" [1] by Linda McIver and Damian Conway:
>
> over one thousand novice programming students ...:
>
> "the quick brown fox" + "jumps over the lazy dog"
>
>... they believed that the + s
Andy Wardley wrote:
Can we overload + in Perl 6 to work as both numeric addition
and string concatenation ...
Isn't there some nifty Unicode operator perl6 could enlist? ;)
How about concatenating adjacent operands? ANSI C does this
with string constants and it works very well. It would become
Quoted from "Seven Deadly Sins of Introductory Programming Language
Design" [1] by Linda McIver and Damian Conway:
We have shown over one thousand novice programming students
the C/C++ expression:
"the quick brown fox" + "jumps over the lazy dog"
and asked them what they believe
46 matches
Mail list logo
