[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.
[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 strongly
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 jet
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 in a
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...
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
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
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 paralellism
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
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
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
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
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)
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
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
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
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, Cnexts
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;
foo($junction);
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
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
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 Copen twice, with
the two states, and returns a conjunction of the resulting filehandles.
Though you probably really want a
Dave Whipp wrote:
Under my junctive semantics it is. It simply calls Copen 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
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
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 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 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 have
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
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
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
* 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 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,
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.
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, or
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 string
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 the
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 the
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
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 variables:
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 if
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 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:
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
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
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 objects?
I
44 matches
Mail list logo
