;re missing 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 va
the magic 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!
f, would it be possible to
make it work on both hashes and arrays, without making the op very slow?
--
Matthijs van Duin -- May the Forth be with you!
7;})
I think this is highly ambiguous.
$x = /foo * $bar/and +bar();
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!
age is bad. It means I wrote awful code here.
So the only thing I can say in response to these convoluted examples is "don't
do that then".
--
Matthijs van Duin -- May the Forth be with you!
glyph. (And because of its location on most keyboards.)
And also because ` is unused in this context, while it's not unimaginable
that someone may want the number of elements modulo something. (I dislike
unnecessary whitespace-disambiguating rules)
--
Matthijs van Duin -- May the Forth be with you!
. (I'm not
entirely sure yet how I feel about removing ``... maybe just leave it until
a better application for those ticks can be found)
--
Matthijs van Duin -- May the Forth be with you!
lar should be usable 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
to like ``, 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!
n, this can also be used for arrays.
I like that too. (though not (yet) implemented in my patch)
--
Matthijs van Duin -- May the Forth be with you!
w
A::P uses the 'Want' module (if installed) to speed up the common cases.
--
Matthijs van Duin -- May the Forth be with you!
7;t represent INFINITY in any literal sense [...] and could
easily hold a digital image of a tuna
I vote yes on that, if it doesn't add too much to the size of the runtime
library :-)
--
Matthijs van Duin -- May the Forth be with you!
for practical, I don't see
that as a problem.
If we really want a mathematically pure system, it could probably be
implemented using a module.
--
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
I want to work with... luckily I
haven't seen him around here at the maths faculty
--
Matthijs van Duin -- May the Forth be with you!
quot; way would 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&#x
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!
l = factorial($x); # this or
$val = &factorial.($x); # maybe this.
In general, don't use the & form when you really want to call something.
--
Matthijs van Duin -- May the Forth be with you!
$_ 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!
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
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 C, as opposed to the value of C<$_>? I.E.
wouldn't it be:
$_ and return $_ given big_calculation();
-or-
given
g system, but we
*must* have a preemptive one.
"must" is a big word; people happily used computers a long time before any
threading was used ;-)
It looks like we could use both very well though
--
Matthijs van Duin -- May the Forth be with you!
't make my non-preemptive-threaded applications slower
with your built-in support for preemptive threads :-)
--
Matthijs van Duin -- May the Forth be with you!
return when true;
}
--
Matthijs van Duin -- May the Forth be with you!
duling, and people who try to move applications that perform
real-time tasks from MacOS 9 to MacOS X curse the preemptive multitasking
the latter has.
--
Matthijs van Duin -- May the Forth be with you!
Huffman principle here by optimizing 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!
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 i
ke the one above... to be continued)
--
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
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!
b to close of $y, making b state makes no sense... you should
use 'my sub b' instead in that case.
--
Matthijs van Duin -- May the Forth be with you!
uot; will not stay shared' - but I
hope perl 6 will simply give a compile-time error)
--
Matthijs van Duin -- May the Forth be with you!
fferent closure. The $x in each closure
all refer to the same variable. Each closure's $y however is different and
independent.
--
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!
back-model isn't. I also think it
has less opportunity for optimizations but I might be wrong about that.
--
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 t
7;m suggesting you do "officially", but optimize it away behind the scenes.
This leaves nice and simple semantics for backtracking in general, while
in fact their implementation inside rules is simple 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!
neral case, but we've come nowhere near touching that)
We have come near it.. backtracking is easy using continuations, and we can
certainly have rules set the standard for the general case.
--
Matthijs van Duin -- May the Forth be with you!
efully). Since you need to fetch the rule body anyway,
there should be no extra overhead: where you'd normally throw 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!
t calling semantics to subrules if they determine that's possible.
But I don't think a special optimization should 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!
can. Rules need 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!
819 invoke50000.0262850.05
962 rx_literal_s_i_sc_ic 10.0542600.05
- --- -- ------
16 480040.7868610.16
iBook; PPC G3; 700 Mhz
--
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 s
amiliarize myself with pasm :)
--
Matthijs van Duin -- May the Forth be with you!
t "baz: $i\n";
thread_yield;
}
}
thread_exit;
--
Matthijs van Duin -- May the Forth be with you!
ry all sorts of things that can't actually be done, but I
suppose in this case it's a plausible 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!
egex match)
My 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!
hich has already returned. Are you saying every rule will be
an explicit state machine?
This has the advantage that C behaves consistently with the
rest of Perl
What do you mean?
I looked around in Parrot a little, and it seems like continuations
are done pretty efficiently.
Yes, I no
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 poi
hat might negatively
affect speed.
Finally, the continuation system also gives 'let' interesting semantics
which may be useful outside of rules.
Basically, the continuation system has only one big drawback: it uses
continuations. I really have no idea how efficient those will be in
parrot. If using them makes rules significantly slower than speed will
probably have to win from cleanness and the callback system should be used.
Or, as I mentioned at the top, maybe I'm just thinking way too complex
and overlooking a simple and obvious 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!
:-)
$a ??= $b :: $c;
--
Matthijs van Duin -- May the Forth be with you!
dy quite busy... but I'd say I'm helping with the design
as we speak :-)
--
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 fi
ld be a regex"
point. Good enough.
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!
t <> and
are shorter, and have (to me) fairly obvious meanings. But it was just a
random suggestion; I'm not going to actively try to advocate them if
they're not liked :-)
--
Matthijs van Duin -- May the Forth be with you!
n backtracking
If you backtrack across it, it fails all the way out of the current
list of alternatives.
This suggests that if you do:
[ foo [ bar :: ]? | foo ( \w+ ) ]
that if it backtracks over the :: it will break out of the outermost [],
since the innermost isn't a list of alternatives.
or message ;-)
croak "Can't deal with the stuff left of <~ operator";
}
--
Matthijs van Duin -- May the Forth be with you!
-modifier, which really has an impact on the
statement unlike any operator could achieve, and hence really needs to
be a statement modifier.
--
Matthijs van Duin -- May the Forth be with you!
7; is identical to
'BAZ and BAR and FOO'.
'FOO when BAR' is similar to 'FOO if BAR' except BAR is matched magically
like the rhs of the ~~ operator and an implicit 'break' occurs if true.
RATIONALE
1. it doesn't hurt anything: existing use of the modifiers (now operators)
remains functionally the same.
2. it allows new useful expressions
3. it's more consistent ('if' has no reason being more special than 'and')
4. it shouldn't make parsing more difficult
--
Matthijs van Duin -- May the Forth be with you!
the conditionals infix-operators would
probably suffice.
Then again, I just thought up (perl 5 style):
print for split while <>;
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!
ld the criterium be for "this case"? (I
hope not the kludge it is right now in perl 5 ;-)
--
Matthijs van Duin -- May the Forth be with you!
62 matches
Mail list logo
