Re: S5 updated
How do you do that? Generation and matching are two different things
algorithmically.
yes, but they are intimately linked. just like the transformation of a string
into a number, and from a number to a string. Two algorithmically different
things as well, but they'd damn-well better be exact inverses of the other.
It all comes down to what you think is a 'low level' op.. Some languages
think that regular expressions themselves aren't low level enough to be
included in the language, perl thinks that it is low-level enough to be an op.
My point is that if inputting strings into grammars is low level
enough to be an op, why isn't generating strings *from* grammars?
Anyways, that's my main point.. anyone who wants to read further for more sub-points
on why I believe this to be true, proceed at their own risk..
@gen = g:bnd(1000)/[ab]+/
if (@gen !~ m/[ab]+/) { print STDERR something is seriously wrong..\n; }
or maybe even
(g:bnd(1000)/[a-b]+/ !~ m/[a-b]+/) print STDERR SOMETHING IS SERIOUSLY
WRONG\n;
I suppose generate could be distributed in a standard module
Or even a nonstandard module. That's my point.
Let me come right round to my point about perl being open source.
Someone has to do the work somewhere, and making it standard or core
doesn't change that. It just means that it'll take longer.
well, of course. But its not something that needs be included in the first
iteration. As far as I know, making g// as an operator (or adding a modifier
to m//) doesn't change the perl6 parser in any way.
My suggestion is that doing it at this low level will help stress test
the regex engine, and it would be useful to have in 'make test'. And hence it
makes sense as either a low-level module or op.
IMO Its always helpful to see a problem from two different angles - and if a
g:// !~ m// equation comes up true, something is either extremely wrong
with the regex engine or something is extremely wrong with the generator.
And if there was a way to 'coverage test' your regular expressions (so that
you could be sure that all regex alternations were tested) then you could
use the regex engine to stress test the generator.
Making standard also doesn't make it any faster. You have to burn the
cycles somewhere along the line in any case. The algorithm is
recursive, and that's a mathematical truth. If you can find a
nonrecursive algorithm, please do so, and then you can put it in a
module.
of course, but making it 'standard' - and especially making it so that it
is part of the regression test suite - gives it incentive to be complete
and the incentive for people to make performance improvements and perhaps
code it in IMCC/parrot byte code.
Plus, it gives it incentive for *standardization* - I could see lots of
partial solutions out on C6AN for the generator problem when only one is
really needed - one that totally matches the regex engine. Its just like
dates and times - CPAN is a veritable sink for half-implemented solutions,
where if we had a single standard people's lives would be a lot easier.
I think we should all settle on the fact that any feature could be
considered standard, but very few probably should. And what is is
Larry's decision, and I think we should leave it at that.
Look, to a certain extent I agree with you, and I don't want to belabor
the point. Let me just say that this is my attempt at lobbying the decision
making process.. ;-)
Ed
Re: This week's summary
On Wed, 22 Sep 2004, The Perl 6 Summarizer wrote: Writing pack, or something like it Michele Dondi wondered how to write pack-like functions in Perl 6, where the first argument is a string which specifies the signature of the rest of the function call. The proposal stumped me, but maybe you all can make something of it. It was not a *proposal* and it was not really about writing pack-like functions. It was really about... D'Oh! I can hardly summarize myself: well, let's say that it was wether about it will be possible in Perl6 to use what I judge to be elegant and natural functional-language-like constructs (possibly avoiding explicit intermediate variables with the exception of, say, $_) like *e.g.* (in this case) map()ping a list of values to a suitable list of curried (on the given values) closures, then reduce()ing it by a suitable (functional) composition and applying the result to the desired input. Not very concise indeed... well, just more verbose than conceptually complex, IMHO! BTW: I'm a male, Michele is Italian for Michael, Mikhail, etc. etc. ad libitum... Mike -- It was part of the dissatisfaction thing. I never claimed I was a nice person. - David Kastrup in comp.text.tex, Re: verbatiminput double spacing
Re: A..Z alternatives
Andrew Rodland wrote: On Tuesday 21 September 2004 07:18 pm, Thomas A. Boyer wrote: Larry Wall wrote: Somebody needs to talk me out of using A..Z for the simple cases. Larry [ for array dimension placeholder ] That might confuse users of languages that were not C-syntax-influenced, who think that '**' means not equal. But surely old Modula hacks like me are in a minority in the Perl world (and Pascal programmers would never do Perl, would they? Algol, anybody?) So maybe I'm the only one who runs the risk of that particular confusion. :-) What about BASIC? Aren't all the little kids today raised on BASIC? :) Only if their parents are evil... I was raised on BASIC and look what happened - now I'm writing Perl Quiz of the Week solutions in Haskell!
Re: This week's summary
On Wed, 22 Sep 2004 21:11:02 +0100, The Perl 6 Summarizer [EMAIL PROTECTED] wrote: The Perl 6 Summary for the week ending 2004-09-17 Another week, another summary, and I'm running late. So: This week in perl6-compiler Bootstrapping the grammar Uri Guttman had some thoughts on bootstrapping Perl 6's grammar. He hoped that his suggested approach would enable lots of people to work on the thing at once without necessarily getting in each other's way. Adam Turoff pointed everyone at a detailed description of how Squeak (a free Smalltalk) got bootstrapped. http://xrl.us/c6kp This link doesn't seem to be working, and www.perl6.org doesn't have the archives of perl6-compiler online yet. Does anyone have a link to the archives that works?
Re: S5 updated
On Sep 22, 2004, at 5:06 PM, Edward Peschko wrote: How do you do that? Generation and matching are two different things algorithmically. yes, but they are intimately linked. just like the transformation of a string into a number, and from a number to a string. Two algorithmically different things as well, but they'd damn-well better be exact inverses of the other. But they're not: 3 foo -- 3 -- 3 My point is that if inputting strings into grammars is low level enough to be an op, why isn't generating strings *from* grammars? Maybe, because it's a less common thing to want to do? (Which is a bit ironic, since technically grammars are typically characterized as sets of rules for how to generate all the acceptable strings of the language they define, and parsing is sort of running that in reverse.) But you seemed to be saying (to which Luke replied the How do you do that? above) that they should somehow share an implementation, so that they can't accidentally diverge. But algorithmically it seems they can't share an implementation, so making them both fundamental ops doesn't achieve the goal of ensuring parity. JEff
Re: This week's summary
On Thu, Sep 23, 2004 at 09:12:32AM -0400, Buddha Buck wrote: On Wed, 22 Sep 2004 21:11:02 +0100, The Perl 6 Summarizer [EMAIL PROTECTED] wrote: The Perl 6 Summary for the week ending 2004-09-17 Another week, another summary, and I'm running late. So: This week in perl6-compiler Bootstrapping the grammar Uri Guttman had some thoughts on bootstrapping Perl 6's grammar. He hoped that his suggested approach would enable lots of people to work on the thing at once without necessarily getting in each other's way. Adam Turoff pointed everyone at a detailed description of how Squeak (a free Smalltalk) got bootstrapped. http://xrl.us/c6kp This link doesn't seem to be working, and www.perl6.org doesn't have the archives of perl6-compiler online yet. Does anyone have a link to the archives that works? http://www.mail-archive.com/[EMAIL PROTECTED]/ http://www.mail-archive.com/[EMAIL PROTECTED]/msg00076.html -- We strive to quickly network economically sound data in order to assertively leverage other's high-payoff intellectual capital to exceed customer expectations
Re: S5 updated
[EMAIL PROTECTED] wrote:
I'll show you. Here are some of the generators. This is very dense,
functional code. Read at your own risk (but I'm certainly not writing
it to be executed!).
Quite. ;)
For the regexp /a aa aaa a aa/, this would sequentially
search through all possible ways to decompose 21 until it hit
1+2+3+4+5+6; then it'd return ax21 as the single result. This... might
take a while.
Since programming in Theoretic Perl6 (Terl6?) /is/ fun, here's my take:
# compositions2($length, @listoflists) gives all possible ways to depompose
# $length into the sum of the form a1+a2+a3+...+an so that a[i] is contained
# in @listoflists[i]
multi generate(Rule::Group $group: Int $length) {
# For each assignent of lengths to each of $groups children
# such that they sum to $length...
compositions2($length, map(possible_lengths, $group.children)) ==
map - @comp {
@comp $group.children ==
map - $n, $pat {
# Generate every string of length $n that the subpattern
# matches
[ $pat.generate($n) ]
} ==
# Join our results together
outer == join ''
}
}
use IntegerIntervalArithmetics add_lists, mult_lists ;
# add_lists(@list1, @list2) returns the list of sums of all possible
# elements of the lists. However, it should take .. and ... operators
# into account. This generally requires range tree datastructure of some
# sort.
# mult_lists(@list1, @list2) returns the list of all products
multi possible_lengths(Rule::Group $group) {
[ reduce(add_lists, map(possible_lengths, $group.children)) ];
}
multi possible_lengths(Rule::Plus $plus) {
[ mult_lists($plus.expression, 1... ];
}
multi possible_lengths(Rule::Constant $const) {
[ length($const.chars) ];
}
I'm still not claiming that this is something one should use, but it /was/ fun
to tinker with. :)
Miro
Re: S5 updated
On Sep 23, 2004, at 5:27 PM, Edward Peschko wrote:
On Thu, Sep 23, 2004 at 08:15:08AM -0700, Jeff Clites wrote:
just like the transformation of a string into a number, and from a
number to a string. Two algorithmically different things as well,
but they'd damn-well better be exact inverses of the
other.
But they're not:
" 3 foo" -- 3 -- "3"
I'd say that that's a caveat of implementation, sort of a side effect
of handling
an error condition.
Nope, I'd call it fundamental semantics--it allows common idioms such
as "0 but true" in Perl5, for example. It's just an explicit part of
the rule for how Perl (and C's strtol/atoi functions) assign numerical
values to strings.
But you might like this example better, which I assume will work in
Perl6:
"３" -- 3 -- "3"
(In case your email viewer doesn't render that, the first string
contains the "fullwidth digit three", a distinct, wider version of a 3,
used in some Asian languages.)
By your criteria there are very few inverses - you could say that
multiplication isn't an inverse of division because of zero, for
example.
I'm reacting here to your saying, "exact inverses". But for this
example, it's not my criteria--to a mathematician, multiplication over
the real numbers (or over integers) is in fact not invertible.
If you add the further caveat that everything in the string to be
converted has to be an integer, then they *are* direct inverses.
Yes, the operation is invertible, if restricted to a domain over which
it's invertible
My point is that if inputting strings into grammars is low level
enough to be an op, why isn't generating strings *from* grammars?
Maybe, because it's a less common thing to want to do?
Well, there re two responses to the "that's not a common thing to want
to do":
1) its not a common thing to want to do because its not a useful
thing to do.
2) its not a common thing to want to do because its too damn
difficult to do.
I'd say that #2 is what holds. *Everybody* has difficulties with
regular
expressions - about a quarter of my job is simply looking at other
people's regex used in data transformations and deciding what small
bug is causing them to fail given a certain input.
Yeah, but when a regex isn't acting how I expected it to, I know that
because I've already got in-hand an example of a string it matches
which I thought it wouldn't, or one it fails to match which I thought
it should. What I want to know is *why*--what part of the regex do I
need to change. Generating strings which would have matched, wouldn't
seem to help much.
And you might be underestimating how many strings can be generated from
even a simple regex, and how uninformative they could be. For example,
the Perl5 regex /[a-z]{10}/ will match 141167095653376 different
strings, and it would likely be a very long time before I'd find out if
this would match any strings starting with "x". I'd probably be left
with the impression that it would only match strings starting with
"a".
Running a regular expression in reverse has IMO the best potential for
making
regexes transparent - you graphically see how they work and what they
match.
How graphically?
Why shouldn't that be reflected in the language itself?
Maybe because if it's likely to be used mostly for debugging, and can
be implemented in a library, then it doesn't need to be implemented as
an operator, and contribute to the general learning curve of the
language's syntax.
JEff
