Programming languages and copyright?
Hello, Does anyone know if programming languages are protected by copyright or not? When creating a new program, you are not allowed to pick-and-choose what you want from other programs sources as that would be a copyright violation. But when creating a new programming language, it seems that everyone is picking-and-choosing what they want from other programming languages. So I'd like to ask whether this is legal or not and why? -- Markus Laire
Re: Programming languages and copyright?
On 10/23/06, Smylers [EMAIL PROTECTED] wrote: Markus Laire writes: Does anyone know if programming languages are protected by copyright or not? Code can be copyrighted; ideas can't be. Yes, but the syntax of the programming language is more than just an idea. Copyright-article[1] at Wikipedia says that Copyright is a set of exclusive rights regulating the use of a particular expression of an idea or information. So, for example, the idea of look-behind assertions can't be copyrighted as it's an idea. But what about a particular form chosen to express that idea (e.g. to use before pattern to denote look-behind)? Can this be copyrighted as it's more than just an idea? [1] http://en.wikipedia.org/wiki/Copyright ps. I'm asking this because I'm thinking of creating a (simple) programming language by myself, but I'm unsure about how much syntax I could copy from any existing programming languages. -- Markus Laire
Re: S5: substitutions
On 10/9/06, Jonathan Lang [EMAIL PROTECTED] wrote:
Smylers wrote:
To be consistent your proposal should also suggest that these become
equivalent:
* { function() }
* qq[ {function() }]
* qq{ function() }
* eval function()
How so? AFAIK, string literal syntax requires you to prepend a sigil
on the front of any embedded closure that you want to interpolate a
value from; otherwise, it isn't a closure - it's just a pair of
curly-brace characters. My proposal isn't curly braces _always_ act
like closures, no matter what; it's the second part of a s[]
construct doesn't have to be a literal; it can be anything that can be
evaluated as needed by the algorithm to provide substitute text.
According to S02 bare curlies do interpolate in double-quoted strings:
S02 =item *
S02
S02 A bare closure also interpolates in double-quotish context. It may
S02 not be followed by any dereferencers, since you can always put them
S02 inside the closure. The expression inside is evaluated in scalar
S02 (string) context. You can force list context on the expression using
S02 the Clist operator if necessary.
--
Markus Laire
if-else and statement-ending blocks?
S04 says:
A line ending with a closing brace }, followed by nothing but whitespace or
comments, will terminate a statement if an end of statement can occur there.
That is, these two statements are equivalent:
my $x = sub { 3 }
my $x = sub { 3 };
Does this mean that
if $foo == 123 {
...
}
else {
...
}
is same as
if $foo == 123 {
...
}; # -- notice the semicolon here
else {
...
}
because if-statement could end there.
--
Markus Laire
Re: Nested statement modifiers.
On 10/3/06, Aaron Sherman [EMAIL PROTECTED] wrote: Paul Seamons wrote: It relates to some old problems in the early part of the RFC/Apocalypse process, and the fact that: say $_ for 1..10 for 1..10 Was ambiguous. The bottom line was that you needed to define your parameter name for that to work, and defining a parameter name on a modifier means that you have to parse the expression without knowing what the parameters are, which is ugly in a very non-stylistic sense. I don't think that is ambiguous though. It really is, and the very first question that everyone asks is: how do I get access to the outer loop variable, which of course, you cannot for the reasons stated above. What about $OUTER::_ ? Shouldn't that access the outer $_ ? Let's get P6 out the door, and then discuss what tiny details like this do or don't make sense. -- Markus Laire
Re: Nested statement modifiers.
On 10/4/06, Juerd [EMAIL PROTECTED] wrote:
Damian Conway skribis 2006-10-03 16:40 (-0700):
Which can also be written as:
do { do { say 1 if 1 } if 1 } if 1;
Sorry, no it can't. From S4
(http://dev.perl.org/perl6/doc/design/syn/S04.html#The_repeat_statement):
Unlike in Perl 5, applying a statement modifier to a do block is
specifically disallowed
Oh. For some reason, I thought this exception was for loops only.
According to S04 Cdo { ... } is a loop, The do-once loop.
--
Markus Laire
Re: [svn:perl6-synopsis] r12346 - doc/trunk/design/syn
On 9/23/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: @args = [EMAIL PROTECTED],1,2,3; -push [,] @args;# same as push @foo,1,2,3 +push [,] @args;# same as push(@foo: 1,2,3) I don't quite understand this. Shouldn't C[,] @args be equivalent to C[EMAIL PROTECTED],1,2,3 just as C[+] 0,1,2,3 is equivalent to C0+1+2+3? So why is there C: instead of C, after C@foo? Does this have something to do with the fact that C@args is C[EMAIL PROTECTED],1,2,3 and not C@foo,1,2,3? -- Markus Laire
Re: [svn:perl6-synopsis] r12346 - doc/trunk/design/syn
On 9/23/06, Audrey Tang [EMAIL PROTECTED] wrote: 在 Sep 23, 2006 8:36 PM 時，Markus Laire 寫到： On 9/23/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: @args = [EMAIL PROTECTED],1,2,3; -push [,] @args;# same as push @foo,1,2,3 +push [,] @args;# same as push(@foo: 1,2,3) I don't quite understand this. Shouldn't C[,] @args be equivalent to C[EMAIL PROTECTED],1,2,3 just as C[+] 0,1,2,3 is equivalent to C0+1+2+3? So why is there C: instead of C, after C@foo? Does this have something to do with the fact that C@args is C[EMAIL PROTECTED],1,2,3 and not C@foo,1,2,3? Exactly. Per this interpretation, [EMAIL PROTECTED] is shorthand for \(@foo :), and I think that this shorthand should be mentioned somewhere. From some of the examples I thought that C[EMAIL PROTECTED], @bar would be equivalent to C\(@foo, @bar) [,] would first flatten the contents of @arg, and then process each one; if an element is Capture, it is joined into the current arglist; if it's not, then it's made a simple positional. I wasn't sure about this treatment, so I checked on #perl6 with Larry; an alternative is to treat the elements of @foo always as positional arguments, but that will make the two [,] calls below nonequivalent: my @args = [EMAIL PROTECTED], 1, 2, 3; [,] @args; [,] [EMAIL PROTECTED], 1, 2, 3; I'd prefer to make them equivalent, on the principle that all listops conceptually flatten+concat their arguments first, and then process each element regardless of its origin. Thanks, Audrey -- Markus Laire
Is [,] different from other Reduction operators?
S06 says: =head2 Flattening argument lists The reduce operator C[,] casts each of its arguments to a CCapture object, then splices each of those captures into the argument list it occurs in. The unary C| sigil has the same effect on a single argument. ... Does this mean that [,] is a special Reduction operator and doesn't work in the same way as other Reduction operators do? I don't quite understand what [,] actually does, but it seems to be so special that IMHO it shouldn't be a Reduction operator at all but something totally different. As an example, C[+](1,2,3) is same as C1+2+3 so IMHO C[,](1,2,3) should be same as C1,2,3 but S06 says that it becomes C\(1,2,3). -- Markus Laire
Re: call, call(), .call, and captures
On 9/20/06, Aaron Sherman [EMAIL PROTECTED] wrote: Larry Wall wrote: What we really need is a unary operator that is sugar for [,](=(...)). Just don't anyone suggest *. :-) I was thinking about that. I wonder if [\] would make sense, or is that just begging to have in-editor parsers fall over screaming ;) That would be quite close to [\+] [\,] etc.. from S03: S03 say [\+] 1..* # (1, 3, 6, 10, 15, ...) -- Markus Laire
any(@originals) ~~ { .foo eq $bar} (was Re: renaming grep to where)
On 9/19/06, Trey Harris [EMAIL PROTECTED] wrote:
In a message dated Mon, 18 Sep 2006, Darren Duncan writes:
@filtered = @originals.where:{ .foo eq $bar };
Note that this can be written:
@filtered = any(@originals) ~~ { .foo eq $bar};
This doesn't seem to be correct.
According to S03 junctions thread through operations, returning
another junction representing the result. Instead of returning the
filtered values, this seems to allways return one of
any(Bool::False) # If all comparisons were false
any(Bool::True) # If all comparisons were true
any(Bool::False, Bool::True) # If some comparisons were false and some true
Testing a concrete example in pugs (r13034):
pugs my @a = (1..10);
(1, 2, 3, 4, 5, 6, 7, 8, 9, 10)
pugs any(@a) ~~ { $_ 0 }
(Bool::False)
pugs any(@a) ~~ { $_ 0 }
(Bool::True)
pugs any(@a) ~~ { $_ % 2 }
(Bool::False | Bool::True)
--
Markus Laire
Re: multi subs with identical signatures: should be a warning ?
Since nobody else has answered yet, I'll try to say something.
I'll post this also to perl6-language so that those who know better
can comment on this.
On 8/28/06, Mark Stosberg [EMAIL PROTECTED] wrote:
First, what's the recommended reference for learning how dispatching to
the right 'multi' sub is resolved. ?
http://dev.perl.org/perl6/doc/synopsis.html
S12 seems most relevant (e.g. the section Multisubs and Multimethods)
S06 might also be relevant
I'd like to know the expected behavior in this case:
multi sub foo () { say b: }
multi sub foo () { say a: }
foo();
I would expect it would throw an error or at least a warning, since
there's no clear way to choose a correct sub to dispatch to.
IMHO this is either the case where you define same sub twice, which is
an error (and so foo() would never get called) according to S06:
quote
Redefining a stub subroutine does not produce an error, but redefining
an already-defined subroutine does. If you wish to redefine a defined
sub, you must explicitly use the is instead trait.
/quote
or, if not that case, then this is defining two multi-subs which have
the same long-name. According to S12 the later multi-sub will then
hide the earlier one, and foo() would then allways call the second
multi-sub, saying a:
quote
For subs or methods declared multi, only one instance of the long name
can be in any namespace, and it hides any outer (or less-derived)
routines with the same long name.
/quote
Pugs currently dispatches to one anyway, without a warning.
If Pugs allways dispatches to the second one, then this might be the
right behaviour.
A more insidious version of the same case is the following, which
I accidentally wrote more than once already...and then wondered why
my code wasn't working as expected...
multi sub foo (%names?) { say b: }
multi sub foo (@pos?) { say a: }
There, I have distinct arguments, but they are both optional, making
them the same as the case above.
This isn't exactly the same as above. In this case the two multi-subs
just might have different long-names and so one would not hide the
another.
I'm not 100% sure about whether these have different long-name or
not as I don't know how exactly the long-name is created.
If I'm right that these do have different long-name then IMHO the
call to foo() would throw an exception because there's a tie between
two equally-good candidates for multi-dispatch and S12 says that in
such a case an exception is thrown:
quote
When you call a routine with a particular short name, if there are
multiple visible long names, they are all considered candidates. They
are sorted into an order according to how close the run-time types of
the arguments match up with the declared types of the parameters of
each candidate. The best candidate is called, unless there's a tie, in
which case the tied candidates are redispatched using any additional
tiebreaker long names (see below).
If a tie still results, only candidates marked with the default trait
are considered, and the best matching default routine is used. If
there are no default routines, or if the available defaults are also
tied, a final tie-breaking proto sub is called, if there is one (see
above). Otherwise an exception is thrown.
/quote
--
Markus Laire
Re: [svn:perl6-synopsis] r11504 - doc/trunk/design/syn
On 8/28/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
+Elsewhere it is equivalent to a parenthesisized list of strings:
+C ('foo','bar') . Since parentheses are generally reserved just for
+precedence grouping, they merely autointepolate in list context. Therefore
+
+@a = 1, 2 3 , 4;
+
+is equivalent to
+
+@a = 1, 2, 3, 4;
Shouldn't this be
@a = 1, '2', '3', 4;
--
Markus Laire
Re: [svn:perl6-synopsis] r11115 - doc/trunk/design/syn
On 8/18/06, Larry Wall [EMAIL PROTECTED] wrote: On Fri, Aug 18, 2006 at 12:56:30PM +0300, Markus Laire wrote: : What about combined short switches like C-abc to mean C-a -b -c? : Will perl6 support this notation or not? Hmm, that opens up a world of hurt. Either you have to distinguish a --abc from -abc, or you have to have some kind of fallback heuristic, and it doesn't work terribly well with arguments in any case except for the final one. Should probably make it possible, just because the external interface is one of the places where Perl has always tried to be accommodating to existing culture rather than revisionist. We can probably work something out here, along the lines of: if there's only one - if single character aliases are defined if the word matches that alphabet if the word doesn't match any longer names At first I was inclined to say that if there's a *% then all the unrecognized go in there and you can parse the -abc yourself, but that doesn't tell you how to treat the next argument unless we look at the definition of -c anyway. We can't just say that -c's arg must use the -c=arg form, since even Perl 5 violates that with -e. :/ Larry Yep, I understand it's not an easy question. Still I was thinking of behaviour where C-abc would allways mean C-a -b -c regardless of what 1-char aliases or longer names have been defined. This would make --abc and -abc mean completely different things. And in this proposal only the last switch would be able to get an argument, e.g. with C-abc=99 or C-abc 99 or something like that. If this can't be the default behaviour, then it would be nice to be able to easily switch to this kind of behaviour. ps. Then there's the perl5-behaviour of perl -n0e unlink where also the intervening switches can get arguments. This could be expanded so that all chars for which there's no 1-char alias defined, are parameters. So C-aHellobWorld would mean C-a=Hello -b=World if there are 1-char aliases only for a b. ;) -- Markus Laire
Re: === and array-refs
On 8/17/06, Darren Duncan [EMAIL PROTECTED] wrote: Generally speaking, the direct use of === is more for specialized purposes, somewhat like the direct use of =:= is. If one can't tell the difference between === and eqv, they most likely want snapshot semantics anyway, and so might as well forget === exists, and just use eqv everywhere. For me === feels like it should be the operator with easier semantics, i.e. the operator which perl-newbies would first want to learn, so it feels like the semantics of === and eqv should be swapped. === is a lot nearer to what many other languages uses for they comparison than more cryptic eqv. Also, == does simpler comparison than eq, so I feel that === should also do simpler (to understand) comparison than eqv -- Markus Laire
Re: === and array-refs
On 8/16/06, Darren Duncan [EMAIL PROTECTED] wrote: Both the === and eqv operators test the actual values of 2 containers, but that their semantics differ in regards to mutable containers. Given an immutable container/type, such as a number or Str or Seq, both will always return true if the values are the same. With a mutable container, such as an Array, only eqv will return true if the value is the same, and === will return false for 2 containers having the same value. The difference between === and eqv is that, if you have 2 symbols, $a and $b, and $a === $b returns true, then that result is guaranteed to be eternal if you don't assign to either symbol afterwards. For a mutable type like an Array, === returns false on 2 containers because it can't guarantee that someone else holding another symbol for either container won't change its content, and so $a or $b could change after we made the === test, without us causing that to happen, and so for mutable types, === only returns true for 2 aliases, because that is the most it can guarantee that they will be the same. By contrast, eqv does not make the eternal guarantee, and works only on snapshots, so eqv can safely deep-compare mutable types like Arrays, since even if one of them changes afterwards, it doesn't matter, since eqv only guaranteed them equal for that point in time when it executed. So do you mean that this code $a = One; $b = One; $aa := $a; say Same before if $a === $b; $aa = Two; say Same after if $a === $b; would print Same before Same after because here I have 2 symbols, $a and $b, and $a === $b returns true and I don't assign to either symbol afterwards - and you seem to be saying that only with mutable types like Array can you change the contents via another symbol ($aa here). But according to S03 this would only print Same before, because the assigment to $aa would change $a quote A new form of assignment is present in Perl 6, called binding, used in place of typeglob assignment. It is performed with the := operator. Instead of replacing the value in a container like normal assignment, it replaces the container itself. For instance: my $x = 'Just Another'; my $y := $x; $y = 'Perl Hacker'; After this, both $x and $y contain the string Perl Hacker, since they are really just two different names for the same variable. /quote -- Markus Laire
Re: === and array-refs
On 8/16/06, Dr.Ruud [EMAIL PROTECTED] wrote: Markus Laire schreef: my $x = 'Just Another'; my $y := $x; $y = 'Perl Hacker'; After this, both $x and $y contain the string Perl Hacker, since they are really just two different names for the same variable. /quote So $x === Sy stil holds. Exactly, and because of that $a === $b does NOT hold in my example. ($a would be Two, $b would be One) -- Markus Laire
Re: === and array-refs
On 8/16/06, Darren Duncan [EMAIL PROTECTED] wrote: I'll try saying what I meant differently here: The difference between === and eqv is that, if you have 2 symbols, $a and $b, and $a === $b returns true, then that result is guaranteed to be eternal if you don't assign to either symbol [or other symbols aliased to either] afterwards. The idea is that, the degree to which === examines 2 variables to consider them equal or not is only so far as they are immutable. So if you say $foo = $bar, and then $baz === $foo returns true, then a subsequent assignment to or type-allowed mutation of $bar won't invalidate that $baz === $foo, but an assignment to $foo would. IMHO the text a subsequent assignment to or is useless here because I don't think any subsequent assignment to $bar could ever affect $foo, even if they were mutable types: $bar = [1,2]; $foo = $bar; ... $bar = 123; # This doesn't affect $foo Of course, type-allowed mutation of $bar will affect $foo if $bar is mutable type. Still, thanks for clarification - I misunderstood what you meant with someone else holding another symbol. -- Markus Laire
Re: [svn:perl6-synopsis] r10804 - doc/trunk/design/syn
On 8/11/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
+To return from other types of code structures, the Cleave function
+is used. The first argument, if supplied, specifies a CSelector
+for the control structure to leave. The CSelector and will be
+smart-matched against the dynamic scope objects from inner to outer.
+The first that matches is the scope that is left.
s/and //
+As with module and class declarations, a sub or method declaration
+ending in semicolon is allowed at the outermost file scope if it is the
+first such declaration, in which case the rest of the file is the body:
+
+sub MAIN ($directory, :$verbose, *%other, [EMAIL PROTECTED]);
+for @filenames { ... }
+
+Proto or multi definitions may not be written in semicolon form,
+nor may CMAIN subs within a module or class. (A CMAIN routine
+is allowed in a module or class, but is not usually invoked unless
+the file is run directly (see a above). This corresponds to the
+unless caller idiom of Perl 5.) In general, you may have only one
+semicolon-style declaration that controls the whole file.
Should the following text now be removed from S06:
--- S06.pod.orig2006-08-11 11:50:46.0 +0300
+++ S06.pod 2006-08-11 11:51:08.0 +0300
@@ -159,14 +159,6 @@
sub foo {...} # Yes, those three dots are part of the actual syntax
-The old Perl 5 form:
-
-sub foo;
-
-is a compile-time error in Perl 6 (because it would imply that the body of the
-subroutine extends from that statement to the end of the file, as Cclass and
-Cmodule declarations do).
-
Redefining a stub subroutine does not produce an error, but redefining
an already-defined subroutine does. If you wish to redefine a defined sub,
you must explicitly use the Cis instead trait.
--
Markus Laire
Re: [svn:perl6-synopsis] r10477 - doc/trunk/design/syn
Modified: doc/trunk/design/syn/S06.pod -Note that all such pipes (and indeed all lazy argument lists) supply +Note that all such feed (and indeed all lazy argument lists) supply s/feed/feeds/ -Piping to the C* whatever term is considered a pipe to the lexically +Piping to the C* whatever term is considered a feed to the lexically Piping should probably be changed to something else. -- Markus Laire
Re: S04 - forbidden coding-style
On 7/25/06, Thomas Wittek [EMAIL PROTECTED] wrote: Bearing that in mind, would the eye-socket-burning return $foo IF $something; really be so bad? Operators/reserved words should be lowercase. Period. ;) I think that this would heavily break consistency, annoying new users. There are already many uppercase reserved words in perl6: Pseudo-packages from S02 MY, OUR, GLOBAL, OUTER, CALLER, CONTEXT, SUPER, COMPILING Closure traits from S04 BEGIN, CHECK, INIT, END, FIRST, ENTER, LEAVE, KEEP, UNDO, NEXT, LAST, PRE, POST, CATCH, CONTROL From S10 AUTODEF, CANDO Submethods from S12 BUILD, BUILDALL, CREATE, DESTROY, DESTROYALL Pseudo-class from S12 WALK I might've missed some. So making statement modifiers uppercase would just be an another place where perl6 uses uppercase reserved words. -- Markus Laire
Re: S04 - forbidden coding-style
On 7/20/06, Smylers [EMAIL PROTECTED] wrote:
Markus Laire writes:
S04 seems to say that a style like this can't be used by
perl6-programmers:
loop
{
...
}
while $x;
I like this style, as it lines up both the keywords and the curlies.
As of yesterday you can get very close to this by putting a space-eating
backslash after the closing brace:
loop
{
...
}\
while $x;
That still has the keywords and the braces aligned.
Yes. First I didn't like that additional slash, but now that I think
it more, it does give a nice visual clue that Cwhile belongs to the
preceding block.
(And that doesn't affect auto-indenting in vim)
--
Markus Laire
S04 - forbidden coding-style
This quote from S04
quote
Outside of any kind of expression brackets, a final closing curly on a
line (not counting whitespace or comments) always reverts to the
precedence of semicolon whether or not you put a semicolon after it.
(In the absence of an explicit semicolon, the current statement may
continue on a subsequent line, but only with valid statement
continuators such as else. A modifier on a loop statement must
continue on the same line, however.)
/quote
seems to say that a style like this can't be used by perl6-programmers:
loop
{
...
}
while $x;
I'd like to ask if it's necessary to make this programming-style
invalid for perl6? This style is used at least by GNU Coding
Standards (section 5.1) at
http://www.gnu.org/prep/standards/standards.html
I also like this style, as it lines up both the keywords and the curlies.
--
Markus Laire
Re: [svn:perl6-synopsis] r9733 - doc/trunk/design/syn
On 7/1/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: +But parens are special that way. (Even Cq() is assumed to be a +function call rather than a quote.) Other bracketing characters are +special only if they can be mistaken for adverbial arguments, so qn[stuff] -is fine, while +is fine, and means + +q:n /stuff/ + +while Since quotes can have whitespace before the first/opening delimiter, but functions can't (according to S03), how is Cq () parsed? (Notice the space before parens). Would that be parsed as invalid function-call (i.e. syntax error) or valid quote? -- Markus Laire
Re: [svn:perl6-synopsis] r9727 - doc/trunk/design/syn
On 7/1/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: +In particular, these forms disable the lookahead for an adverbial argument, +so while + +q:n($foo) + +will misinterpret C$foo as the C:n argument, + +qn(stuff) + +has the advantage of misinterpreting it as the argument to the Cqn() +function instead. C:) + +But parens are special that way. Other bracketing characters are special +only if they can be mistaken for adverbial arguments, so + +qn[stuff] + +is fine, while + +q:n[stuff] + +is not. Basically, just don't use parens for quote delimiters, and always +put a space after your adverbs. Why q:n[stuff] is not fine? Shouldn't that pass [stuff] to adverb n? Also, in what way are parens special? Doesn't qn(stuff) and qn[stuff] both mean same thing? And both q:n(stuff) and q:n[stuff] pass something to adverb n. (First passes stuff, second passes [stuff]) -- Markus Laire
Can foo(123) dispatch to foo(Int) (was: Mutil Method Questions)
I'm sending this also to perl6-language, in case someone there knows
an answer to this.
On 6/23/06, Jonathan Scott Duff [EMAIL PROTECTED] wrote:
I don't think so. I think the best candidate prose is about
choosing from types that have been specified, not autoconverting
between types such that one of them will match the long name. In
other words, when you have
multi sub foo (Num) { ... }
multi sub foo (Int) { ... }
foo(1);
foo(123);
foo(bar);
foo(Int) is the best candidate for the first one because 1 is an Int.
But in the second and third calls, there is no best candidate
because strings were passed. Would you expect the third call to
succeed because bar can be converted into the number 0?
I think you are right, but I don't see that mentioned anywhere in Synopses.
S12 clearly says that for a particular short name (foo here) *all*
visible long names (foo(Num) and foo(Int) here) are candidates and
best candidate *is* called (no matter how bad it is) -- unless there's
a tie.
So that would seem to say that for foo(123) above foo(Int) would be
called because it's the best candidate.
Which one is better for foo(bar)? foo(Int) or foo(Num)? Or is that a tie?
And what about other types?
e.g. if String can't ever be best candidate for Int, then does that
mean that neither can Int ever be best candidate for Num, because
they are different types?
The programmer put type information in the sig for a reason. I think
that reason is that they wanted to be careful about what was allowed
to be passed to the subroutine. Autoconversion seems to defeat that.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
--
Markus Laire
Re: [svn:perl6-synopsis] r9216 - doc/trunk/design/syn
On 5/13/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Argumentless C** in a multi-dimensional subscript indicates 0 or -more dimensions of C* where the number of dimension isn't necessarily -known: C@foo[1;**;5]. It has a value of CList of Any, or something -like that. The argumentless C* and C** forms are probably only -useful in dimensional list contexts. Is there any new format to do the equivalent of C@foo[1;**;5], or is that impossible nowadays? -- Markus Laire
Re: Scans
On 5/10/06, Austin Hastings [EMAIL PROTECTED] wrote: Mark A. Biggar wrote: Use hyper compare ops to select what you want followed by using filter to prune out the unwanted. filter gives you with scan: filter (list [] @array) @array == first monotonically increasing run in @array This seems false. @array = (1 2 2 1 2 3), if I understand you correctly, yields (1 2 2 3). No, it yields (1, 2, 2) list [] @array == list [] (1, 2, 2, 1, 2, 3) == 1, 1 2, 1 2 2, 1 2 2 1, 1 2 2 1 2, 1 2 2 1 2 3, == Bool::True, Bool::True, Bool::True, Bool::False, Bool::False, Bool::False And so filter (list [] @array) @array would give first 3 elements of @array, i.e. (1, 2, 2) filter (list [=] @array) @array == first monotonically non-decreasing run in @array So @array = (1 0 -1 -2 -1 -3) == (1, -1) is monotonically non-decreasing? This would give (1, 0, -1, -2) list [=] (1, 0, -1, -2, -1, -3) == 1, 1 = 0, 1 = 0 = -1, 1 = 0 = -1 = -2, 1 = 0 = -1 = -2 = -1, 1 = 0 = -1 = -2 = -1 = -3 == Bool::True, Bool::True, Bool::True, Bool::True, Bool::False, Bool::False And so filter (list [=] @array) @array would give first 4 elements of @array, i.e. (1, 0, -1, -2) -- Markus Laire
Re: Scans
In the previous mail I accidentally read [=] as [=] On 5/10/06, Markus Laire [EMAIL PROTECTED] wrote: filter (list [=] @array) @array == first monotonically non-decreasing run in @array So @array = (1 0 -1 -2 -1 -3) == (1, -1) is monotonically non-decreasing? This would give (1, 0, -1, -2) Correction: This would give (1) list [=] (1, 0, -1, -2, -1, -3) == 1, 1 = 0, 1 = 0 = -1, 1 = 0 = -1 = -2, 1 = 0 = -1 = -2 = -1, 1 = 0 = -1 = -2 = -1 = -3 == Bool::True, Bool::True, Bool::True, Bool::True, Bool::False, Bool::False Correction: Bool::True, Bool::False, Bool::False, Bool::False, Bool::False, Bool::False And so filter (list [=] @array) @array would give first 4 elements of @array, i.e. (1, 0, -1, -2) Correction: It would give only first element of @array, i.e. (1) -- Markus Laire
Re: Scans
On 5/9/06, Jonathan Scott Duff [EMAIL PROTECTED] wrote: On Tue, May 09, 2006 at 06:07:26PM +0300, Markus Laire wrote: ps. Should first element of scan be 0-argument or 1-argument case. i.e. should list([+] 1) return (0, 1) or (1) I noticed this in earlier posts and thought it odd that anyone would want to get an extra zero arg that they didn't specify. My vote would be that list([+] 1) == (1) just like [+] 1 == 1 Yes, that was an error on my part. I mis-read the example from Juerd as giving 0 arguments for first item, while it gives the 0th argument of an array. I (now) agree that it doesn't seem to be usefull to include the 0-argument case. -- Markus Laire
Re: Scans
On 5/9/06, Smylers [EMAIL PROTECTED] wrote: But this could just be because I don't (yet) grok scans. Here's a simple example: [+] 1,2,3,4,5 would return scalar 1+2+3+4+5 as a reduction and list (0, 1, 1+2, 1+2+3, 1+2+3+4, 1+2+3+4+5) as a scan. (0 comes from [+](), i.e. [+] with no arguments) -- Markus Laire
Re: Scans
On 5/9/06, Austin Hastings [EMAIL PROTECTED] wrote: Gaal Yahas wrote: I love this idea and have implemented it in r10246. One question though, what should a scan for chained ops do? list [==] 0, 0, 1, 2, 2; # bool::false? # (bool::true, bool::true, bool::false, bool::false, bool::false) Keeping in mind that the scan will contain the boolean results of the comparisons, you'd be comparing 2 with true in the later stages of the scan. Is that what you intended, or would ~~ be more appropriate? This code list [==] 0, 0, 1, 2, 2; would expand to [==] 0, 0 == 0, 0 == 0 == 1, 0 == 0 == 1 == 2, 0 == 0 == 1 == 2 == 2 which gives Bool::True, Bool::True, Bool::False, Bool::False, Bool::False So you don't compare 2 to true in any stage. ps. Should first element of scan be 0-argument or 1-argument case. i.e. should list([+] 1) return (0, 1) or (1) -- Markus Laire
S09: Single typo postfix ...
There is a typo in S09 (patch included) Also, S09 uses postfix ... to mean ..Inf but S03 uses ..* for this, so one of these should likely be changed unless both are OK. -- Markus Laire patch-S09 Description: Binary data
Re: A shorter long dot
On 5/1/06, Paul Johnson [EMAIL PROTECTED] wrote:
Maybe you all write your code differently to me, but looking through a
load of my OO code I had trouble finding three method calls in a row to
any methods on any objects, let alone six calls to the same method name
on different objects.
If I saw code like
$xyzzy.foo();
$fooz\.foo();
$foo\ .foo();
$fa\ .foo();
$and_a_long_one_I_still_want_to_align\
.foo();
$etc\ .foo();
I'd probably take that as a pretty strong clue that I should really have
written
$_.foo for @things_to_foo;
or something.
I like lining up my code as much as the next programmer, and probably a
lot more, but I just don't see the need for this syntax which seems
ugly, confusing and unnecessary.
But then again, as I said, I really don't see the problem that is being
solved.
This long-dot can be used for many things, not just method calls.
IMHO This example from S03 is a lot better:
quote
Whitespace is no longer allowed before the opening bracket of an array
or hash accessor. That is:
%monsters{'cookie'} = Monster.new; # Valid Perl 6
%people {'john'} = Person.new; # Not valid Perl 6
One of the several useful side-effects of this restriction is that
parentheses are no longer required around the condition of control
constructs:
if $value eq $target {
print Bullseye!;
}
while 0 $i { $i++ }
It is, however, still possible to align accessors by explicitly using
the long dot syntax:
%monsters.{'cookie'} = Monster.new;
%people\ .{'john'} = Person.new;
%cats\ .{'fluffy'} = Cat.new;
/quote
--
Markus Laire
Linking Synopses to corresponding pod-files?
When reading Synopses, I sometimes notice some mistakes or typos, which I'd like to submit a patch for, but it's not easy to do so as I don't know where to get the source. Could each Synopsis include a link to the corresponding .pod (if it's available in Internet, that is), so that submitting patches would be easier? -- Markus Laire
Re: Linking Synopses to corresponding pod-files?
On 5/4/06, Juerd [EMAIL PROTECTED] wrote: Markus Laire skribis 2006-05-04 14:55 (+0300): When reading Synopses, I sometimes notice some mistakes or typos, which I'd like to submit a patch for, but it's not easy to do so as I don't know where to get the source. Have you tried s/html/pod/? :) Thanks :) -- Markus Laire
Re: A shorter long dot
On 5/4/06, Paul Johnson [EMAIL PROTECTED] wrote:
On Thu, May 04, 2006 at 01:56:44PM +0300, Markus Laire wrote:
Thanks for taking the time to explain this. The long dot here does seem to be
solving more important problems. Now I'm not as up to date with Perl 6 syntax
as I once was, nor as much as I probably should be to be part of this thread,
but ...
IMHO This example from S03 is a lot better:
quote
Whitespace is no longer allowed before the opening bracket of an array
or hash accessor. That is:
%monsters{'cookie'} = Monster.new; # Valid Perl 6
%people {'john'} = Person.new; # Not valid Perl 6
What does Not valid Perl 6 mean? A syntax error? Is it not possible
to make it valid and to mean what would be meant without the whitespace?
Yep, I think it's syntax error.
Note that {} here is a postfix (actually postcircumfix) operator, and
the decision to never allow whitespace before postfix operators seems
to be quite fundamental in perl6.
Some relevant sections from Synopses:
(These sections are quite long, so I'm not copy-pasting them here.)
From Synopsis 2 at http://dev.perl.org/perl6/doc/design/syn/S02.html
See the section starting with In general, whitespace is optional in
Perl 6 except
From Synopsis 3 at http://dev.perl.org/perl6/doc/design/syn/S03.html
See the section starting with List operators are all parsed consistently.
And Synopsis 4 at http://dev.perl.org/perl6/doc/design/syn/S04.html
is also related to this.
However, I'm really not looking to drive perl6-language round in circles, so if
there is some document somewhere explaining the rest of the several useful
side-effects I'd love a pointer to it (I couldn't find anything appropriate).
Have you *recently* read the Synopses at
http://dev.perl.org/perl6/doc/synopsis.html
I'm currently re-reading them, and if you have some time (few days or
weeks :), I'd suggest reading them all.
--
Markus Laire
Re: S5 - Question about repetition qualifier
On 4/26/06, Joe Gottman [EMAIL PROTECTED] wrote:
According to Synopsis 5, the repetition qualifier is now **{.} where the .
must correspond to either an Int or a Range. This seems rather restrictive.
Why are we not allowed a junction of Ints, for instance
S05 also says:
quote
It is illegal to return a list, so this easy mistake fails:
/ [foo]**{1,3} /
(At least, it fails in the absence of use rx :listquantifier, which is
likely to be unimplemented in Perl 6.0.0 anyway).
/quote
So it seems only reason not to allow lists is that they aren't yet
implemented, and likely won't be for some time.
Also, I don't know exactly what the syntax looks like, but I can imagine
using a repetition qualifier that takes a closure of some sort, for instance
to match an odd number of repetitions
m/^ a**{($_ % 2 == 0)} $/; #I'm not sure about the syntax for the code.
Are you reading some old version of S05?
http://dev.perl.org/perl6/doc/design/syn/S05.html says that The
repetition specifier is now **{...} for maximal matching, with a
corresponding **{...}? for minimal matching. Space is allowed on
either side of the asterisks. The curlies are taken to be a closure
returning an Int or a Range object.
So you can just put any closure which returns Int or Range directly
within the curlies.
--
Markus Laire
S05: Interpolated hashes?
In Synopsis 5 (version 22), Under Variable (non-)interpolation it's said that quote An interpolated hash matches the longest possible key of the hash as a literal, or fails if no key matches. (A key will match anywhere, provided no longer key matches.) /quote And under Extensible metasyntax (...) it's said that quote With both bare hash and hash in angles, the key is counted as matched immediately; that is, the current match position is set to after the key token before calling any subrule in the value. That subrule may, however, magically access the key anyway as if the subrule had started before the key and matched with KEY assertion. That is, $KEY will contain the keyword or token that this subrule was looked up under, and that value will be returned by the current match object even if you do nothing special with it within the match. /quote I don't quite understand how these relate to each other. First text is clear enough, but second seems to be something totally different. Could someone give an example of what difference there's between interpolated hash matches the longest possible key of the hash as a literal, or fails if no key matches. and the key is counted as matched immediately; that is, the current match position is set to after the key token before calling any subrule in the value. ... I don't quite understand if the key is matched in the second version or if it's just counted as matched, whatever that means, and why the description is so dis-similar to the first quote. -- Markus Laire
Re: S05: Interpolated hashes?
Thanks, Scott Larry. IMHO, the explanation about KEY and $KEY could be moved to where the bare hash behaviour is explained as hash-in-angles-section already says A leading % matches like a bare hash except ... On 4/24/06, Larry Wall [EMAIL PROTECTED] wrote: If you want to reset to before the key for some reason, you can always set .pos to $KEY.beg, or whatever the name of the method is. Hmm, that looks like it's unspecced. This seems interesting. From day-to-day it becames harder to fully understand this perl6 thing, but I like it :) -- Markus Laire
Two comments about S05
Here are two comments after reading S05, Version 18 at
http://dev.perl.org/perl6/doc/design/syn/S05.html
In section Extensible metasyntax (...)
quote
With both bare hash and hash in angles, the key is always skipped over
before calling any subrule in the value. That subrule may, however,
magically access the key anyway as if the subrule had started before
the key and matched with KEY assertion. ...
/quote
I first read this key is always skipped over meaning that the key is
allways ignored. Perhaps this text could be clarified.
In section Backslash reform
quote
The \G sequence is gone. Use :p instead. (Note, however, that it makes
no sense to use :p within a pattern, since every internal pattern is
implicitly anchored to the current position. You'll have to explicitly
compare ( .pos == $oldpos ) in that case.)
/quote
Shouldn't this be ?{ ... } (code assertion) instead of ( ... )
(result capture)?
--
Markus Laire
Re: Junctions again (was Re: binding arguments)
On 1/5/06, TSa [EMAIL PROTECTED] wrote:
Jonathan Lang wrote:
Therefore,
$x = 3;
if $x = 1 5 {say 'smaller'}
if $x 1 5 {say 'larger'}
should produce exactly the same output as
$x = 3;
if $x = 1 $x = 5 {say 'smaller'}
This is slightly untrue. because if the junction contains two
identical values or an undef ordered object the part is
essentially stripped away:
if $x = 5 $x = 5 {say 'smaller'}
can be permuted into
if $x = 5 5 $x {say 'smaller'}
and optimized to
if $x == 5 {say 'smaller'}
Do you claim that
if $x = 5 $x = 5 {say 'smaller'}
is same as
if $x == 5 {say 'smaller'}
--
Markus Laire
Re: new sigil
Sam Vilain wrote: ps, X11 users, if you have any key bound to AltGr, then AltGr + C might well give you a ¢ sign without any extra reconfiguration. For me AltGr + C gives Copyright-symbol ©. (SuSe 9.1, tested in konsole, kwrite and thunderbird) -- Markus Laire
Standard library for perl6? (graphical primitives)
(I'm mainly interested about graphical primitives, but there are likely
other areas where standard library would be of use.)
If I want to write a crossplatform text-mode application, I could write
it in perl, and know that it will be usable in wide variety of
platforms, as long as I use only standard commands and not any
platform-specific modules etc..
But if I want to write graphics-mode application, I really don't know
what to do. Even if I were to write a simple one, which just draws lines
or puts pixels on screen, I do not know of any good solution.
Java has graphical primitives, but is encumbered by bad licenses.
C doesn't have graphical primitives in standard library, AFAIK.
Perl does have CPAN, but the problem is that there are no standard
modules, and so there can be several modules doing the same thing. perl5
has some standard commands, listed in perlfunc, but that doesn't
include any graphical primitives.
Could it be possible to create a Standard library for perl6, which
would also include graphical primitives (putpixel, getpixel,
getcolordepth, putimage, getimage, copyrectangle)?
Just a basic example:
use 6;
use Stdlib::GraphicalPrimitives;
// check for availability of graphics mode
if (!GraphModeAvailable())) {
print No graphics available, sorry\n;
exit 1;
}
// initialize graph-mode, ask for a 100x100 pixel area
// with 24bit colors to work on
if (!InitGraphics(100, 100, 24)) {
print Couldn't get 100x100x24 graphics area\n;
exit 2;
}
// do something
DrawLine(0, 0, 99, 99);
// ...
--
Markus Laire
Re: (1,(2,3),4)[2]
Rod Adams wrote:
TSa (Thomas Sandlaß) wrote:
You mean @a = [[1,2,3]]? Which is quite what you need for multi
dimensional arrays anyway @m = [[1,2],[3,4]] and here you use
of course @m[0][1] to pull out the 2. I'm not sure if this automatically
makes the array multi-dimensional to the type system though. That is
if @m[0,1] returns 2 as well or if it returns the list (1,2) or whatever.
Is @m[0..3] valid and what does it return? And what's the type of that
return value(s)? I can imagine many things ranging from a two element
array of refs to two element arrays up to a flattened list of 4 values.
@m[0,1] is an array slice of two elements, in this case two arrayrefs
[1,2], and [3,4].
@m[0;1] is a multidim deref, referencing the 4.
@m[0..3] is valid, returning arrayref x 2, undef x 2.
I think you got these wrong. With @m = ([1,2],[3,4]) these would be
true, but with @m = [[1,2],[3,4]] we have an additional reference there.
Here @m has single array-ref, not 2 array-refs.
pugs gives this:
pugs my @m = [[1,2],[3,4]]
({ref:Array})
pugs @m[0,1]
({ref:Array}, undef)
pugs @m[0..3]
({ref:Array}, undef, undef, undef)
# @m[0;1] form doesn't work in r3723
and
pugs my @m = ([1,2],[3,4])
({ref:Array}, {ref:Array})
pugs @m[0,1]
({ref:Array}, {ref:Array})
pugs @m[0..3]
({ref:Array}, {ref:Array}, undef, undef)
--
Markus Laire
Re: (1,(2,3),4)[2]
Rod Adams wrote:
Austin Hastings wrote:
--- Rod Adams [EMAIL PROTECTED] wrote:
TSa (Thomas Sandlaß) wrote:
@m = [[1,2],[3,4]]
@m[0;1] is a multidim deref, referencing the 4.
Referencing the 2, I hope?
Doh!
Yes, the 2.
Really?
@m here has _single_ array-ref so
@m[0] returns that single array-ref - [[1,2],[3,4]]
@m[0;1] then returns array-ref [3,4]
@m[0;0] would return [1,2]
@m[0;0;1] would return 2
Double-checking with pugs: (multi-dim with ; doesn't work yet)
pugs my @m = [[1,2],[3,4]]
({ref:Array})
pugs @m[0]
({ref:Array}, {ref:Array})
pugs @m[0][1]
(3, 4)
pugs @m[0][0]
(1, 2)
pugs @m[0][0][1]
2
@m = [[1,2],[3,4]] IS NOT same as @m = ([1,2],[3,4])
pugs my @m = ([1,2],[3,4])
({ref:Array}, {ref:Array})
pugs @m[0]
(1, 2)
pugs @m[0][1]
2
--
Markus Laire
Re: Plethora of operators
Juerd wrote: Juerd skribis 2005-05-14 17:23 (+0200): Markus Laire skribis 2005-05-14 18:07 (+0300): [+^=] (@a, @b, @c) These arrays flatten first (otherwise [+] @foo could never calculate the sum of the elements), so imagine that you have $foo, $bar, $baz, $quux, $xyzzy to let +^= operate on. Is this then ok? [+^=] (@a ; @b ; @c) or [+^=] ([EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]) As S09 says that: At the statement level, a semicolon terminates the current expression. Within any kind of bracketing construct, semicolon notionally produces a list of lists, the interpretation of which depends on the context. Such a semicolon list always provides list context to each of its sublists. The following two constructs are structurally indistinguishable: (0..10; 1,2,4; 3) ([0..10], [1,2,3,4], [3]) If not, how then would I use hyper-reduction ops like [+^=] with several arrays? i.e. How do I write @a +^= @b +^= @c using the [+^=] op? -- Markus Laire Jam. 1:5-6
Re: Plethora of operators
Adam Kennedy kirjoitti:
[»+^=«] reminds me of a P5 regex that has a comment saying This is
black magic. Don't touch!. --That's-- my complaint.
I look at...
but the basic operator there is just ^, with a + modifier to indicate
numeric XOR, = to indicate an assignment operator, »« to indicate
explicit parallelism, and now [] to indicate reduction
...and I just mind-wipe... so it's doing WHAT exactly? I've read it 5
times and I still have no idea. And reduction? I write 25,000+ lines of
Perl a year, and if you are talking about something like
List::Util::reduce, I think I've used it maybe twice?
Just trying to guess:
(Here @a, @b, @c all have same length for simplicity)
[+^=] (@a, @b, @c)
# reduction: place the op between each item in the given list
@a +^= @b +^= @c
# hyper-op: apply op in parallel for items in lists
for @a Y @b Y @c - $a is rw, $b is rw, $c {
$a +^= $b +^= $c
}
# and finally (+^= is right-associative)
for @a Y @b Y @c - $a is rw, $b is rw, $c {
$b = $b +^ $c;
$a = $a +^ $b;
}
I'm not too familiar with xor, so here's an easier example with plain +=
my @a = (1,2,3);
my @b = (10,20,30);
my @c = (100,200,300);
[+=] (@a, @b, @c);
# i.e. @a += @b += @c
# now @c = (100, 200, 300)
# @b = (110, 220, 330)
# @a = (111, 222, 333)
--
Markus Laire
Jam. 1:5-6
Re: split /(..)*/, 1234567890
Rick Delaney wrote:
On Fri, May 13, 2005 at 04:05:23AM +0800, Autrijus Tang wrote:
On Thu, May 12, 2005 at 12:01:59PM -0700, Larry Wall wrote:
Yes, though I would think of it more generally as
('', $0, '', $0, '', $0, ...)
where in this case it just happens to be
('', $0)
and $0 expands to ['12','34','56','78','90'] if you treat it as an array.
I don't understand this comment. The $0 here is an array of
match-objects and when treated as array it returns an array of
match-objects, not an array of strings. (see below)
Thanks, implemented as such.
pugs map { ref $_ } split /(..)*/, 1234567890
(::Str, ::Array::Const)
Sorry if I'm getting ahead of the implementation but if it is returning
$0 then shouldn't ref($0) return ::Rule::Result or somesuch? It would
just look like an ::Array::Const if you treat it as such.
With pugs (r2917) this doesn't return an Array of Strings but an Array
of Match-objects:
pugs map { ref $_ } split /(..)*/, 1234567890
(::Str, ::Array::Const)
pugs map { ref $_ } [split /(..)*/, 1234567890][1]
(::Match, ::Match, ::Match, ::Match, ::Match)
pugs map { ~$_ } [split /(..)*/, 1234567890][1]
('12', '34', '56', '78', '90')
pugs map { $_.from } [split /(..)*/, 1234567890][1]
(0, 2, 4, 6, 8)
--
Markus Laire
Jam. 1:5-6
Re: C:: in rules
TSa (Thomas Sandlaß) kirjoitti: Larry Wall wrote: Speaking of which, it seems to me that :p and :c should allow an argument that says where to start relative to the current position. In other words, :p means :p(0) and :c means :c(0). I could also see uses for :p(-1) and :p(+1). Isn't that slightly inconsistent with :p meaning :p(1) the so-called real winner for passing boolean options of A12? Perhaps spec should be changed so that :p means :p(bool::true) or :p(?1) and not :p(1) -- Markus Laire Jam. 1:5-6
Re: Unknown level of hash
Zhuang Li wrote:
Yes. I think it's both useful and fun. I was thinking something similar
to
@[EMAIL PROTECTED] = map{1} @a;
But getting $hash-{E1}-{E2}-...-{En} = 1; instead of $hash{E1} =
1; ... $hash{En} =1;.
What I'd really like to do is:
Given @a = ('E1', 'E2', ..., 'En');
@b = ('K1', 'K2', ..., 'Km');
@c = ('V1', 'V2', ..., 'Vm');
To get the following in one line:
$hash-{E1}-...-{En}-{K1} = 'V1';
$hash-{E1}-...-{En}-{K2} = 'V2';
$hash-{E1}-...-{En}-{Km} = 'Vm';
I'll attempt a quess based on S03 S04 S09.
( http://dev.perl.org/perl6/synopsis/ )
S09 says that @nums[dims 0..2] means @nums[0;1;2]
S09 also says that Everything we've said for arrays applies to hashes
as well ...
S04 tells how to process several lists in parallel in for-loop.
S03 tells about unary * list-flattening op.
So what about:
for @b ¥ @c - $b, $c { $hash-{dims ([EMAIL PROTECTED],$b)} = $c }
ps. I'm not 100% sure if I got that ([EMAIL PROTECTED],$b) right. I want to add $b to
@a and feed it to dims as one list.
--
Markus Laire
Jam. 1:5-6
Re: Units on numbers [was Re: S28ish]
Larry Wall wrote: ... SKIP ... Okay, that looks scary, but if as in my previous message we define chars as the highest Unicode level allowed by the context and the string, then we can just write that in some notation resembling: substr($a, 5`Chars, 10`Chars); or whatever notation we end up with for labeling units on numbers. Even if we don't define chars that way, they just end up labeled with the current level (here assuming Codes): substr($a, 5`Codes, 10`Codes); or whatever. But this is all implicit, which is why you can just write substr($a, 5, 10); and have it DWYM. Now, I admit that I've handwaved the tricksy bit, which is, How do you know, Larry, that substr() wants 5`Codes rather than 5`Meters? It's all very well if you have a single predeclared subroutine and can look at the signature at compile time, but you wrote those as multi methods up above, so we don't know the signature at compile time. Well, that's correct, we don't know it at compile time. But what *do* we know? We know we have a number, and that it was generated in a context where, if you use it like a string position, it should turn into a number of code points, and if you use it like a weight, it should turn into a number of kilograms (or pounds, if you're NASA). In other words, the effective type of that literal 5 is not Int, but Int|Codes|Meters|Kilograms|Seconds|Bogomips or some such. And if MMD can handle that in an argument type and match up Codes as a subtype of Ptr, and if we write our method signature only in the abstract types like Ptr, we're pretty much home free. That certainly simplifies how you write S29, though I don't know if the MMD folks will be terribly happy with the notion of dispatching arguments with junctional types. But it does fall out of the design rather naturally. ... So do you actually envision perl6 to allow a junction of units on numbers? This would have huge implications, depending on what exactly is possible with these units... Would/could some of these DWIM in perl6? # import proper MMD-subs for + - * etc... use MyUnitConversions; my $length = 1.3`Meters + 4.6`Yards; my $weight = 4`Pounds - 1'Kilograms; my $money = 12` + 5.78` + 12`US$; Then, how would I specify the unit of the result? my $unit = 1`Minutes|Kilograms|Meters; my $time_mins`Minutes = $unit * 5.45; # 5.45 Minutes my $time_secs`Seconds = $unit * 5.45; # 327 Seconds my $weight`Weight = $unit * 2.34; my $length`Length = $unit * 12.56; But these would need MMD based on return-type which is out IIRC? So perhaps just simple: my $time_mins = unit_conversion($unit * 5.45, Minutes); my $time_secs = unit_conversion($unit * 5.45, Seconds); Or using some infix-op: my $time_mins = ($unit * 5.45) ` Minutes; my $time_secs = ($unit * 5.45) ` Seconds; And what about hex/dec/oct/bin? Could these be included in this system? my $number`Dec = 12`Oct + 010101`Bin + 0cab`Hex; And then we of course definitely need my $length = 12`OctMiles + 0c`HexKilometers;:) Not sure if I'm on right track at all - but Units on numbers with MMD gives some really nice ideas to a mathematically minded person... my $speed_a = 78`Kilometers / 2`Hour; my $speed_b = 50`(Miles/Hour); # or 50`Miles_per_Hour my $delta = $speed_a - $speed_b; -- Markus Laire Jam. 1:5-6
Re: .method == $self.method or $_.method?
Larry Wall kirjoitti: On Thu, Mar 17, 2005 at 03:59:43PM -0800, Michael G Schwern wrote: : What it doesn't solve is the $.method vs .method issue. They look similar : but one works on the invocant and one works on $_. Still a trap. Yes, and that's probably the killer of the oc idea. So much for Sleep Brain, heh, heh. I think we'll need to figure out how to shorten $_.foo instead. Either that, or there has to be a way to explicitly make $_ the invocant of a subblock. What about using the oc idea to shorten $_.foo x.foo (or some other letter instead of 'x') Still this only shortens it by one char... (Not sure if I like this at all - just an idea...) -- Markus Laire Jam. 1:5-6
Q: index(Hello, , 999)
What should index(Hello, , 999) return in perl6? In perl5 that returns 5, but IMHO -1 would be right result. -- Markus Laire Jam. 1:5-6
Q: Junctions send+more=money
I have two questions about this example code
(taken from http://svn.openfoundry.org/pugs/examples/sendmoremoney.p6)
(btw, a really nice example of how to use junctions - just try to write
this in perl5 :)
#!perl6
use v6;
my $s;
my $e;
my $n;
my $d;
my $m;
my $o;
my $r;
my $y;
$s = any(0..10) none(0);
$e = any(0..10);
$n = any(0..10);
$d = any(0..10);
$m = any(0..10) none(0);
$o = any(0..10);
$r = any(0..10);
$n = any(0..10);
$y = any(0..10);
I think these should be any(0..9).
my $send := construct($s,$e,$n,$d);
my $more := construct($m,$o,$r,$e);
my $money := construct($m,$o,$n,$e,$y);
if ($send + $more == $money) {
say send = $send;
say +more = $more;
say -
say money = $money;
}
sub foldl(Code op, Any $initial, [EMAIL PROTECTED]) returns Any {
if ([EMAIL PROTECTED] == 0) {
return $initial;
} else {
return op(shift @values, ?SUB(op, $initial, @values));
}
}
sub add(Int $x, Int $y) returns Int {
return $x + $y;
}
sub construct([EMAIL PROTECTED]) returns Junction {
return foldl( sub ($x, $y) { $x * 10 + $y}, 0, @values);
}
How would the if (...) {...} work if there were more than one possible
match to this equation?
How would I rewrite this example to be more general, so that given 3
strings (in this case 'send', 'more', 'money'), the program would give
all possible results for the equation first string + second string =
third string.
--
Markus Laire
Jam. 1:5-6
Re: Boolean comparison (was Boolean literals)
Larry Wall wrote:
On Wed, Feb 16, 2005 at 02:29:36PM +0800, Autrijus Tang wrote:
: Just a quick question. The prettyprinter of Pugs (the thing that
: handles the .perl method) currently prints out boolean true and
: false as #t and #f, which is obviously not correct.
:
: pugs (1 2, 2 1)
: (#f, #t)
:
: What should I do, though? Inventing two primitives, true and
: false? Or is there a way to annotate values with types, similar
: to Haskell's :: construct?
:
: pugs (1 2, 2 1)
: (0 as Bool, 1 as Bool)
The latest S12 has it as bool::true and bool::false. (In general,
you can print out any enum as role::identifier.) When unambiguous,
bare true and false can be used, but in any event the use of
symbolic booleans is somewhat discouraged in Perl because it leads
people to write stupidities like
while foo() == true {...}
Instead, we try to make sure all types know how to behave in boolean
context directly. Any object that does the bool role has an
attribute of type bit, which will return 0 if the object is false,
and 1 if the object is true. (The optimizer is free to optimize away
the method call if it can, of course. Native integers and floats
are always true if non-zero, for instance. But object types can always
be derived from, or have but true mixed into them.)
We already have +^ ~^ ?^ +| ~| ?| etc..
Why not allow data-type prefix for the comparison operators also, so
we'd get, to mention a few, ~== (same as 'eq') ~ (same as 'lt') ~=
(same as 'le') - and of course boolean versions ?== and ?!= (The others
really don't have use with just 2 possible values.)
Then a programmer could write
while foo() ?== true {...}
and it would be ok. After all, perl is all about giving more than one
way to do it.
--
Markus Laire
Jam. 1:5-6
Re: Perl 6 Summary for 2005-01-31 through 2004-02-8
John Macdonald wrote: The basic problem is that a junction does not work well with boolean operations, because the answer is usually sometimes yes and sometimes no and until you resolve which of those is the one you want, you have to proceed with both conditions. Well, just patch the boolean operators to return one of (yes, no, sometimes) instead of plain (true, false) :) Anyway, what are the usual semantics with junctions boolean operators in some other languages? (This is so new concept to me, that I don't know of any language to compare against.) -- Markus Laire Jam. 1:5-6
Re: Autothreading generalization
Luke Palmer writes: Craig DeForest writes: Yeah, the sigils do get in the way for small placeholder variables like these. @C[ $i; $j; $k; $l ] = @A[ $i; $j ] * @B[ $k; $l ] Losing the carets doesn't do much for us (and would force us to use the explicit syntax, whatever that might be). Hmm, on the other hand, ^ doesn't mean anything in term context yet. I feel uncomfortable about allowing ^ as a shorthand for $^, since every other variable in the whole damn language has one of the four standard sigils. What about adding fifth sigil into the language? To be used only with placeholder-variables? That way ^ (or whatever char we choose) wouldn't be shorthand for $^, but part of the actual variable name, as are other sigils. That char should be selected based on it's readibility in expressions like these. Would placeholder variables be used often enough to varrant their own sigil? Luke -- Markus Laire Jam. 1:5-6
Re: Perl 6 documentation project mailing list
On 8 Nov 2002 at 9:12, Michael Lazzaro wrote: On Thursday, November 7, 2002, at 10:45 PM, Piers Cawley wrote: Those of us with subs to perl6-all will get this anyway, right? I posted an initial message about five minutes ago, so if you received it, then yes. :-) There are few messages going there now, but at least I don't receive them via perl6-all, only via perl6-documentation (I'm on both lists, just in case) -- Markus Laire 'malaire' [EMAIL PROTECTED]
Re: UTF-8 and Unicode FAQ, demos
On 2 Nov 2002 at 0:06, Simon Cozens wrote: [EMAIL PROTECTED] (Matthew Zimmerman) writes: Larry has been consistently using OxAB op 0xBB in his messages to represent a (French quote) hyperop, (corresponding to the Unicode characters 0x00AB and 0x00BB) More and more conversations like this, (and how many have we seen here already?) about characters sets, encodings, mail quoting issues, in fact, anything other than Perl, will be rife on every Perl-related mailing list if we persist with this idiotic idea of having Unicode operators. It may seem idiotic to the egocentric people who only needs chars a-z in his language. But for all others (think about Chinese), Unicode is real asset. -- Markus Laire 'malaire' [EMAIL PROTECTED]
Re: Vectorizing operators for Hashes
On 31 Oct 2002 at 0:40, John Williams wrote: On Wed, 30 Oct 2002, Me wrote: %a ^:union[op] %b %a :foo[op]:bar %b I think that any operators over 10 characters should be banished, and replaced with functions. I don't think there should be any upper limit for operator-lengths. e.g. When teaching perl to my little brothers (still at primary school) I might want to use alphabetical userdefined operators: print 1 + 5 - 4 / 2 print one plus five minus four divided_by two (and same in finnish) näytä yksi plus viisi miinus neljä jaettuna kaksi At least it wouldn't harm anyone to allow this. -- Markus Laire 'malaire' [EMAIL PROTECTED]
Re: Perl6 Operator (REMAINING ISSUES)
On 31 Oct 2002 at 15:59, Mark J. Reed wrote: Once you wander away from Latin-1 into the more general world of Unicode, you start running into trouble on the input side. On Windows you pretty much have to use the Character map accessory. Emacs and vim still work on UNIX, but I don't know of a XIM implementation for general Unicode. (Although if you log into your Unix machine using Kermit-95, it has a keystroke sequence for arbitrary Unicode input). Emacs and vim also works on Windows, not just UNIX. -- Markus Laire 'malaire' [EMAIL PROTECTED]
Re: Wh[ie]ther Infix Superposition ops
On 29 Oct 2002 at 11:22, Jonathan Scott Duff wrote:
On Tue, Oct 29, 2002 at 10:13:39AM +0200, Markus Laire wrote:
Also the idea of allways using 'function' style for something so
basic like superpositions doesn't appeal to me.
Superpositions are basic in a fabric-of-the-universe kind of way,
but they are hardly basic in the everyone-learns-them-in-grade-school
kind of way. I think the latter is more important for huffman coding
of operators for the unwashed masses. But I'm willing change my mind
if we start teaching everyone superpositions in grade school :-)
You are making the fundamental mistake of thinking superpositions as
superpositions. When thinking them as another-kind-of or/and, their
usefulness comes a lot clearer.
perl5: if $x == 5 || $x == 7 || $x == 99
perl6: if $x == 5 | 7 | 99
perl5: ...loop to test every value in an array...
perl6: if ! 28 = any(@days_in_months) = 31 { ERROR }
(this probably has slight syntax error)
perl5: if $x 0 $x 20 $y 0 $y 20 $z 0 $z 20
perl6: if 0 $x $y $z 20
perl5: if ($x = 10 $x = 20) || ($x = 30 $x = 40)
perl6: if $x ~~ 10..20 | 30..40
--
Markus Laire 'malaire' [EMAIL PROTECTED]
RE: [RFC] Perl6 Operator List, Take 5
On 29 Oct 2002 at 22:29, Larry Wall wrote:
Of course, Real Mathematicians will want [1..10) and (1..10] instead.
That seems familiar, I like it ;)
There's also an issue of what (1..10) - 1 would or should mean, if
anything. Does it mean (1..9)? Does 1 + (1..10) mean (2..10)?
And what would ('a' .. 'z') - 1 mean?
If we are going to do math with ranges, we definitely need non-
discreet ranges also. Or at least make sure it's easy enough to
implement as a class.
(1.9 .. 2.1) + (5..7) * (72.49 .. 72.51);
--
Markus Laire 'malaire' [EMAIL PROTECTED]
Re: worth adding collections to the core language?
On 30 Oct 2002 at 11:09, Larry Wall wrote: On Wed, 30 Oct 2002, Piers Cawley wrote: :It is a truth universally acknowledged that a language in : possession of a rich syntax must be in need of a rewrite. : -- Jane Austen? It is a truth universally acknowledged that a language in possession of a rich syntax must be in need of a larger character set. I can almost taste it: French quotes for hyperoperators... @a «+» @b @a«++» @a«.anymethod(args)» And you could always have something else as a backup for those unfortunates who can't use «+» - like ^[+] What are the good reasons not to use «» ? -- Markus Laire 'malaire' [EMAIL PROTECTED]
Re: [RFC] Perl6 Operator List, Take 5
On 30 Oct 2002 at 15:24, Jonathan Scott Duff wrote: On Wed, Oct 30, 2002 at 11:10:54PM +0200, Markus Laire wrote: If we are going to do math with ranges, we definitely need non- discreet ranges also. Or at least make sure it's easy enough to implement as a class. (1.9 .. 2.1) + (5..7) * (72.49 .. 72.51); I don't think that non-discrete ranges is what you mean. Perhaps you just want ranges whose step size is something other than 1 (1.9 .. 2.1 : 0.1) + (5..7) * (72.49 .. 72.51 : 0.01) That would also be usefull, but I definitely mean math with non-discrete ranges. How else are you going to calculate with numbers which have 'uncertainty-range' (not sure about right term) i.e. all math in physics. There are bound to be other uses. This should probably be a class, so only problem is then to be sure that it's possible to create such a class and use it with easy syntax. Then there is a question of what such expressions should return. A superposition of non-discrete anges encompassing all the possible solutions would be the easy way. Adding probability distributions to those ranges would also be usefull. Still this is an implementation detail. -- Markus Laire 'malaire' [EMAIL PROTECTED]
Re: Wh[ie]ther Infix Superposition ops
On 29 Oct 2002 at 5:45, Piers Cawley wrote: Whilst I don't wish to get Medieval on your collective donkey I must say that I'm really not sure of the utility of the proposed infix superposition ops. I'm a big fan of any/all/one/none, I just think that one(any($a, $b, $c), all($d, $e, $f)) Is a good deal more intention revealing than the superficially appealing than ($a $b $c) ^ ( $d | $e | $f ) which takes rather more decoding. And if you *do* want to use such operators, surely you could just do use ops ':superpositions'; in an appropriate lexical scope. Am I missing something? In this case I find the latter to be easier to decode and more appealing. There are less chars and paretheses are seen much more easily. The 'one(...)' especially seems to be superficial, as it's just 'this or that' operation in this case, and so single operator fits perfectly. Also the idea of allways using 'function' style for something so basic like superpositions doesn't appeal to me. Of course this might just be that I'm too used to use strange mathematical symbols. (Nobody ever understood my solutions in high-school...) -- Markus Laire 'malaire' [EMAIL PROTECTED]
Re: Perl6 Operator List, TAKE 4
On 28 Oct 2002 at 16:42, Dan Sugalski wrote: At 4:39 PM -0500 10/28/02, brian wheeler wrote: On Mon, 2002-10-28 at 16:25, Michael Lazzaro wrote: explicit radix specifications for integers: 0123- decimal 2:0110- binary [also b:0110?] 8:123 - octal [also o:123?] 16:123- hex[also h:123?] 256:192.168.1.0 - base 256 (...etc...) I've got to admit that I've not paid alot of attention to this thread...but does that mean 0x1234 and 01234 (octal) go away or is this an omission? While we're at it, maybe we can add in 0rMCM to allow roman numerals too... -- What about specifying endiannes also, or would that be too low-level to even consider? Currently I don't have any examples for where it might even be used... -- Markus Laire 'malaire' [EMAIL PROTECTED]
Re: exegesis 5 question: matching negative, multi-byte strings
On 1 Oct 2002 at 18:47, [EMAIL PROTECTED] wrote:
all text up to, but not including the string union.
rule getstuffbeforeunion { (.*?) union | (.*) }
a union = a
b = b
hmm... well, it works, but its not very efficient. It basically
scans the whole string to the end to see if there is a union string, and
then backtracks to take the alternative. And hence, its not very scalable.
It also doesn't 'complexify' very well.
What about
Perl 5: /(.*?)(?:union|$)/
Perl 6: /(.*?) [union | $$]/
or if you want to exlude 'union' from match
Perl 5: /(.*?)(?=union|$)/
Perl 6: /(.*?) [after: union | $$]/
IMHO those should scan string one char at a time until 'union' or end-
of-string, which is optimal solution.
--
Markus Laire 'malaire' [EMAIL PROTECTED]
Re: Backtracking syntax
Backtracking syntax includes: :, ::, :::, commit, cut 1. It's nice how the ':', '::', and ':::' progression indicates progressively wider scope. But I would be surprised if newbies don't say to themselves, now just how wide a scope am I backtracking when there's three colons?. What problem there is? Scopes are atom/group/rule - I don't see any possible misunderstanding there as these scopes are so natural. 2. Typo-trap: I can imagine it being fairly easy for some people to miss, during debugging, both the visual and behavioral distinction between '::' and ':::'. If that really is big problem, it can be solved easily by using proper editor which supports high-lighting. ::: could be shown with different color or bold while :: uses some other syntax. 3. It seemed odd how the commit and cut assertions switch to the general ... syntax. I felt like it would be better if they avoided the general syntax, and preferably had some family resemblance with the first three backtracking controls. So, how about something like: : # lock in current atom, ie as now :] # lock in surrounding group, currently :: : # lock in surrounding rule, currently ::: :/ # lock in top level rule, currently commit :// # cut I find :,::,::: to be a lot easier to remember than :,:],: - and also easier to type. While commit and cut don't follow same syntax, I don't really see any better solutions. Better solution should IMHO keep :,::,::: and offer better alternative only to commit. cut doesn't really belong to this serie as it's different backtracking-operation and so it can and should have different syntax. I wonder if might be usefull instead of commit with proper syntax-highlighting. -- Markus Laire 'malaire' [EMAIL PROTECTED]
Re: Backtracking syntax
On 22 Sep 2002 at 21:06, Simon Cozens wrote: [EMAIL PROTECTED] (Markus Laire) writes: While commit and cut don't follow same syntax, I don't really see any better solutions. commit is sufficiently hard that it musn't be confused with the colon series. Yes, I didn't think that enough. :,::,::: only affects current rule while commit goes further to possibly affect other rules also, so it must have different syntax. -- Markus Laire 'malaire' [EMAIL PROTECTED]
Re: Regex query
On Sat, Sep 21, 2002 at 11:36:49AM -0600, John Williams wrote: On Sat, 21 Sep 2002, Jonathan Scott Duff wrote: Anyway, (7) or (3+4) should yield a number, not a list, because otherwise every math expression will break. Why can't perl be smart enough to figure out what we mean? Something along these lines: (7) # list context (3+4)# numeric context (there's a numeric operator in there) (3+4,5) # list context (comma trumps the numeric op) It would be a total nightmare to try to DWIM in this case, especially with userdefined operators or more complex expressions. There are 101 reasons why parens shouldn't make lists and how it can make mathematical expressions do something totally unexpected. Consider changing a program where you have many mathematical expressions. $x = $y / (($a + $b) * $c - $d); If you later find out that $b or $d can be left out, I expect to be able to just remove it without need to check if any parentheses now contains only one value, and then to remove parens also. Also machine-generated expressions would have to be double-checked for any single values in parentheses. Latest Perl-Golf tournament 'Infix to RPN' used testcases like (18*16*16*5-1+12+15+18*1-8+6/7-6-2-(19)*(17))+8+((9/14)) This is valid mathematical expression in perl5 but would do something totally different in perl6 because of those 'one-element lists' -- Markus Laire 'malaire' [EMAIL PROTECTED]
RE: atomicness and \n
On 4 Sep 2002 at 0:22, Aaron Sherman wrote: On Wed, 2002-09-04 at 00:01, Sean O'Rourke wrote: None, I think. Of course, if we ignore internals, there's no difference bewteen that and rx /roundascii | 1 | 7/. Then, why is there a C+? Why not make it C|? $foo = rx/ a|b|[cde]|f / Because it's good to have MTOWTDI. (= More than one way to do it) -- Markus Laire 'malaire' [EMAIL PROTECTED]
Re: Regex stuff...
On 31 Aug 2002 at 0:17, Piers Cawley wrote:
my $pattern = rx:w / $1:=(\S+) =gt $2:=(\S+) |
$2:=(\S+) lt= $1:=(\S+) /;
@ary = m/$pattern/
how many elements are there in @ary? I can
make a case for 4 quite happily. Certainly that's what A5 seems to
imply:
Suppose you want to use a hypothetical variable to bind a name to
a capture:
/ (\S+) { let $x := $1 } /
A shorthand for that is:
/ $x:=(\S+) /
The parens are number independently of any name, so $x is an alias
for $1.
And it's that last sentence that's important here. So, it looks like
C +@ary is going to be 4.
How could it be 4? If the example would've been
my $pattern = rx:w / $a:=(\S+) =gt $b:=(\S+) |
$b:=(\S+) lt= $a:=(\S+) /;
Then there is 4 variables to speak of ($1,$2,$a,$b) and a question
arises about which of these are returned.
In the original example however we only have 2 variables ($1,$2) so
it can't really return anything else than those 2.
m: w / $2:=(\S+) lt= $1:=(\S+) /
Now, assignment to hypotheticals doesn't happen all at once, it
happens when the matching engine reaches that point in the
string. Unless I'm very much mistaken, the order of execution will
look like:
$2:=$1; $1:=$2;
And it seems to me that we'll end up with $1 and $2 both bound to the
same string; which isn't working quite how I expect. Or do we special
case the occasions when we bind the result of a capturing group to a
numeric match variable?
As I understand it, binding to $1 etc.. is a special case. Also I
don't see any problems in your example:
m: w / $2:=(\S+) lt= $1:=(\S+) /
First () is captured and assigned to $2 (instead of $1).
Then second () is captured and assigned to $1.
--
Markus Laire 'malaire' [EMAIL PROTECTED]
Re: Regex stuff...
On 31 Aug 2002 at 10:26, Piers Cawley wrote:
my $pattern = rx:w / $1:=(\S+) =gt $2:=(\S+) |
$2:=(\S+) lt= $1:=(\S+) /;
Count the capturing groups. Looks like there's 4 of 'em to me. $1, $2,
$3 and $4 are automatic variables which, according to the Apocalypse
get set for every capturing group independent of any named variable to
which they might also be bound.
Not if those capturing groups have been renumbered.
From A5:
You can reorder paren groups by naming them with numeric variables:
/ $2:=(.*?), \h* $1:=(.*) /
If you use a numeric variable, the
numeric variables will start renumbering from that point, so
subsequent captures can be of a known number (which clobbers any
previous association with that number). So for instance you can
reset the numbers for each alternative:
/ $1 := (.*?) (\:) (.*) { process $1, $2, $3 }
| $1 := (.*?) (=\) (.*) { process $1, $2, $3 }
| $1 := (.*?) (-\) (.*) { process $1, $2, $3 }
/
So binding to $1 etc is a special case. Your example never captures
to $1..$4 but only to $1,$2 according to the renumbering.
Note that it's actually called 'reordering/renumbering' instead of
'binding' in A5 for numeric variables.
--
Markus Laire 'malaire' [EMAIL PROTECTED]
Re: Hypothetical synonyms
On 28 Aug 2002 at 16:04, Steffen Mueller wrote: Piers Cawley wrote: Uri Guttman [EMAIL PROTECTED] writes: ... regex code ... Hmm... is this the first Perl 6 golf post? Well, no, for two reasons: a) There's whitespace. b) The time's not quite ready for Perl6 golf because Larry's the only one who would qualify as a referee. I think that time is just right for starting to golf in perl6. Parrot with languages/perl6 already supports a working subset of perl6. I'm currently trying to get factorial-problem from last Perl Golf working in perl6, and it has proven to be quite a challenge... (only 32bit numbers, modulo not fully working, no capturing regexps, ) And I'm definitely going to try any future PerlGolf challenges also in perl6. -- Markus Laire 'malaire' [EMAIL PROTECTED]
Re: E5: questions
On 23 Aug 2002 at 22:29, Damian Conway wrote: 2) p3, This or nothing, Have I got :, ::, and ::: straight? o : backtrack fails rule No. Backtrack skips the preceding atom. o :: backtrack fails surrounding group Yes. o ::: backtrack fails whole match No. Backtrack fails rule. So, would this be right short explanation: o : backtrack fails preceding atom (as atom fails, it's skipped) o :: backtrack fails surrounding group (OK) o ::: backtrack fails rule (OK) o commitbacktrack fails whole match So even shorter version: :/::/:::/commit makes backtrack fail current atom/group/rule/match. -- Markus Laire 'malaire' [EMAIL PROTECTED]
Re: OT: Finite State Machine (was Perl summary for week ending 2002-08-04)
Not know what a finite state machine was, I decided to poke around the Net before replying to you. I found this definition: ... at http://www.c3.lanl.gov/mega-math/gloss/pattern/dfa.html This seems rather ambiguous, though, as it basically means that a FSM is anything that you can imagine that can parse language. Nothing about its inherent limits, outside of which I presume one will find irregular languages. IMHO that's an awful explanation. From what I remember, this is true. Somebody correct me if I'm wrong. Any Finite State Machine or true regular expression can be written using a set of symbols (e.g. chars a-z) and three operators: * Concatenation - pattern A concatenated with B matches a match for A followed by a match for B * Or - pattern A-or-B matches either a match for A or a match for B. * Closure - zero or more matches for a pattern So regular expressions in Perl are really far from being regular. for technical definition, you can check e.g. http://www.wkonline.com/d/Finite_State_Machine.html but that is most likely not understandable without prior knowlegde. -- Markus Laire 'malaire' [EMAIL PROTECTED]
Re: Use of regular expressions on non-strings
On 1 Aug 2002 at 19:30, David Whipp wrote: I'm wondering if Perl6's new regex can be applied to non-string things. I seem to recall A5 mentioning something about strings tied to array implementations; but I'm wanting something a little more powerful. Yes, it can be applied to anything which can be tied to string. I didn't understand your message completely so I'll just copy-paste relevant parts from Synopsis 5, which IMO is easier to understand than A5. from http://dev.perl.org/perl6/synopsis/5.html Matching against non-strings * Anything that can be tied to a string can be matched against a regex. This feature is particularly useful with input streams: my @array := $fh; # lazy when aliased my $array is from(\@array); # tie scalar# and later... $array =~ m/pattern/; # match from stream Backtracking control * A cut assertion always matches successfully, and has the side effect of deleting the parts of the string already matched. * Attempting to backtrack past a cut causes the complete match to fail (like backtracking past a commit. This is because there's now no preceding text to backtrack into. * This is useful for throwing away successfully processed input when matching from an input stream or an iterator of arbitrary length. -- Markus Laire 'malaire' [EMAIL PROTECTED]
