Grammars that generate stuff
Hi all. I've been thinking about stringification, forms, and things
like that.
As exegesis 7 points out, sprintf, pack, and the forms language all
essentially take data and specifies how to turn it into a string (I'm using
string loosely here). Likewise with .perl -- it takes some data, and turns
it into a string formatted in a particular way.
Perl 6 has a general language (grammars) for taking some input and a
grammar, and separating the data from the formatting, as it were.
What's made Perl 6 so much more powerful in this area is the grouping
of regexen into grammars.
I'm wondering if we can't come up with a language that does for output
formatting what grammars do for input formatting.
For example, say we could create something called an
outputgrammar. We could do something like this:
grammar XMLIn {...}
outputgrammar XMLout {...}
My thought is that you would then be able to read an XML document
using the XMLin grammar, do a transform or two, and then rewrite it almost
identically (except the changes) with the outputgrammar.
Ideally, it'd be possible to specify one grammar that would act both
for parsing output and formatting input. This may not be possible, but I like
the idea.
It may already be possible to mock up some of these things (a hash
array of sprintf formats?), but I'd be interested in seeing some discussion on
what's possible.
Of course, if this has already been discussed, I'd love to read about
it -- please send links.
:)
-
| Name: Tim Nelson | Because the Creator is,|
| E-mail: wayl...@wayland.id.au| I am |
-
BEGIN GEEK CODE BLOCK
Version 3.12
GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V-
PE(+) Y+++ PGP-+++ R(+) !tv b++ DI D G+ e++ h! y-
-END GEEK CODE BLOCK-
Re: On Junctions
I stand corrected. That said: with the eigenstates method now private, it is now quite difficult to get a list of the eigenstates of the above expression. Yes, that's a concern. Most of the interesting junction-based algorithms I've developed in the past rely on two facilities: the ability to extract eigenstates, and the ability to thresh a junction: to determine which eigenstates caused a boolean expression involving the junction to be true. However, I suspect that if these two capabilities prove to be all(not easy, very useful) in Perl 6, there will soon be a module that facilitates them. ;-) Damian
Re: On Sets (Was: Re: On Junctions)
Daniel Ruoso wrote: The thing is that junctions are so cool that people like to use it for more things than it's really usefull (overseeing that junctions are too much powerfull for that uses, meaning it will lead to unexpected behaviors at some point). What are the general boundaries for junctions? We know that engineering type problems should be solved using floating point variables rather than integers (although it is probable that an integer solution probably would be possible - it would be excessively complicated). Perhaps, it might help to see some more examples of how junctions should be used? Regards, Richard
Junction Algebra
Included in my 'On junctions' message were some questions that have not
been directly answered. I simplify and expand them here.
Here I use === to mean 'is the same as'.
(I am not sure which of == or === should be used.)
1) Is the following true for an any junction?
any( ... , any('foo','bar')) === any(...,'foo','bar')
If yes, then
if an 'any' junction is contained in an outer 'any', the inner 'any' can
be factored out?
2) Also, is the following true for nested 'all' junctions? viz.
all(... , all('foo', 'bar')) === all(...,'foo','bar')
3) Conjecture: The following is true of all junction types, eg.,
junc(..., junc(...)) === junc(..., ...)
4) Are there any transformations of other nested junctions?
Richard
Re: On Junctions
Em Sáb, 2009-03-28 às 16:17 +1100, Damian Conway escreveu:
Nested heterogeneous junctions are extremely useful. For example, the
common factors of two numbers ($x and $y) are the eigenstates of:
all( any( factors($x) ), any( factors($y) ) )
I think that's the exact case where we should be using sets instead...
my $common_factors = factors($x) ∩ factors($y)
Assuming we have...
multi infix:∩(List @a, List @b -- Set) {...}
multi infix:∩(Set @a, Set @b -- Set) {...}
... and variants ...
But the semantics of sets are still somewhat blurry... there are some
possibilities:
1) Sets are in the same level as junctions, but have no collapsing and
allow you to get its values. The problem is if it autothreads on
method calls or not... It also makes $a $b confuse...
2) Set ~~ Any, and all the inteligence is made implementing multis,
it has the disadvantage that new operators will need to have
explicit implementations in order to get Set DWIMmery...
I have been unsure about that, but lately I'm mostly thinking option 2
is the sanest, which means we only get as much DWIMmery as explicitly
implemented (which may or may not be a good idea).
daniel
Re: On Sets (Was: Re: On Junctions)
Em Sáb, 2009-03-28 às 13:36 +0300, Richard Hainsworth escreveu:
Daniel Ruoso wrote:
The thing is that junctions are so cool that people like to use it for
more things than it's really usefull (overseeing that junctions are too
much powerfull for that uses, meaning it will lead to unexpected
behaviors at some point).
What are the general boundaries for junctions?
Junctions are superposition of values with a given collapsing type.
The most important aspect of junctions is that they are a singular
value, which means that they are transparent to the code using it. You
always use it as a singular value, and that's what keep its semantics
sane.
The boundary is where you try to use a junction as a plural value, and
that's where the semantics get weird...
Perhaps, it might help to see some more examples of how junctions should
be used?
They should be used as a singular value... which means that the
blackjack example is only a good example for junctions, as far as to
know if the user has busted.
my @hand = 1|11, 9, 1|11;
my $sum = [+] @hand;
if ($sum = 21) {
# valid game
} else {
# busted!
}
The semantic is sane that way because it doesn't make a difference if
there is a junction or not...
my @hand = 6, 9, 6;
my $sum = [+] @hand;
if ($sum = 21) {
# valid game
} else {
# busted!
}
But even to compare two hands it gets weird...
my @a = 1|11, 9, 1|11;
my @b = 6,9,6;
my $pa = [+] @a;
my $pb = [+] @b;
if ($pa = 21 $pb = 21) {
if ($pa $pb) {
# B0RK3D
}
}
That happens because $pa and $pb are a singular value, and that's how
junctions work... The blackjack program is an example for sets, not
junctions.
Now, what are junctions good for? They're good for situation where it's
collapsed nearby, which means, it is used in boolean context soon
enough. Or where you know it's not going to cause the confusion as in
the above code snippet.
Sets can provide the cool DWIMmery junction provides for the blackjack
case and still provide sane semantics for you to get its compound
values.
daniel
Re: On Junctions
On Fri, Mar 27, 2009 at 05:49:02PM -0400, Henry Baragar wrote:
I believe that there are hands where $p = 15|26 which would not beat a
hand where $d = 17.
I believe that the correct way to calculate the value of the hand is:
my $p = ([+] @p).map{.eigenstates}.grep{$_ 21}.max;
Since the result of [+] is a scalar we don't need to 'map' it.
Assuming that .eigenstates exists it would then be
my $p = ([+] @p).eigenstates.grep({ $_ 21 }).max
Pm
Re: On Junctions
Daniel Ruoso wrote: But the semantics of sets are still somewhat blurry... there are some possibilities: 1) Sets are in the same level as junctions, but have no collapsing and allow you to get its values. The problem is if it autothreads on method calls or not... It also makes $a $b confuse... 2) Set ~~ Any, and all the inteligence is made implementing multis, it has the disadvantage that new operators will need to have explicit implementations in order to get Set DWIMmery... I have been unsure about that, but lately I'm mostly thinking option 2 is the sanest, which means we only get as much DWIMmery as explicitly implemented (which may or may not be a good idea). My understanding is that Set operates on the same level as Hash and List - indeed, a Set could be thought of as a Hash that only cares about the keys but not the values, and has a few additional methods (i.e., the set operations). That is, a junction is an item with an indeterminate value; but a Set is a collection of values in the same way that a hash is. And the proper sigil for a Set is %, not $. -- Jonathan Dataweaver Lang
Re: On Sets (Was: Re: On Junctions)
HaloO, On Friday, 27. March 2009 12:57:49 Daniel Ruoso wrote: 1 - multi infix:+(Set $set, Num $a) This would return another set, with each value of $set summed with $a. I think that this mixed case should numify the set to the number of elements to comply with array semantics. infix:+ should remain a numeric operator and numify other operant types. This operator orientation is a strong feature of Perl 6 and should not be diluted by overloads with non-numeric meanings. 2 - multi infix:+(Set $a, Set $b) This would return another set, with $a.values X+ $b.values, already removing duplicated values, as expected from a set. Even the homogeneous case should adhere to numeric semantics. Set operations are with parens. So disjoint union creation is (+). We could try to get a meta parens so that (X+) is conceivably auto-generated. OTOH it collides with (+) visually. Regards, TSa. -- The unavoidable price of reliability is simplicity -- C.A.R. Hoare Simplicity does not precede complexity, but follows it. -- A.J. Perlis 1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
Re: On Junctions
Patrick R. Michaud wrote:
On Fri, Mar 27, 2009 at 05:49:02PM -0400, Henry Baragar wrote:
I believe that there are hands where $p = 15|26 which would not beat a
hand where $d = 17.
I believe that the correct way to calculate the value of the hand is:
my $p = ([+] @p).map{.eigenstates}.grep{$_ 21}.max;
Since the result of [+] is a scalar we don't need to 'map' it.
Assuming that .eigenstates exists it would then be
my $p = ([+] @p).eigenstates.grep({ $_ 21 }).max
Argh... the multiple personalities of the junction caused me to forget
that there is only one scalar! HB
Pm
Re: On Sets (Was: Re: On Junctions)
On Sat, Mar 28, 2009 at 6:39 AM, Daniel Ruoso dan...@ruoso.com wrote: Em Sáb, 2009-03-28 às 13:36 +0300, Richard Hainsworth escreveu: Daniel Ruoso wrote: The thing is that junctions are so cool that people like to use it for more things than it's really usefull (overseeing that junctions are too much powerfull for that uses, meaning it will lead to unexpected behaviors at some point). What are the general boundaries for junctions? Junctions are superposition of values with a given collapsing type. The most important aspect of junctions is that they are a singular value, which means that they are transparent to the code using it. You always use it as a singular value, and that's what keep its semantics sane. Closely related to this is that junctions autothread. If you type in foo($a | $b), it will be processed exactly as if you had typed foo($a) | foo($b) - that is, it will call foo twice, once for $a and once for $b, and it won't care which order it uses. And this is true whether or not you know that a junction is involved. Given 'foo($j)', foo will be called once if $j isn't a junction, and will be called multiple times if $j is a junction. If you were dealing with a Set instead, you'd need to make use of 'map' and/or hyperoperators to achieve a similar result. -- Jonathan Dataweaver Lang
Re: Junction Algebra
On Sat, Mar 28, 2009 at 02:08:22PM +0300, Richard Hainsworth wrote: 3) Conjecture: The following is true of all junction types, eg., junc(..., junc(...)) === junc(..., ...) The conjecture is false for one/none junctions: one(0, one(1, 1)) # true one(0, 1, 1) # false none(0, none(0, 0)) # false none(0, 0, 0) # true I'm still considering the any/all cases. Pm
Re: On Sets (Was: Re: On Junctions)
Thomas Sandlaß wrote: Set operations are with parens. Which Synopsis is this in? -- Jonathan Dataweaver Lang
Re: On Sets (Was: Re: On Junctions)
Daniel Ruoso wrote:
But even to compare two hands it gets weird...
my @a = 1|11, 9, 1|11;
my @b = 6,9,6;
my $pa = [+] @a;
my $pb = [+] @b;
if ($pa = 21 $pb = 21) {
if ($pa $pb) {
# B0RK3D
}
}
That happens because $pa and $pb are a singular value, and that's how
junctions work... The blackjack program is an example for sets, not
junctions.
The blackjack program is an excellent example for junctions (and not so
good for sets, IMHO). The problem in the example above is that the
calculation of the value of a hand was not completed. The complete
calculation is as follows:
my $pa = ([+] @a).eigenstates.grep{$_ 21}.max
If the result is undef, then the @a hand is a bust, and comparing $pa to
a similarly calculated $pb is sane.
Henry
daniel
Re: On Sets (Was: Re: On Junctions)
Henry Baragar wrote:
The blackjack program is an excellent example for junctions (and not so good
for sets, IMHO). The problem in the example above is that the calculation
of the value of a hand was not completed. The complete calculation is as
follows:
my $pa = ([+] @a).eigenstates.grep{$_ 21}.max
Per the recent change to the synopses, eigenstates is now a private
method, rendering the above code invalid.
--
Jonathan Dataweaver Lang
Re: Grammars that generate stuff
On Sat, Mar 28, 2009 at 1:48 AM, Timothy S. Nelson wayl...@wayland.id.auwrote: Perl 6 has a general language (grammars) for taking some input and a grammar, and separating the data from the formatting, as it were. Ideally, it'd be possible to specify one grammar that would act both for parsing output and formatting input. This may not be possible, but I like the idea. Tim, Regarding generative/transforming grammars, you may get some good syntax/architecture ideas from the OMeta language system see http://www.tinlizzie.org/ometa-js/#Sample_Project for a selection of browser-based examples... (it's also the subversion repo). Also if you don't mind things Microsoft, there's the (part of Oslo) M language family. -Matthew
Re: Junction Algebra
On Sat, Mar 28, 2009 at 10:19:31AM -0500, Patrick R. Michaud wrote: On Sat, Mar 28, 2009 at 02:08:22PM +0300, Richard Hainsworth wrote: 3) Conjecture: The following is true of all junction types, eg., junc(..., junc(...)) === junc(..., ...) The conjecture is false for one/none junctions: one(0, one(1, 1)) # true one(0, 1, 1) # false Boy, I typoed that one. I meant to write: one(1, one(1, 1)) # true one(1, 1, 1)# false Pm
