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: Heureka - from the -Ofun department
On 2/9/06, Leopold Toetsch <[EMAIL PROTECTED]> wrote: > > On Feb 8, 2006, at 22:28, Joshua Isom wrote: > > > but an option to disable compile time optimizations would help with > > the testing the interpreter instead of the compiler > > It's not an optimization and it can't be turned off, as there are no > such opcodes like 'pow_i_ic_ic'. And again - the evaluation of that > constant is using the parrot *runtime* (compilation is runtime, just > earlier ;) . And if a JITted program behaves differently that's still > another case. Is there a reason why this can't be "turned off" like this: convert $N0 = pow 2.0, 5.0 to $N = 2.0 $N0 = pow N, 5.0 where N is an otherwise unused register. If the only problem is that pow can't be called with 2 constants, this would trivially solve it. ps. The syntax might be wrong, as I don't program in parrot. I'm just following the conversation. -- 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 (<...>)" 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 assertion. ... 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" 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.) Shouldn't this be (code assertion) instead of <( ... )> (result capture)? -- Markus Laire
S05: Interpolated hashes?
In Synopsis 5 (version 22), Under "Variable (non-)interpolation" it's said that 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.) And under "Extensible metasyntax (<...>)" it's said that 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 assertion. That is, $ 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. 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 and $ 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 $.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
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:
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).
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
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:
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;
--
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:
>
>
> 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
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: 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
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
And here I mis-read < as <=. Perhaps I should stop "fixing", as I'm making too many errors here... On 5/10/06, Markus Laire <[EMAIL PROTECTED]> wrote: > > 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) Correction: (1, 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 Correction: Bool::True, Bool::True, Bool::False, Bool::False, Bool::False, Bool::False And so filter (list [<] @array) @array would give first 3 elements of @array, i.e. (1, 2, 2) Correction: First 2 elements, i.e. (1, 2) -- 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: [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 C, 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
perl6-users or perl6-meta?
perl6-meta was reactivated[1] few weeks ago. Now that perl6-users has been created[2], what about perl6-meta? Will perl6-meta be used anymore or not? I'll guess perl6-users will be used instead of perl6-meta, but I'm just asking for confirmation so that I'll know which lists to follow. [1] http://www.nntp.perl.org/group/perl.perl6.meta/989 [2] http://www.nntp.perl.org/group/perl.perl6.announce/511 -- Markus Laire
Re: Mutil Method Questions
On 6/23/06, Steffen Schwigon <[EMAIL PROTECTED]> wrote:
Steffen Schwigon <[EMAIL PROTECTED]> writes:
> multi sub talk () { say 'Loose Talk Is Noose Talk.'; }
> multi sub talk (String $msg) { say $msg; }
> multi sub talk (String $msg, Int $times) { say $msg x $times; }
BTW, because we are just on-topic, can someone explain, when these
types above are used. They seem pretty useless in my example but it
looked that nice. :-)
IMHO they are already used in that example automatically. You just
don't see it because every multi sub had different amount of
parameters.
This example might make it a bit clearer:
multi sub talk (String $msg1, String $msg2) { say "$msg1 $msg2" }
multi sub talk (String $msg, Int $times) { say $msg x $times; }
multi sub talk (String $msg, Num $times) { say "Please use an integer"; }
multi sub talk (String $msg, Range $r) { say "$_: $msg" for $r }
talk("Hello", "World"); # String and String
talk("Hi", 2); # String and Int
talk("Test", 1.23); # String and Num
talk("Hello", 3..5); # String and Range
talk(123, 3); # Int and Int
I think that would print
Hello World
HiHi
Please use an integer
3: Hello
4: Hello
5: Hello
123123123
In last example, there is no exact match for parameters (Int, Int), so
IMHO perl6 would select the closest match, which in this case is
(String, Int) because Int can be converted to String.
The Range-example is my quess of how Range could be used with "for".
I'm not 100% sure if that syntax is OK.
How do I extend the example to really check the parameter types. Some
kind of "use strict" anywhere?
I think that parameter types are automatically checked.
Also "use strict;" is default in perl6, but that's a bit different thing IMHO.
--
Markus Laire
Re: Mutil Method Questions
On 6/23/06, Jonathan Scott Duff <[EMAIL PROTECTED]> wrote: An alternate interpretation would be that the last one is actually a compile- time error because none of the sigs match (Int,Int) and for a call to work with 2 Int parameters, you'd need to be explicit: talk(~123,3); But I'm not sure which way perl6 actually leans. Though it seems to me that automatic type conversion by the compiler is a way to get yourself in trouble. Not that perl shouldn't let the programmer get himself in trouble, but this seems like one of those things that should require asking to turn on rather than asking to turn off. Synopsis 12 at http://dev.perl.org/perl6/doc/design/syn/S12.html says When you call a subroutine 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 actual 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). IMHO that seems to mean that in my example the (String, Int) version would be called because it's "the best candidate". And that would also mean that first Int is automatically converted to String. -- 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] 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 C +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
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 C 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 C parsed? (Notice the space before parens). Would that be parsed as invalid function-call (i.e. syntax error) or valid quote? -- Markus Laire
S04 - forbidden coding-style
This quote from S04
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.)
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: 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 C belongs to the
preceding block.
(And that doesn't affect auto-indenting in vim)
--
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: [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: [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 C function
+is used. The first argument, if supplied, specifies a C
+for the control structure to leave. The C 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 C subs within a module or class. (A C 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 C and
-C 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 "C" trait.
====
--
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 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. -- 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. > 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: === 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: [svn:perl6-synopsis] r11115 - doc/trunk/design/syn
On 8/18/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: +To give both a long and a short switch name, you may use the pair +notation. The key will be considered the short switch name, while +the variable name will be considered the long switch name. So if +the previous declaration had been: + +sub MAIN (:f($frompart), :t($topart), [EMAIL PROTECTED]) + +then you could invoke the program with either C<-f> or C<--frompart> +to specify the first parameter. Likewise you could use either C<-t> +or C<--topart> for the second parameter. What about combined short switches like C<-abc> to mean C<-a -b -c>? Will perl6 support this notation or not? -- 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: [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: 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:
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.
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: "
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.
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:
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.
--
Markus Laire
Compiling pugs r12925 failed
I tried to compile pugs r12925 with parrot r14364 (both current as of
yesterday) and "make" for pugs failed with this message:
...
...
/KNOPPIX/usr/bin/perl util/gen_prelude.pl -v -i src/perl6/Prelude.pm
-p ./pugs --output blib6/lib/Prelude.pm.yml
Generating precompiled Prelude... ./pugs -C Parse-YAML Prelude.pm >
blib6/lib/Prelude.pm.yml
***
unexpected "\""
expecting comment, "(", ":", operator, postfix conditional,
postfix loop, postfix iteration, ";" or "}"
at Prelude.pm line 682, column 9
Output is empty at util/gen_prelude.pl line 167.
system: [/KNOPPIX/usr/bin/perl util/gen_prelude.pl -v -i
src/perl6/Prelude.pm -p ./pugs --output blib6/lib/Prelude.pm.yml]:
Tiedostoa tai hakemistoa ei ole at util/build_pugs.pl line 516.
make: *** [pugs] Error 2
"Tiedostoa tai hakemistoa ei ole" is "No such file or directory" in english.
I checked src/perl6/Prelude.pm but didn't see anything interesting on
line 682. Maybe the linenumber was wrong?
My system is Knoppix 4.0.2 CD + ghc 6.4.1 from Debian-backports.
$ uname -a
Linux Knoppix 2.6.12 #2 SMP Tue Aug 9 23:20:52 CEST 2005 i686 GNU/Linux
--
Markus Laire
Re: Compiling pugs r12925 failed
On 9/2/06, Audrey Tang <[EMAIL PROTECTED]> wrote: 2006/9/2, Markus Laire <[EMAIL PROTECTED]>: > I tried to compile pugs r12925 with parrot r14364 (both current as of > yesterday) and "make" for pugs failed with this message: Heya. r12925 is at the middle of gaal's mad hax0ring to support :(Sig) syntax in addition to \(Capt) syntax. Can you try again? I get same error with r12939 (except that "line 516" is now "line 517") Maybe remove blib6\lib\Prelude.pm.yml before typing "make", too. There is no such file before running "make". (Not even a directory called "blib6") -- Markus Laire
Re: Compiling pugs r12925 failed
On 9/2/06, Audrey Tang <[EMAIL PROTECTED]> wrote: 2006/9/2, Markus Laire <[EMAIL PROTECTED]>: > On 9/2/06, Audrey Tang <[EMAIL PROTECTED]> wrote: > > 2006/9/2, Markus Laire <[EMAIL PROTECTED]>: > > > I tried to compile pugs r12925 with parrot r14364 (both current as of > > > yesterday) and "make" for pugs failed with this message: > > > > Heya. r12925 is at the middle of gaal's mad hax0ring to support > > :(Sig) syntax in addition to \(Capt) syntax. Can you try again? > > I get same error with r12939 (except that "line 516" is now "line 517") This is quite strange, as I cannot duplicate this failure mode; neither can others in #perl6. Nevertheless, I've attempted a fix. Can you try again with r12945? It's too late to do it today (it takes about 2 hours), and I'm not using computer tomorrow, so I'll try again on monday. -- Markus Laire
Re: Compiling pugs r12925 failed
On 9/2/06, Markus Laire <[EMAIL PROTECTED]> wrote: On 9/2/06, Audrey Tang <[EMAIL PROTECTED]> wrote: > This is quite strange, as I cannot duplicate this failure mode; neither can > others in #perl6. Nevertheless, I've attempted a fix. Can you try > again with r12945? It's too late to do it today (it takes about 2 hours), and I'm not using computer tomorrow, so I'll try again on monday. I just tried it and pugs r12945 (with parrot r14400) works :) Thanks for fixing it even if you couldn't duplicate it :) -- Markus Laire
Just dreaming ... (was: Re: Mozilla's offer of help to Perl 6 -- How about adding P6XPCOM to PyXPCOM in Gecko 1.9+ and Firefox 3?)
On 9/9/06, Conrad Schneiker <[EMAIL PROTECTED]> wrote: In: Perl 6 Design Minutes for 23 August 2006 http://use.perl.org/articles/06/09/08/2238219.shtml I saw this intriguing news: "Mozilla Foundation wants to know how they can help Perl 6" Support for
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: 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
Re: Trying to make a new operator
On 9/22/06, Richard Hainsworth <[EMAIL PROTECTED]> wrote:
Biggest problems are the following:
a) finding the symbols - I had to use two editors, and getting them to
show them on screen
Good place to see all of the symbols in Unicode is
http://unicode.org/charts/symbols.html (a lot of PDF-files there)
You could also try to find the proper symbol from
http://www.iam.uni-bonn.de/~alt/html/unicode_3.html
and then copy-pasting it to your editor.
This seemed to work for me with Firefox+KWrite after I changed the
encoding to UTF-8 (but my font didn't show all the symbols).
b) mixing types. My version of pugs does not respect the white space at
the start and end of strings. Also if the functions are given as <>, all the white space is excluded. Not sure if this is a
feature or a non-feature.
< text more text > creates a list, not a string, and is meant to
ignore the extra spaces because spaces are only used to delimit the
list-items.
(I'm not sure about <<...>>)
If you want to create strings, just use the quotes like here:
sub infix:<☥> {...};
sub infix:<☆> {...};
sub infix:<☺> {...};
(3 ☥ 40 ☆ 7 ☺ 50).say;
sub infix:<☥> ($l,$r) {
return "The $l wise men spent $r days";
};
sub infix:<☆> ($l,$r) {
return "$l following a star in the $r-th heaven";
};
sub infix:<☺> ($l,$r) {
return "$l to become very happy for $r days and nights"
};
--
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 C<0+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 C<0+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 C 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 C<1+2+3> so IMHO C<[,](1,2,3)> should be same as C<1,2,3> but S06 says that it becomes C<\(1,2,3)>. -- 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 C is a loop, "The do-once loop".
--
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: 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 C operator if necessary.
--
Markus Laire
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 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
Parrot Glossary - COW
I've been following this list for a month, but havn't yet learned what COW really means. It's used so often that perhaps it should be added to Parrot Glossary. -- 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 assertion always matches successfully, and has the side effect of deleting the parts of the string already matched. * Attempting to backtrack past a causes the complete match to fail (like backtracking past a . 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]>
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]>
[perl #16745] imcc doesn't compile anymore
# New Ticket Created by "Markus Laire" # Please include the string: [perl #16745] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt2/Ticket/Display.html?id=16745 > Compiling imcc dies on Cygwin with error "No rule to make target 'anyop.h', needed by 'imcparser.o'.
Re: Cleanup time!
On 25 Aug 2002 at 1:22, Simon Cozens wrote: > [EMAIL PROTECTED] (Dan Sugalski) writes: > > We're shooting for a release mid-next-week > > I don't wish to criticise the release process in any way, but when > someone announces a mid-week release, I don't know about you, but > I'd consider it completely inappropriate to sneak in 66K of source > changes without an email to the list, late on a Saturday night when > many of the developers might not notice its import. That code seems to be part of perl6-fixes, and working perl6 rexexps is a release target. perl6 was badly broken before, so fixes are required before release. Unfortunately, now that perl6 has got some fixes, imcc is broken so I can't test perl6 yet. -- Markus Laire 'malaire' <[EMAIL PROTECTED]>
Re: [perl #16755] imcc requires Parrot_dlopen but HAS_DLOPEN is never defined
On 25 Aug 2002 at 18:45, Tom Hughes wrote: > In message <20020825155505$[EMAIL PROTECTED]> > Tom Hughes (via RT) <[EMAIL PROTECTED]> wrote: > > > Recent changes to imcc make it require a working Parrot_dlopen but > > unfortunately as things stand it never does work because Configure.pl > > never sets HAS_DLOPEN so Parrot_dlopen is also stubbed out. > > > > There is a second problem in that platform.c only include dlfcn.h if > > a particular symbol is defined but that symbol is not defined until > > parrot.h is included which is after the include of dlfcn.h. > > Here's a patch that addresses both those issues and makes imcc > work again. I applied this patch locally, but making imcc still ends with error "cannot find -ldl" (I quess that means Parrot_dlopen library as Cygwin has no such file) -- Markus Laire 'malaire' <[EMAIL PROTECTED]>
Re: [perl #16755] imcc requires Parrot_dlopen but HAS_DLOPEN is never defined
On 25 Aug 2002 at 13:26, Sean O'Rourke wrote: > On Sun, 25 Aug 2002, Tom Hughes wrote: > > > In message <20020825155505$[EMAIL PROTECTED]> > > > > Here's a patch that addresses both those issues and makes imcc > > work again. > > Here's a patch that hopefully addresses the makefile issue. imcc.in > belongs in config/gen/makefiles/. Could you please try it out to see if > it works on your platform? I tested than on Cygwin and imcc does compile, but I have some problems: If I compile imcc with 'make imcc', most perl6 tests will fail with error "readline() on closed filehandle P6C::TestCompiler::PASM at P6C/TestCompiler.pm line 55." If I compile imcc with plain 'make' (which also remakes shared parrot), I get about 1000 lines "undefined reference to" warnings from core.ops, debug.ops, io.ops and rx.ops, but perl6 works better with only 35% test failed and no readline-errors. -- Markus Laire 'malaire' <[EMAIL PROTECTED]>
Re: [perl #16755] imcc requires Parrot_dlopen but HAS_DLOPEN is never defined
On 25 Aug 2002 at 19:28, Sean O'Rourke wrote:
> On Mon, 26 Aug 2002, Markus Laire wrote:
> > I tested than on Cygwin and imcc does compile, but I have some
> > problems:
> >
> > If I compile imcc with 'make imcc', most perl6 tests will fail with
> > error "readline() on closed filehandle P6C::TestCompiler::PASM at
> > P6C/TestCompiler.pm line 55."
>
> "make imcc" only rebuilds imcc, while the default target also makes
> libparrot.so. I suspect this is the problem, what with imcc needing
> libparrot.
>
> > If I compile imcc with plain 'make' (which also remakes shared
> > parrot), I get about 1000 lines "undefined reference to" warnings
> > from core.ops, debug.ops, io.ops and rx.ops,
>
> Does the same thing happen when you do a "make shared"
> in the base parrot directory?
"make shared" dies with 'missing .h files'
"make && make shared" gives same
"undefined reference to" warnings and then ends with
"collect2: ld returned 1 exit status
make: *** [blib/lib/libcore_prederef.so.0.0.7] Error 1"
but imcc and perl works with same 35% tests failed.
> > but perl6 works better with only 35% test failed and no
> > readline-errors.
>
> Okay. I thought it did better on Windows. What does it say when
> you run one or two of the failed tests individually? e.g.
I just checked all failed tests. Worst problem seems to be that tests
returns int/str instead of PerlInt/PerlString
t/parser/apoc1.t 1 256 11 100.00% 1
t/parser/basic.t 18 460818 18 100.00% 1-18
t/parser/exe2.t2 512 22 100.00% 1-2
t/parser/exe3.t1 256 11 100.00% 1
t/parser/exe4.t 255 65280 11 100.00% 1
t/parser/similar.t 6 1536 66 100.00% 1-6
t/parser/speed.t 255 65280 33 100.00% 1-3
apoc1:
Structures begin differing at:
$got->[0]{P6C::prefix::args}{P6C::prefix::name} = Does not exist
$expected->[0]{P6C::prefix::args}{P6C::prefix::name} = 'scalar'
basic.{1-18}, exe2.{1-2}, exe3, similar.3
$got-> ... = 'int'
$expected-> ... = 'PerlInt'
similar.{4-6}
$got-> ... = 'str'
$expected-> ... = 'PerlString'
similar.1
$got-> ... = undef
$expected-> ... = Does not exist
exe4, speed
loops parser, no tests run!
similar.2
could not parse program
--
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 backtrack fails whole match So even shorter version: :/::/:::/ makes backtrack fail current atom/group/rule/match. -- Markus Laire 'malaire' <[EMAIL PROTECTED]>
Re: [perl #16755] imcc requires Parrot_dlopen but HAS_DLOPEN is never defined
On 25 Aug 2002 at 23:01, Sean O'Rourke wrote:
> Ah, _parser_ tests! (hits self on head). Those are out-of-date, and
> should be disabled. The fact that all the compiler tests pass is a
> relief, and indicates that all is well. How does t/rx/basic.t do?
I got new cvs and applied same 2 patches (dlopen-patch & imcc-patch)
only t/rx/basic.{3,4} fails, both with same error:
Couldn't find global label '__setup' at line 1.
Couldn't find global label '_main' at line 3.
Couldn't find operator 'bsr' on line 1.
Couldn't find operator 'bsr' on line 3.
# Failed test (t/rx/basic.t at line 57) (line 88 for basic.4)
# got: ''
# expected: 'ok 1
--
Markus Laire 'malaire' <[EMAIL PROTECTED]>
Re: [perl #16755] imcc requires Parrot_dlopen but HAS_DLOPEN is never defined
On 26 Aug 2002 at 13:48, Leopold Toetsch wrote:
> > I got new cvs and applied same 2 patches (dlopen-patch & imcc-patch)
> > only t/rx/basic.{3,4} fails, both with same error:
>
> Please rebuild the grammar (there is currently no Makefile autmagic for
> this):
>
> $ perl6 --force -v --tree -- < /dev/null
That doesn't change anything, same tests fail with same error.
--
Markus Laire 'malaire' <[EMAIL PROTECTED]>
Re: [perl #16755] imcc requires Parrot_dlopen but HAS_DLOPEN is never defined
On 27 Aug 2002 at 1:49, Mike Lambert wrote: > So currently, if one does a CVS checkout on win32, and is using cygwin or > msvc, they can do: > > Configure.pl && cd languages\perl6 && make && make test > > And it should proceed to properly pass all of the compiler tests, aside > from 8_5 and 8_6, which are a bug with the perl6 compiler somewhere > (verified by sean and leo). ok, I tested that on cygwin with CVS checkout (GMT 20020827-1125) With following commands ALL perl6 tests pass. NO skipped or failed tests, not even those 8_5 and 8_6. (All tests succesful - Files=15, Tests=64) Configure.pl && make && cd languages/imcc && make imcc && cd ../perl6 && make perl6-config && make test With Configure.pl && cd languages\perl6 && make && make test make dies with missing .h file. Full log is: cd ../imcc && make make[1]: Entering directory `/home/z/cvs/cvs-parrot/languages/imcc' gcc -fno-strict-aliasing -I/usr/local/include -g -I../../include -o imcparser.o -c imcparser.c In file included from anyop.h:4, from imcc.y:17: .../../include/parrot/parrot.h:165: parrot/vtable.h: No such file or directory make[1]: *** [imcparser.o] Error 1 make[1]: Leaving directory `/home/z/cvs/cvs-parrot/languages/imcc' make: *** [imcc] Error 2 -- Markus Laire 'malaire' <[EMAIL PROTECTED]>
Re: [perl #16755] imcc requires Parrot_dlopen but HAS_DLOPEN is never defined
On 27 Aug 2002 at 11:59, Markus Laire wrote: > ok, I tested that on cygwin with CVS checkout (GMT 20020827-1125) That should've been GMT 20020827-0825 -- Markus Laire 'malaire' <[EMAIL PROTECTED]>
Re: [perl #16755] imcc requires Parrot_dlopen but HAS_DLOPEN is never defined
On 27 Aug 2002 at 11:59, Markus Laire wrote: > On 27 Aug 2002 at 1:49, Mike Lambert wrote: > > > So currently, if one does a CVS checkout on win32, and is using cygwin > > or msvc, they can do: > > ... While perl6 does work now, 'make test' for parrot doesn't work at all !!! 'make test' after 'Configure.pl && make' gives this: cd classes && make && cd .. make[1]: Entering directory `/home/z/cvs/my-parrot/classes' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/home/z/cvs/my-parrot/classes' make: *** No rule to make target `libparrot.a', needed by `test'. Stop. -- Markus Laire 'malaire' <[EMAIL PROTECTED]>
[perl #16789] 'make test' for parrot fails
# New Ticket Created by "Markus Laire" # Please include the string: [perl #16789] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt2/Ticket/Display.html?id=16789 > After recent fixes to get perl6 work on win32 & cygwin, 'make test' for parrot doesn't work anymore (while perl6 does) On win32 with cygwin 'Configure.pl && make' works, and after that 'make test' gives this: cd classes && make && cd .. make[1]: Entering directory `/home/z/cvs/my-parrot/classes' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/home/z/cvs/my-parrot/classes' make: *** No rule to make target `libparrot.a', needed by `test'. Stop. This seems to affect few other system also (see tinderbox) -- Markus Laire 'malaire' <[EMAIL PROTECTED]>
Re: [perl #16755] imcc requires Parrot_dlopen but HAS_DLOPEN is never defined
On 27 Aug 2002 at 11:59, Markus Laire wrote: > With following commands ALL perl6 tests pass. NO skipped or failed > tests, not even those 8_5 and 8_6. > (All tests succesful - Files=15, Tests=64) > > Configure.pl && make && cd languages/imcc && > make imcc && cd ../perl6 && make perl6-config && make test Another typo (I'll be more carefull in future). 'make imcc' there should be just 'make' which means that this also works: perl Configure.pl && make && cd languages/perl6 && make && make test -- 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: Hypothetical synonyms
This really belongs to perl6-internals and not perl6-language. On 28 Aug 2002 at 17:19, Sean O'Rourke wrote: > On Thu, 29 Aug 2002, Markus Laire wrote: > > (only 32bit numbers, modulo not fully working, no capturing regexps, > > ) > > Where does modulo break? Modulo is currently defined for Perlint (and only with integers) and not for Perlnum. So once a scalar contains a fractional number, modulo doesn't work anymore. Currently I don't have enough knowledge of parrot or perl6 source to submit any patches, but maybe in future. -- Markus Laire 'malaire' <[EMAIL PROTECTED]>
Re: [PRE-RELEASE] Parrot 0.0.8
> Codename Octarine > > Schedule as follows: > > August 29, 8am EDT: Code slush, only bug and warning fixes allowed. > August 30, 11:59pm EDT: Code freeze and pretag > August 31, 00:59 EDT: Tag and Release Is there any reason to not to use GMT times in general? I have hard time remembering all the different TLAs for timezones. -- Markus Laire 'malaire' <[EMAIL PROTECTED]>
Re: [perl #16874] [BUG] Concatenation failing
> I have a weird bug where concatenation is sometimes failing, and I > have no idea why. See the attached pasm. I fully expect both works and > weird to output "foo", "bar", "quux" with various levels of spacing, > but weird doesn't output quux. > ... If I add just one print-command to that code, concatenation works as expected. Without commented 'print S15' line, this prints "wierd: [foo bar]" with additional 'print S15' line, this prints "foo wierd: [foo bar quux]" which is OK. So this bug isn't (only) in concat-opcode. set S0, "foo " set S1, "bar " set S2, "quux" set S15, "" concat S15, S0 print S15 # add this line and concatenation works concat S15, S1 concat S15, S2 print "wierd: [" print S15 print "]\n" end -- Markus Laire 'malaire' <[EMAIL PROTECTED]>
Re: [perl #16874] [BUG] Concatenation failing
> I have a weird bug where concatenation is sometimes failing, and I > have no idea why. > ... While trying to find shortest code which reproduces this, I found probably related bug where string is overwritten by a constant in memory. set S0, "" set S1, "ABCDEFGHIJK" set S2, "123456789012" concat S0, S1 concat S0, S2 print "This text overwrites part of S0 :\n" print S0 end which prints: This text overwrites part of S0 : ABCDEFGHIJK1This text o You can change lengths of S1 and S2 a bit, and this still works. Overwritten part always starts at 4-character boundary. -- Markus Laire 'malaire' <[EMAIL PROTECTED]>
Re: Regex stuff...
On 31 Aug 2002 at 0:17, Piers Cawley wrote:
> my $pattern = rx:w / $1:=(\S+) = $2:=(\S+) |
> $2:=(\S+) = $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+) = $b:=(\S+) |
> $b:=(\S+) = $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+) = $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+) = $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+) = $2:=(\S+) |
> > $2:=(\S+) = $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: Parrot: maximizing the audience
On 3 Sep 2002 at 22:17, Jerome Quelin wrote: > Hi there, > > As a recent parroter, what striked me most while reading perl6-internals, is > that it's very perl-centric. Ok, I agree that: > ... > * the name "perl6-internals" is really too restrictive (but this point has > already been discussed last week). > ... Would it be possible to rename "perl6-internals" now to something better like "parrot-internals"? There probably are some big problems in renaming an active list, but this could give us more non-perl developers interested in parrot. -- 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 / | 1 | 7/". > > Then, why is there a C<+>? Why not make it C<|>? > > $foo = rx/ <||[cde]>|f / Because it's good to have MTOWTDI. (= More than one way to do it) -- Markus Laire 'malaire' <[EMAIL PROTECTED]>
Re: [perl #16937] Cygwin testers needed
On 6 Sep 2002 at 11:15, Andy Dougherty wrote:
> I've been told that my patch #16937 (which changes ld_shared from the
> hard-wired wrong value of -shared to $Config{lddlflags}, which is the
> variable designed in perl5 for this precise use) breaks cygwin. But in
> the current state of affairs, without this patch, every other build that
> doesn't use GNU binutils is broken.
>
> Could a cygwin user please try applying my patch? I'd be happy to work
> with you to resolve any problems.
I just tested that on cygwin.
Perl Configure.pl && make && cd languages/perl6 && make
dies at perl6-make with error
/usr/lib/libcygwin.a(libcmain.o)(.text+0x81): undefined reference to
`WinMain@16'
In Makefile there is line 'LD_SHARED = -s -L/usr/local/lib'
Full output for perl6-make:
cd ../imcc && make
make[1]: Entering directory `/home/z/ramdisk/parrot/languages/imcc'
bison -v -y -d -o imcparser.c imcc.y
gcc -fno-strict-aliasing -I/usr/local/include -g -I../../include -o
imcparser.o -c imcparser.c
flex imcc.l
gcc -fno-strict-aliasing -I/usr/local/include -g -I../../include -o
imclexer.o -c imclexer.c
gcc -fno-strict-aliasing -I/usr/local/include -g -I../../include -o
imc.o -c imc.c
gcc -fno-strict-aliasing -I/usr/local/include -g -I../../include -o
stacks.o -c stacks.c
gcc -fno-strict-aliasing -I/usr/local/include -g -I../../include -o
symreg.o -c symreg.c
gcc -fno-strict-aliasing -I/usr/local/include -g -I../../include -o
instructions.o -c instructions.c
gcc -fno-strict-aliasing -I/usr/local/include -g -I../../include -o
cfg.o -c cfg.c
gcc -fno-strict-aliasing -I/usr/local/include -g -I../../include -o
sets.o -c sets.c
gcc -fno-strict-aliasing -I/usr/local/include -g -I../../include -o
debug.o -c debug.c
gcc -fno-strict-aliasing -I/usr/local/include -g -I../../include -o
anyop.o -c anyop.c
gcc -o imcc imcparser.o imclexer.o imc.o stacks.o symreg.o
instructions.o cfg.o sets.o debug.o anyop.o ../../platform.o -lcrypt
cd ../.. && make shared && rm -f parrot.exe && make
make[2]: Entering directory `/home/z/ramdisk/parrot'
mkdir blib
mkdir blib/lib
cd classes && make && cd ..
make[3]: Entering directory `/home/z/ramdisk/parrot/classes'
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory `/home/z/ramdisk/parrot/classes'
gcc -s -L/usr/local/lib -s -L/usr/local/lib -o
blib/lib/libparrot.so exceptions.o global_setup.o interpreter.o
parrot.o register.o core_ops.o core_ops_prederef.o memory.o
packfile.o stacks.o string.o sub.o encoding.o chartype.o
runops_cores.o trace.o pmc.o key.o hash.o core_pmcs.o platform.o
jit.o jit_cpu.o resources.o rx.o rxstacks.o embed.o warnings.o misc.o
core_ops_cg.o packout.o byteorder.o debug.o smallobject.o headers.o
dod.o method_util.o io/io.o io/io_buf.o io/io_unix.o io/io_win32.o
io/io_stdio.o classes/array.o classes/boolean.o
classes/continuation.o classes/coroutine.o classes/csub.o
classes/default.o classes/intqueue.o classes/key.o
classes/multiarray.o classes/perlarray.o classes/perlhash.o
classes/perlint.o classes/perlnum.o classes/perlstring.o
classes/perlundef.o classes/pointer.o classes/sub.o
encodings/singlebyte.o encodings/utf8.o encodings/utf16.o
encodings/utf32.o chartypes/unicode.o chartypes/usascii.o -lcrypt
/usr/lib/libcygwin.a(libcmain.o)(.text+0x81): undefined reference to
`WinMain@16'
collect2: ld returned 1 exit status
make[2]: *** [blib/lib/libparrot.so] Error 1
make[2]: Leaving directory `/home/z/ramdisk/parrot'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/home/z/ramdisk/parrot/languages/imcc'
make: *** [imcc] Error 2
--
Markus Laire 'malaire' <[EMAIL PROTECTED]>
Re: Goal call for 0.0.9
On 9 Sep 2002 at 15:02, Andy Dougherty wrote: > On Mon, 9 Sep 2002, Sean O'Rourke wrote: > > > None of the stuff in languages/ is part of the default build, and I think > > it should stay that way. It seems like bad form to, by default, build > > parts of a package that the user may not want to use. > > Yes, I agree in general. But the down side is that it's neither built nor > tested by most users (including the tinderboxes!). On balance, I think we > should use bad form and build parts that users may not want to use in > order to give them a workout. IMHO it's fine to build few extra parts by default to test them while we are still developing. Those parts can always be removed for release versions. At least perl6 (and imcc which it needs) could be added to default build, and perhaps also scheme if it's going to be first fully working language. -- 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: Backtracking syntax
> Backtracking syntax includes: > > :, ::, :::, , > > 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 and 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 > :// # cut I find :,::,::: to be a lot easier to remember than :,:],:> - and also easier to type. While and don't follow same syntax, I don't really see any better solutions. Better solution should IMHO keep :,::,::: and offer better alternative only to . 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 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 and don't follow same syntax, I don't really see > > any better solutions. > > 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 goes further to possibly affect other rules also, so it must have different syntax. -- Markus Laire 'malaire' <[EMAIL PROTECTED]>
Re: Regex query
And the one best reason I forgot to include: How do you do C< ($a + $b) * $c > if parentheses are forbidden for mathematical expressions? -- 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: /(.*?) [ | $$]/
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: 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: 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: 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: 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: Perl6 Operator (REMAINING ISSUES)
On 31 Oct 2002 at 16:04, Brent Dax wrote: > Markus Laire: > # Emacs and vim also works on Windows, not just UNIX. > > So does DOS 'edit'. That doesn't mean Windows users use it. Windows > users want tools that look and act like Windows tools--if they didn't, > they'd be using another OS. Neither GNU emacs nor xemacs fits the > bill, and I doubt vim does either. gvim looks and acts a lot like usual Windows editors if you install it in proper 'windows compatible' mode. Still it is a bit different. -- 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: 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: Initial notes
On 9 Nov 2002 at 18:56, Andrew Wilson wrote: > Starting small sounds like a good idea. I'm not so sure about trying to > "lock things down" before moving on. I don't think that will be > possible in any meaningful way. The problem with trying to lock things > down is that the design team are refining the design as they go. If > something isn't working they change it. > > I will be happy to be proved wrong about this but I have a feeling that > too much attention to detail will get us bogged down. I also think that we shouldn't try to provide too exact and final documentation at once. Just define each area "with enough detail" (whatever that means) and then move on. Until whole language-design is somewhat complete, there will be things which requires earlier decisions to be changed. -- Markus Laire 'malaire' <[EMAIL PROTECTED]>
Re: faq
On 12 Nov 2002 at 16:40, Marius Nita wrote: > Hello, > > I have a question about the Parrot FAQ. I hope it's not too > off-topic for this list. The FAQ mentions that "it would be nice to > write the Perl to Bytecode compiler in Perl" and that there is no > bootstrap problem. > > Does this mean that the perl6 compiler is written in perl5 and it > will be rewritten in perl6 when a large enough subset of perl6 is > implemented? I figure Perl5 will be obsolete at some point in the > future... perl6, or parrot, or something else which runs on parrot. With parrot you have a lot of possibilities on which languages to use (once it's complete). > I noticed that the current incomplete perl6 implementation is written > in perl5 using Parse::RecDescent, but I figured it's just a test > implementation until the "real" compiler is written in C... perl5 won't be used anywhere when all is ready. There will be small 'miniparrot' (currently in development), which can be build with just C compiler [was anything else required?]. Miniparrot can then be used to build everything else, including full parrot, perl6, other parrot-supported languaged, etc.. This 2nd step might be e.g. Bytecode-compiled perl6-program which is simple enough to work with miniparrot. (Here might be some mistakes, but this is as I understand this, based on active lurking here) -- Markus Laire 'malaire' <[EMAIL PROTECTED]>
Re: Numeric Literals (Summary)
On 15 Nov 2002 at 12:02, Dave Whipp wrote: > A couple more corner cases: > > $a = 1:0; #error? or zero Shouldn't base-1 be: 1:0 == 10:0 1:1 == 10:1 1:11 == 10:2 1:111 == 10:3 1:1010111 == 10:5 etc.. Also 0:0 == 10:0 -- Markus Laire 'malaire' <[EMAIL PROTECTED]>
