it work on both hashes and arrays, without making the op very slow?
--
Matthijs van Duin -- May the Forth be with you!
at compile time.
True, but what about $x\$y ? :-)
(which I'd want to work for consistency reasons.. so you can write
$foo\bar\$baz\42 instead of ugly mixing like $foo\foo{baz}\42 )
--
Matthijs van Duin -- May the Forth be with you!
the point of my question. Since shorthand for hash
elements has already been banned from the core by Larry, I'm now just
exploring what is involved with adding it later on, independent of what
actual syntax I'd use (a bashtick, backslash, or something else).
--
Matthijs van Duin -- May the Forth
();
would that be:
$x = m/foo* $bar/ (+bar());
or
$x = $_.{'foo'} * $bar.{'and'} + bar();
?
As much as I see the appeal of this syntax, the / is simply too heavily used
already.
--
Matthijs van Duin -- May the Forth be with you!
examples is don't
do that then.
--
Matthijs van Duin -- May the Forth be with you!
for those ticks can be found)
--
Matthijs van Duin -- May the Forth be with you!
not (yet) implemented in my patch)
--
Matthijs van Duin -- May the Forth be with you!
``, but that point is
entirely orthogonal to the introduction of the ` dereferencing operator.
The two uses don't conflict. (which is why I was able to make a patch that
adds the `-operator to perl 5.8.3)
--
Matthijs van Duin -- May the Forth be with you!
too
This is of course natural.. many places in perl accept either a bareword or
simple scalar, at least in p5.
You are repeating the errors of javascript. $0[15] != $0{15}
No, he spotted the issue in advance and suggested a solution already.
--
Matthijs van Duin -- May the Forth be with you!
the 'Want' module (if installed) to speed up the common cases.
--
Matthijs van Duin -- May the Forth be with you!
pure system, it could probably be
implemented using a module.
--
Matthijs van Duin -- May the Forth be with you!
too much to the size of the runtime
library :-)
--
Matthijs van Duin -- May the Forth be with you!
faculty
--
Matthijs van Duin -- May the Forth be with you!
On Sun, Apr 06, 2003 at 12:38:29AM +0200, Matthijs van Duin wrote:
In other words, if you treat Inf as any particular number (which Mr
Mathematician stridently yet somewhat ineffectually reminds you that are
*not* allowed to do!), then you may get peculiar results.
There is no problem with doing
be to first produce all possibilities of length n
before giving any possibility of length n+1.
''
'A'
'B'
'AA'
'AB'
'BB'
'AAA'
'AAB'
...
I haven't spent a milisecond of working out whether that's feasible to
implement, but from a theoretical POV it seems like the solution.
--
Matthijs van Duin
Is there any specific reason this was a reply to Michael Lazarro's Re:
== vs. eq dated Tue, 1 Apr 2003 16:30:00 -0800 ?
(What I mean is, PLEASE don't use reply when you're not replying at all)
--
Matthijs van Duin -- May the Forth be with you!
On Mon, Mar 31, 2003 at 10:56:14AM +0200, Matthijs van Duin wrote:
temp $foo := $bar; # temporarily bind $foo to $bar
temp $foo = $bar;# temporarily assign the value of $bar to $foo
I just realize 'temp $foo = 3' might just as well mean bind $foo to a new
scalar and initialize it to 3
for the most
common case, cooperative threading wins from preemptive threading.
People who really want to do SMP should just fork() and use IPC, or use
the Thread::Preemptive module which *someone* will no doubt write :-)
--
Matthijs van Duin -- May the Forth be with you!
-time tasks from MacOS 9 to MacOS X curse the preemptive multitasking
the latter has.
--
Matthijs van Duin -- May the Forth be with you!
when true;
}
--
Matthijs van Duin -- May the Forth be with you!
-threaded applications slower
with your built-in support for preemptive threads :-)
--
Matthijs van Duin -- May the Forth be with you!
threading was used ;-)
It looks like we could use both very well though
--
Matthijs van Duin -- May the Forth be with you!
On Mon, Mar 31, 2003 at 12:12:54PM -0800, Michael Lazzaro wrote:
On Monday, March 31, 2003, at 11:18 AM, Matthijs van Duin wrote:
Don't those return Cundef, as opposed to the value of C$_? I.E.
wouldn't it be:
$_ and return $_ given big_calculation();
-or-
given big_calculation
On Mon, Mar 31, 2003 at 07:21:03PM +0100, Simon Cozens wrote:
[EMAIL PROTECTED] (Matthijs Van Duin) writes:
I think if we apply the Huffman principle here by optimizing for the
most common case, cooperative threading wins from preemptive threading.
Well, if you optimize for the most common case
$_ given baz(...args...);
note that putting in front of a sub call won't work in perl 6 (that syntax is
used to actually refer to the right sub var itself, iirc)
--
Matthijs van Duin -- May the Forth be with you!
= factorial.($x); # maybe this.
In general, don't use the form when you really want to call something.
/quote
--
Matthijs van Duin -- May the Forth be with you!
Apologies for nitpicking, but you misspelled my name as Mattijs 4 times
in the summary. The right spelling is Matthijs :-)
--
Matthijs van Duin -- May the Forth be with you!
On Wed, Mar 26, 2003 at 09:19:42AM +1100, Damian Conway wrote:
my $x = 1;# initialization
$x = 1;# assignment
Woo, C++ :-)
Considering 'our' merely declares a lexical alias to a package var, how
do we initialize package vars?
--
Matthijs van Duin -- May the Forth
On Mon, Mar 24, 2003 at 01:37:01PM -0500, Dan Sugalski wrote:
Since I'd as soon not encourage this, how about INSTANTIATE? Nice and
long and therefore discouraging. :)
Nothing a macro can't fix :-D
--
Matthijs van Duin -- May the Forth be with you!
will simply give a compile-time error)
--
Matthijs van Duin -- May the Forth be with you!
On Thu, Mar 20, 2003 at 08:49:28AM -0800, Austin Hastings wrote:
--- Matthijs van Duin [EMAIL PROTECTED] wrote:
you seem to have a much complexer model of hypotheses
than what's in my head.
The complex model is right -- in other words, if hypotheses are to be a
first-class part of the language
be wrong about that.
--
Matthijs van Duin -- May the Forth be with you!
Oops, I just noticed Sean had mailed Dan and me privately, not on the list..
sorry for sending the reply here :-)
--
Matthijs van Duin -- May the Forth be with you!
--
Matthijs van Duin -- May the Forth be with you!
attempt at getting its semantics right is what triggered all my recent
backtracking-related posts. (since continuations are unavailable, it looks
like I'll have to settle for the callback system)
--
Matthijs van Duin -- May the Forth be with you!
extrapolation.
I guess to be honestly consistent all modifiers would have to become
operators, which would bring us back to the multiple statement modifiers
to which Larry said no..
I'll rest my case
--
Matthijs van Duin -- May the Forth be with you!
;
--
Matthijs van Duin -- May the Forth be with you!
myself with pasm :)
--
Matthijs van Duin -- May the Forth be with you!
On Wed, Mar 19, 2003 at 01:01:28PM +0100, Matthijs van Duin wrote:
On Wed, Mar 19, 2003 at 10:38:54AM +0100, Leopold Toetsch wrote:
I would propose, estimate the ops you need and test it :)
Hmm, good point
Or even better.. I should just implement both examples and benchmark them;
they're simple
0.05
- --- -- --
16 480040.7868610.16
iBook; PPC G3; 700 Mhz
--
Matthijs van Duin -- May the Forth be with you!
generic backtracking semantics, and that's
what I'm talking about. Optimizations to avoid the genericity of these
backtracking semantics is for later.
--
Matthijs van Duin -- May the Forth be with you!
be elevated to the official
semantics. I say, make generic semantics first, and then optimize the heck
out of it.
--
Matthijs van Duin -- May the Forth be with you!
an error
(non-rule invoked as subrule) you'd switch to generic invocation instead.
Sounds like a good deal? :-)
--
Matthijs van Duin -- May the Forth be with you!
case.
--
Matthijs van Duin -- May the Forth be with you!
and efficient.
I have to admit I'm not 100% sure this is possible, but give me some time
to try to work out the details :-)
--
Matthijs van Duin -- May the Forth be with you!
ofcourse :-)
$a ??= $b :: $c;
--
Matthijs van Duin -- May the Forth be with you!
system for backtracking into subrules.
So, comments? (see also the questions at the top of the email)
--
Matthijs van Duin -- May the Forth be with you!
I just read Piers' summary:
Matthijs van Duin wondered if the issue of multiple statement modifiers
has been settled. The thread is long, and the answer is essentially (and
authoritatively) Yes, it's settled. No, you can't do it. So, unless
Larry changes his mind the point is moot.
So apparently I
it for now I think.. maybe I'll find more later :)
--
Matthijs van Duin -- May the Forth be with you!
; I'm not going to actively try to advocate them if
they're not liked :-)
--
Matthijs van Duin -- May the Forth be with you!
.
Ehhh, I think rules need more magic than just m{} inside a sub to allow
proper backtracking semantics when it's used as a subrule
So that's another very good reason to make them different :-)
--
Matthijs van Duin -- May the Forth be with you!
On Mon, Mar 17, 2003 at 07:49:36PM +0100, Matthijs van Duin wrote:
(blah blah I wrote on closures and rule-invocation)
I'm not saying rules will be implemented in such a way, but it's the first
thing that comes to mind.
Before anyone replies, I just realized I should probably just first browse
say I'm helping with the design
as we speak :-)
--
Matthijs van Duin -- May the Forth be with you!
= $x.items[0];
if ($z ~~ Perl6::SubCall !$z.parens $z.args 0) {
my @args = $z.args, $x.items[1...];
return new Perl6::MethodCall: $z.name, $y, @args;
}
}
# helpful error message ;-)
croak Can't deal with the stuff left of ~ operator;
}
--
Matthijs van
, but it is more readable imho.
Hmmm.. and I just realized.. is something like 'print while ;' still
available in perl 6? And if so, that means the while-loop would
topicalize in this case? What would the criterium be for this case? (I
hope not the kludge it is right now in perl 5 ;-)
--
Matthijs van
;
but I have to admit I can probably live without the ability to write
something like that ;-)
--
Matthijs van Duin -- May the Forth be with you!
achieve, and hence really needs to
be a statement modifier.
--
Matthijs van Duin -- May the Forth be with you!
57 matches
Mail list logo
