Re: Retry: ITypes and VTypes.
On Fri, 4 Feb 2005 04:09:03 +0800, Autrijus Tang [EMAIL PROTECTED] wrote: ... Let's take the first one first, because it is what S06 seems to imply, although it is against Perl5's tie() intuition: my @carton is Scalar; # assuming this is the default Now @carton implements the same set of behaviour as $spot. It essentially means that every variable is a scalar variable, and the only different of @carton vs $spot is that @carton applies list context to its right hand side in assignment and binding, while $spot applies scalar context. I asked that before, and answer was: On Tue, 30 Nov 2004 14:13:52 -0800, Larry Wall wrote: ... I think the only place they differ is in list context. @a always interpolates, and $a never does. and everywhere else they would work the same. rather little difference to have different namespaces, huh? I still have some doubts. How could I make a reference to array? looks like this should work in perl6, because of scalar context: $arref = @arr; or the perl5 way. is it the same somehow? or is it wrong in perl6? $arref = [EMAIL PROTECTED]; and the mentioned problem is interesting too.. my @array is Scalar; # this isn't the default, as I know @array = (1,2,3); how such a weird var would behave? my $var = test; my @arr := $var; error? or maybe it would be the same weirdness, like in former example? or maybe it's a [test]?
strictness and fully qualified global vars
in perl5 Cuse strict doesn't save us from typo bugs in code like
use strict;
print $OtherPackage::erroneuos_name;
in perl5 Cour $var auotovivifies ${__PACKAGE__ . ::}{var} glob at
compile time, so there's something one could check with Cexists, but to
do it manually is senseless.
And there are no globs in perl6..
So, what about perl6? would it be possible to require declaration of
global vars before their first use, even if vars in question are in other
package? would it be default behaviour?
hmm, I wonder, is there any sense in Cour $Package::var in that case.
P.S. I have one (almost unrelated to topic) observation: if sigil is a
part of a variable name, then C Package::$var makes more sense than
perl5 C $Package::var . (AFAIK, PHP5 works this way) And this requires
less magic from perl.
On the other hand it's considerably harder to interpolate that..
Re: state vs my
On Sat, 4 Dec 2004 22:03:19 -0800, Larry Wall [EMAIL PROTECTED] wrote:
On Sun, Dec 05, 2004 at 02:15:51AM +0300, Alexey Trofimenko wrote:
: oh! that it. I've found example which could make it clear to me
:
: sub test {
: return sub {
: for 1..3 {
:state $var = 1;
:print $var++
: }
: }
: }
:
: $a = test; $a() for 1..3; print ';'
: $b = test; $b() for 1..3;
:
: that could print, for different possible definitions of state:
: 1) 123123123;123123123
: 2) 123456789;123456789
: 3) 123456789;101112131415161718
:
: looks like you meant third(!) variant.. but it doesn't make any sense
: for me.
I don't know how you even get the third variant. I think it should be 2,
though I see how you'd get 1 if you think a loop clones every time
through.
third variant is what we get if we replace Cstate with perl5 my $var if
0 here (not exactly, because $var start value would be undef in that
case).
Certainly that one doesn't, since it doesn't refer to any external
lexicals.
Perhaps statehood should be limited to official subs just like
return is.
they must be limited. It would be really strange if
sub test {
for 1..3 {
state $var = 1;
print $var++
}
}
test();test();
and
sub test {
my $a;
for 1..3 {
do_something_with($a);
state $var = 1;
print $var++
}
}
test();test();
would print different results.
But actually I would prefer if state somehow could be made to work other
way, even if closure isn't cloned. I mean, first variant, mentioned at top
of the message. Then we could use state vars in things like:
# I know that _this_ particular task could be solved better
# I'm not good in examplification.
%hash = map {state $k=1; $_ = $k++ } @array;
and always get our keys numbered from 1. And one still get behaviour(2) if
state declaration is at start of subroutine.
(Hmm, but I can't figure if it is possible )
This applies to FIRST {...} blocks too.
for 1..10 {
for 1..3 {
FIRST {...}
...
}
}
I'd expect that FIRST would be fired 10 times, not only once, because
FIRST looks here just as a mere funny loop control structure.
and of course I don't want it to happen once here, and 10 times there,
depending on such a subtle thing as appearance of outer lexical variables
in inner block. hmm.. but I don't want unnecessary cloning either, if it'd
slow down my program. I have a cake, please show me where to bite:)
Re: pull put (Was: Angle quotes and pointy brackets)
On Mon, 06 Dec 2004 12:22:22 GMT, Smylers [EMAIL PROTECTED] wrote: David Green writes: I guess we could always use prepend/append, pull/pop. No! Cpush and Cpop are a well-defined pair, not just in Perl, for dealing with stacks; we should keep those as they are. (And no synonyms, before somebody suggests any!) Yeah. Cpush and Cpop are old and glorious ones (asm comes to mind), and Cshift is too (even DOS .bat files used it, AFAIR), and it's a one of the most used perl5 CORE:: ops (it's more common than other three) .. And I like to shift :) the only doubtful word for me is unshift. Althought I would be pretty happy if we leave it as is, Cput is nice and short. but please don't swap meanings of old ops! if old push suddenly would try to unshift something, it could bring some perl5 programmers to hospital.
Re: state vs my
On Fri, 3 Dec 2004 21:25:39 -0800, Larry Wall [EMAIL PROTECTED] wrote:
On Sat, Dec 04, 2004 at 06:31:35AM +0300, Alexey Trofimenko wrote:
:
: for 1..10_000_000 {
: my ($a,$b,$c) = ...
: ...
: }
:
: vs.
:
: for 1..10_000_000 {
: state ($a,$b,$c) = ...
: ...
: }
:
: latter looks like it would run faster, because no reallocation envolved
: here.
Er, how did you try a state variable in Perl 5? It doesn't have state
variables...
I've emulated state vars like this:
instead of
for (...) {
my $a = ...;
...
}
i've written:
{ my $a;
for (...) {
$a = ...;
...
}
}
I think, effect is the same, (of course only if state vars declared at the
top of the block)
(second variant IS faster in perl5. slightly:)
perl timeit { my $a; for (1..10_000_000) { $a=10 } }
3.149s
perl timeit { for (1..10_000_000) { my $a=10 } }
4.709s
)
P.S.
btw, what about
my @rray;
# i'm starting to like that sigil is a part of name idea :)
for 1..10 {
{
push @rray, \( state $calar )
}
}
say @rray[0] == @rray[1]
what is the scope of state vars exactly? Common sense tells me that it
should be exactly the same as i've shown in second snippet above.. and
latter snippet would say undef.. so Cstate is just a syntactic sugar for
Cmy, which also allow us to remove redundant outer block. is it?
P.P.S. ah, offtopic. I've forgot, are bare self executing blocks outlawed
now? we have an ambiguity otherwise:
sub test {
...
{ #some bare block
...
}
}
looks like test() could return that block as closure in scalar context,
but would execute it immediately in void. wow:)
I should reread apocalypses, definitely..
Perl 5 already stores all the lexicals in the pad for the entire
subroutine. There is no separate pad for the inside of the loop.
Any differences in performance would be related to the actual
reinitialization of the lexical, not allocation.
hmm.. looks like heavy magic is involved here. Because perl5 makes a
feeling that every _block_ has it's own lexical pad. so, does it mean that
my $vars deallocated only on exit from surrounding subroutine, not from
nearest surrounding block? my experience show opposite, but I could be
wrong..
(or I just misunderstood conception of lexical pads)
iterators and functions (and lists)
hm.. consider that:
perl5:
open $fh, 'file';
$first_line = $fh;
@remaining = $fh;
perl6:
$fh = open 'file';
$first_line = $fh();
@remaining = $fh();
I thought about parallels between arrays and iterators, and realized that
they aren't very close to each other:
iterators are much closer to subroutines. And moreover, in perl5 they ARE
subroutines. In abstract, arrays are things with plenty of access methods
and iterator is the thing with a single action: one more result, please.
and that simplicity IS a power.
so why not just CALL our iterator?
of course, that analogy isn't going to work for true functions, which
returns the same all the time, for some given set of arguments.
so, of course, arrays and iterators should be interchangeable, but it
could be kin to an autoconversion. And we for sure have no need to convert
iterator to array so that we should convert it back again later, for
Cfor etc. (as some people here already stated)
ok, structured part of my brain is over.. now,
random thoughts:
$fh(:chomp)
for $fh {...}
for $fh.assuming(:chomp) {...}
# what about making foo( :bar ) the same as
# foo.assuming( :bar) ? ah, that not gonna work.. but I
# think that feature definitely wants something more short
# than .assuming; maybe even some special syntactic honey.
# because it's fun(ny|ctional)
class Foo {
has $.counter;
# multi postcircumfix:( ) makes me sick :(
method bar is default {
$.counter++;
}
}
# emulating 10...
$a = new Foo :counter(10);
say $a.bar;
say $a();
# other thingies:
sub foo { ... };
@array = @foo # all the results of foo, lazily.
maybe @array and @array() could make a sense too:
$fibonacci = {
state ($a, $b) = (1,1);
while $b 100 {
($a,$b) = ($b, $b+$a);
yield $a
}
}
(ah, that isn't very short and impressive.. I need to study a course of
Design of Short and Impressive Examples, by Damian or Mark-Jason,
maybe.)
for @$fibonacci ... # or...
for $fibonacci ... # or...
for $fibonacci ...
interesting problem: how could we iterate through a list of iterators, one
by one, without flattening 'em?
and the very last and most important problem: I have no idea how we could
signal an end of sequence. Throw an exception? return undef but
something_special?
or maybe even perform some self-destructing action?
{
undef whatever_we_have_at_this_moment_standing_for_current_function
if end_condition
}
Re: Arglist I/O [Was: Angle quotes and pointy brackets]
On Sat, 04 Dec 2004 11:03:03 -0600, Rod Adams [EMAIL PROTECTED] wrote:
Larry Wall wrote:
for =$*IN {...}
for =$*ARGS {...}
for =foo.c {...}
for =foo.c foo.h {...}
for =$foo.c $foo.h {...}
for =['foo.c', 'foo.h'] {...}
for =['.myrc', @*ARGS] {...}
for [EMAIL PROTECTED] {...}
for = {...}
The simplicity is nice, but the visual message is, well, icky.
It might be salvageable by having the ='s balance, yielding:
for =$*IN= {...}
for =$*ARGS= {...}
hm. we have short and strange FH, for input.. (and for some reason, it
is bracketing! there's no sense at all in it)
..but we have long (and even looking slightly OOish, in perl5 sense) print
FH for output, and noone complained. We still aint going to have funny
syntax for output, and we not going to keep old syntax for input. Why to
reintroduce even more strangeness with that unary =, which is actually a
simple list operator, which doesn't desire for huffmanizing?
I don't think that would hurt anyone
for lines file1 file2 file3 {...}
# or
for files file1 file2 file3 {...}
# or
for lines @*ARGS {...}
# or just that special case:
for lines {...}
but actually everybody just miss that short and strange
while () {...}
and how all other handles would be accessed is much less concern.
it's just a bad and beloved habit, IMHO.
maybe we could make a special case.. (C programmers would be shocked)
for () {...}
Re: Arglist I/O [Was: Angle quotes and pointy brackets]
On Sat, 04 Dec 2004 11:03:03 -0600, Rod Adams [EMAIL PROTECTED] wrote:
Okay, this rant is more about the \s\s than \s=\s. To me, it is easier
to understand the grouping of line 1 than line 2 below:
if( $a$b $c$d ) {...}
if( $a $b $c $d ) {...}
In line2, my mind has to stop and ask: is that ($a $b) ($c $d),
or $a ($b $c) $d. It quickly comes to the right answer, but the
question never comes up in the first line. If I wanted to use more
parens for clarity, I'd use LISP.
I've got used to write it as
if( $a $b and $c $d) {...}
already. if it could help.. :)
Re: state vs my
On Sat, 4 Dec 2004 11:33:10 -0800, Larry Wall [EMAIL PROTECTED] wrote:
On Sat, Dec 04, 2004 at 08:03:45PM +0300, Alexey Trofimenko wrote:
: P.S.
: btw, what about
:
: my @rray;
: # i'm starting to like that sigil is a part of name idea :)
: for 1..10 {
: {
:push @rray, \( state $calar )
: }
: }
:
: say @rray[0] == @rray[1]
still your answer doesn't make it clearer. would this print 1 or undef?
I assumed it would say undef, but you said that state vars are reallocated
only on function cloning, whatever it is.. so state vars are owned by
functions, not bare blocks. If so, then it DOES print 1, doesn't it?
ah, that was a bad example, I can see now..
I thought, its primary use is for closures:
sub test {
my $a=10;
return sub { $a++ }
}
vs
sub test {
return sub {state $a=10; $a++ }
}
$func1 = test;
$func2 = test;
would closures in $func1 and $func2 share the SAME $a?
or is it that function cloning you said?
oh! that it. I've found example which could make it clear to me
sub test {
return sub {
for 1..3 {
state $var = 1;
print $var++
}
}
}
$a = test; $a() for 1..3; print ';'
$b = test; $b() for 1..3;
that could print, for different possible definitions of state:
1) 123123123;123123123
2) 123456789;123456789
3) 123456789;101112131415161718
looks like you meant third(!) variant.. but it doesn't make any sense for
me.
temp $var;
my $var=foo;
{
temp $var;
say $var;
}
would it be undef or foo? if the former, how could I make $var to
contain a copy of original content?
using analogy with my $x = $x, that's not going to work..
temp $var = $OUTER::var?
OTOH,
my @a = ... # something not lazy with 10_000_000 elements..
{
temp @a; # ouch! temporal clone!
}
that could hurt..
state vs my
for 1..10_000_000 {
my ($a,$b,$c) = ...
...
}
vs.
for 1..10_000_000 {
state ($a,$b,$c) = ...
...
}
latter looks like it would run faster, because no reallocation envolved
here.
I've read an advice somewhat like that in Ruby docs, tried it on perl5,
and it really makes a difference, especially on very short loops.
could it be done some tricky optimisation, so if some variable in loop
isn't going to have references on it, stored somewhere outside the block,
than Cmy before it will be changed to Cstate?
Re: Angle quotes and pointy brackets
On Tue, 30 Nov 2004 10:43:10 +0100, Juerd [EMAIL PROTECTED] wrote:
Alexey Trofimenko skribis 2004-11-30 9:09 (+0300):
delimiters should have corresponding closing character, so it should be
something like
Please, stop seeing ` as a circumfix operator in this context. What you
do is like saying that after . you expect a capital letter. It's a
programming language, and the only definition useful is the language
itself, disregarding other languages, like Perl 5 and English.
In current Perl, :: is also known as '. And that's not a quoting
character in that context. In an early Apocalypse, Larry said not to
make the same mistake again because it would be hard to syntax-colour.
But that doesn't quite count, as matching for editors will have to be
rewritten anyway to support things like $foo{bar}.
I have several editors even on windows, and not even specially written for
perl, which do color ' as :: correctly. Personally, I liked that syntax,
it has some similarities to Ireland surnames:) $O'Hara{Scarlett}
but it puts big restrictions on what can be part of the name (actually,
thoose which match to ident only), so $package'$varname won't work.
I meant only that your ` can't be replacement to because latter allows
MUCH more freedom in key names. Actually, only space has special meaning
here.
so, could you be more explicit, what rules your syntax have?
$a`$b+$c`$d, is it equivalent of
$a[$b+$c][$d] or
$a[$b]+$c[$d] ?
and I think, polymorphic treating of ` as either {} or [] adds some
overhead.. and unstability of your code. Especially in cases like $a`$b,
when compiler just can't see in compiler time, what could be contained in
$b - number or string.
only one variant of that syntax looks for me useful:
$var`Only`Ident`Compatible{$strings}`Here123
as replacement for
$var{'Only'}{'Ident'}{'Compatible'}{$strings}{'Here123'}
so ` works here exactly as Java(ECMA)Script .
no spaces allowed, no expressions, and it is always a HASH subscript.
doesn't lua have that prefix `Quoting behavior already? ( 'text' eq `text
) or it was some other language? If to mimic it, than
$var`Only`Ident`Compatible{$strings}`Here123
could be automatiaclly transformed into
$var'Only''Ident''Compatible'{$strings}'Here123'
Macro definition for it could be very simple, like
macro postfix:` is parsed {ident} {return '$0'} or something like.
%hashkeyanotherkey[1]=0
%hash'key''anotherkey'[1]=0
:keyvalue
:key'value'
This is just making parens/curlies optional for more operators than
.
but :key'value' is the same as :keyvalue.. distinction shown only on
occasional spaces in ''.
$var.key1key2[1].key3 # yikes, but still better than
Still hard to type. Simply put, repeated circumfix operators suck,
regardless of whether they are , , , '', [], {}.
hm, I thought something like this long time ago, when I come to perl and
some other languages from pascal, where you could address a 3dimensional
array with a[1,2,3] instead of a[1][2][3]; but there was no problem at
all, it's a matter of habit. now I consider latter more readable and
flexible.
Re: Angle quotes and pointy brackets
Matthew Walton wrote:
James Mastros wrote:
Larry Wall wrote:
On Fri, Nov 26, 2004 at 07:32:58AM +0300, Alexey Trofimenko wrote:
: ah, I forget, how could I do qx'echo $VAR' in Perl6? something like
: qx:noparse 'echo $VAR' ?
I think we need two more adverbs that add the special features of qx
and qw,
so that you could write that:
q:x/echo $VAR/
where ordinary qx/$cmd/ is short for
qq:x/$cmd/
I think I'd like that much better if we consider execution and
word-splitting to be the primary operations, and interpolation and
noninterpolation the adverbial modifiers then the other way around,
making that qx:q/echo $VAR/ or qx:qq/$cmd/.
especially because adverbs are meant to say how to do rather than what
to do, aren't they?
OTOH, I expect backticks to be rare enough that I wouldn't mind writing
use Spawn 'spawn';
spawn :capture :wait ($cmd);
spawn :capture :wait ('echo $VAR');
Although I'm masochistic enough that I don't mind the idea of always
having to do execution with qx//, qx:q// or qx:qq// (running with other
suggestions, I'd guess that would be non-interpolating execution, then
the same again more explicitly, then interpolating execution) but I do
like the idea of spawn.
hm.. qx:q// qx:qq//
...compare with:
qx q// qx qq//
so there's no need in adverbs. But we have no need in qx either. Why to
introduce (or REintroduce) something if we have something similar already?
$captured = system :capture q/cmd../;
or maybe even:
(code=$code, out=$captured, err=$err) = system qq/cmd/;
or maybe even(!)
$captured = slurp qq/$cmd |/;
Kind of removes the idea of pulling in the output of other programs as a
fundamental part of the language though, for that it's nice to have an
executing, capturing quote. Perhaps an adverb to qx that makes it behave
like system() - I don't think it'd be a good idea to provide one that
makes it behave like exec(), although perhaps other people do.
I haven't that long unix background, and spawning processes is a very
*fat* operation for me.. maybe after year or two I'll change my point of
view, but for now I would be pretty happy with a 'slurp' variant. IMHO,
spawning processes has nothing to do with other quoters, and perl already
went far away from shells.
but talking about oneliners and short shell-like scripts, where `` is
pretty useful.. hm.. things good for oneliners are rarely as good for
larger programs, and vice versa. Of course, Perl5 proves opposite, but
Perl6 tends to be a little more verbose, and even in Perl5 we use quite
different toolbox and style for mentioned above. Why not to make an
average sized module of various shortcut grammars, with a very short
name (x, f.e.), with defaults to export :all, so we could just do
perl -Mx -e 'print `echo this is a perl5qx`'
even if `` would be taken for something more useful in Perl6,
and still be able to import only something useful for our larger program
with
use x qw/:perl5qx/;
Re: Angle quotes and pointy brackets
On Sat, 27 Nov 2004 11:36:14 +0100, James Mastros [EMAIL PROTECTED] wrote: Larry Wall wrote: Likewise a qw/a b/ is short for q:w/a b/ qw:q/a b/ $fromvar = 'foo bar'; qw:qq/a something with spaces b $fromvar/ # ?? -- slightly OT, but is that a, 'something', with, 'spaces', # b, 'foo bar', or... um, what? Is qw smart enough to allow # internal quotes? Does splitting take place before or after # interpolation if it's interpolating? I like the idea that q would be the most general quoter, which could be used (with corresponding adverbs) instead of qq, qw, and heredoc, but qq and qw still exists in core as handy shortcuts for most frequent variants. something like (abstract) qq ::= q.assuming(:qq) (I don't know how to write it correctly - q isn't a function..) ... :s(0) adverb for specifying interpolating level for quoters seems kinda strange to me. First, it is harder to remember numbers than something symbolic. Second, there's going to be several interpolation layers, and some of them are independent of others, so having only one argument is insufficient. we would (not) want to interpolate: variables, functions, methods, \n \t and alike, backslashed delimiters backslashed backslashes ... and something also, i forgot what exactly:) and someone could want only some of the options.. heredocness should be just an adverb for all other type of quotes. personally I would be very glad to have shell-like quoting in qw, as James Mastros suggests above. It could save many keystrokes in definition of long lists where one occasional space-containing element happens to exist. some other cool variants: heredoc-qw which would see only \n as elements delimiter, and would strip leading and ending whitespace (for system) heredoc-qw for list of lists (\n as a row separator) heredoc-qq without ending \n I think, some interesting variants of scalars quoting could be borrowed from YAML(serialization language). think of folded scalars, #comments etc.. hmm.. maybe someone has ideas how to add custom behaviours for q without rewriting it? I mean, how to define custom :adverb for it..
Re: $ @ and %
P.P.P.S. If answer on my why? would be just because! I would take it silently. yes, answer was as I predicted above. I promised.. ..but: As far as I understood, arrays and hashes, and references them are much more similar in Perl6 than it was in Perl5. F.e. we have @a and $a = [EMAIL PROTECTED]; the same: push @a,1,2,3 push $a, 1,2,3 $b = @a $b = $a (?) say @a[] say $a[] (?) myfunc( [EMAIL PROTECTED])myfunc ( *$a) ... were all thoose right? hm.. i'm not so competent to continue that list.. could anyone kind make a comparison table? yes, please! I think, answer could be very informative for other readers too. and even could make it's way to perl6 documentation. So, where's @a and [EMAIL PROTECTED] are the same, and where they aren't? in all other places where they work different, we could use @$a in place of @a, right? if @ in @a is a part of name, would @$b work? and what's that @ here, behind the scenes? operator? macro? ... P.P.P.P.S open $file, filename; print @file; ... ..er, in that case: open $file, filename; print @$file; i mean, what about using objects(files, iterators, etc) as arrays? AFAIK, we will have custom subscripting defined on our objects, so $file[10] could be made to work, but what about @$file, or @($file) or $file[] (um, maybe $file[*], I forgot) would it make any sense? and, one more question: if we would have both tying (arrays which call hidden object methods) and objects which could act as array references, where's a difference between them? could it be THE same? Should it? could we write my $a = new ArrayLikeClass; my @b := @$a; or my @b := $a; (which one is right?)
Re: Angle quotes and pointy brackets
On Fri, 26 Nov 2004 09:33:49 -0800, Larry Wall [EMAIL PROTECTED] wrote:
On Fri, Nov 26, 2004 at 07:32:58AM +0300, Alexey Trofimenko wrote:
: I notice that in Perl6 thoose funny and could be much more common
: than other paired brackets. And some people likes how they look, but
: nobody likes the fact that there's no (and won't!) be a consistent way
to : type them in different applications, wether it's hard or easy.
...
: We also have another ascii pair, and . maybe they could be better
: than and ?:) i'm not that farseeing, but isn't problem of :
distinguishing as a bracket and as an comparison operator no harder
: than distinguishing as bracket and as part of heredoc?..
It would get very confusing visually, even if the computer could sort it
out:
@a = @b
@a = @b
But there are some things that would be completely ambiguous:
%hashfoobar
%hashfoobaz()
I not meant to replace it everywhere. But problem still exists.
I know about only four uses of and . Tell me if there's more?
1) hyperoperators;
@a = @b * @c @a.method
@a = @b * @c @a.method
(and, of course, mentioned in the past supercool 7-chars =:=
operator!)
hm.. IMO, hyperoperations are fat enough to be fat even in code. I
wonder only if whitespace allowed there:
@a = @b * @c @a .method
2) qw//-like construct;
@array = foo bar baz
@array = foo bar baz
@array = qwfoo bar baz
once again, there's nothing wrong. Although, using just foo bar baz
would confuse Perl6 no more than globs and filehandles confuses Perl5.
want an operator/want a term rule applies here.
3) pair(adverb) value quoting;
myfunc :foobar :barbaz
myfunc :arrayvalue1 value2 value3
myfunc :foobar :barbaz # this certainly suck
myfunc :foo(bar) :bar(baz) # I'm going to use that if it works(?).
# still this suck less:
myfunc :array value1 value2 value3
# ..than:
myfunc :array(value1, value2, value3)
but replacement of with plain here is a no-problem:
myfunc :foobar :barbaz :arrayvalue1 value2 value3
after you type :foobar only three times, you'll acquire internal alarm
on constructs like
myfunc :foobar :bar10;
which are rather obfuscating already.
IMHO, mandatory whitespace between :bar and 10 here won't make anybody
sick.
I wonder how many people would like to write it
myfunc:foobar:bar10;
4) hash subscripting;
that's a real pain.
rather cute
$varkey1key2[3]key3
suddenly becomes an ugly monster:
$varkey1key2[3]key3
of course we could write:
$var{'key1'}{'key2'}[3]{'key3'}
and I would prefer this one to previous variant..
but it adds noise too. and it prevent us to logicaly recognize 'key1' and
'key2' not as strings but as something more like struct elements, like we
got used in perl5
When I look at this
$varkey1key2[3]key3
then I think that it's a *very* cute, nice, and clean syntax... I really
like it!
(and I would sacrifice something for that to happen, if I would be Larry
:) )
but there's a problem for people and parser too. is a comparison
*operator* and hash subscript is *operator* too, and there's no way to
distinguish them at all. Term rule won't help here.
+ and + for comparison is plain sickness, of course. But we have some
whitespace rules already. One of them is that subscripts shouldn't have
whitespace to the left of them. We could add one more - to always PUT
whitespace before comparison. so
$afoo.. is a start of subscript and
$a foo.. is always a comparison.
Personally I'm not lazy to put spaces because of my little Forth
experience.
but I don't want to be lynched by mad horde of programmers in white robes,
who will discover that
while $a$b {...}
for qwa b c {...}
and even
foo()bar()...
do something completelly wrong, and parser just unable to catch this..
(hm.. bad examples.. maybe it could be made able to?)
*sigh.. I'll write my own grammar:) I only afraid that it would take a
half of all my remaining lifetime (because of addiction)
But I'll return to topic.
I've seen proposal by Juerd, somewhere it this thread, to use `` for
autoquoting subscripting.
but proposed
%hash`foo`bar`$foo`0`$bar=0
not going to work
delimiters should have corresponding closing character, so it should be
something like
%hash`foo``bar`{$foo}[0]{$bar}=0
or it would be *much* worse for parser than .
actually, (countrary to [] and {} which could have arbitrary complex
nested expressions in it) autoquoting subscript shouldn't neccessarily
be a paired string. Any character could be used for it without any
ambiguity. Even perl4 style ' or even
Same with :pairs
%hashkeyanotherkey[1]=0
%hash'key''anotherkey'[1]=0
:keyvalue
:key'value'
ah, using here would cause difficulties to interpolation of hello,
$world
so what about ' or ` (or whatever you could imagine)?
P.S. I also considered shorcuts like
$varkey1key2key3[1] # but that not going to remove MUCH of
linenoise.
or
$var.key1key2[1].key3
Re: Angle quotes and pointy brackets
On Thu, 25 Nov 2004 13:45:51 -0800, Larry Wall [EMAIL PROTECTED] wrote:
...
Hmm, I would say that is short for qq//, not qq. Quote characters
lose their identity when used with generalized quotes. (I realize this
is not always true with Perl 5, but that can be construed as a mistake.)
So is not really short for qw unless you take the delimiters of the
latter construct as simple characters without any baggage, including
the need to have a workaround. So I'd rather say is short for
qw//.
...
ah, I forget, how could I do qx'echo $VAR' in Perl6? something like
qx:noparse 'echo $VAR' ?
(Note: I like thoose adverbs.. I could imagine that in Perl6 if you want
to have something done in some_other_way, you just should insert
:some_other_way adverb, and that is! perl will DWIM happily :)
...
This approach doesn't help the person who can't even *display* , but
that problem will be solved before the input problem is. For instance,
PerlMonks has no problem displaying , but I haven't a clue how to type
it into my browser yet.
...
I notice that in Perl6 thoose funny and could be much more common than
other paired brackets. And some people likes how they look, but nobody
likes fact that there's no (and won't!) be a consistent way to type them
in different applications, wether it's hard or easy.
But to swap with [] or {} could be real shock for major part of people..
We also have another ascii pair, and . maybe they could be better than
and ?:) i'm not that farseeing, but isn't problem of distinguishing
as a bracket and as an comparison operator no harder than distinguishing
as bracket and as part of heredoc?..
or maybe even we could see consistant to go after + + and alike, and
make old and written as + and + (and then lt and gt suddenly could
become ~ and ~ :)
But I certain, Larry already weighted exact that solution years ago..
P.S. If you have an urgent need to throw spoiled eggs at me, consider all
above as very late or very early fools day joke.. or you could try, but
i've never heard about ballistic transcontinental eggs.
$ @ and %
As far as I understood, arrays and hashes, and references them are much
more similar in Perl6 than it was in Perl5.
F.e. we have @a and $a = [EMAIL PROTECTED];
the same:
push @a,1,2,3 push $a, 1,2,3
$b = @a $b = $a
(?) say @a[] say $a[]
(?) myfunc( [EMAIL PROTECTED])myfunc ( *$a)
hm.. i'm not so competent to continue that list.. could anyone kind make a
comparison table?
in all other places where they work different, we could use @$a in place
of @a, right?
so I can consider @ as threat as container specificator, and nothing
more.. (in abstract, of course). And we just happen to have arrays with
specificator (@) and name without sigil (a), contrary to scalars which
always have to had $ in name ($a).
(
I must admit that I like to have three different namespaces for
arrays,hashes and scalars. In Perl5. the _only_ thing I miss is ability to
sub foo (@@) {
(\my @a, \my @b) = \(@_);
...
}
)
but perl6 has somewhat different data model. And we going to use
references much more often and easier than in perl5. And we going to have
much more different container types, not only arrays and hashes. Why to
threat two containers as first class citizens, and all other as mere
scalars with references to objects?
so, yeah, it's way too late to make significant changes, but could
somebody tell me what was wrong with the following models, apart that they
are different from perl5 (and could make it harder to write perl5 to perl6
translators)
I'm talking about unifying namespaces of arrays, hashes and scalars. I
could swear i've seen some RFC about it..
1. all variables are scalars, and as scalars they include $ in their name
2. if scalar $var contains reference to array or hash, we could threat it
as array or hash using @$var and %$var(or maybe just @var and %var, as
shorthands).
With all associated behavior, so @var = ... makes list context to right
side of assignment. We could think of it as of Array operator, or macro.
2. my @a is ... does right thing: it creates lexical $a, places reference
to anonimous array in it, and apply all the traits as current perl6 would
do (I'm not sure what differences of traits applying to container and
scalars, though). So my @a of .. is just a syntactic sugar to my $a is
Array of ...
3. subscripts are written as $var{} and $var[], as we have now and always
had before. still @var{...} could be easily recognized as slice.
as far as I can see, we have one thing to lose:
1) one namespace instead of three,
(my $x=$x[$i]; It's a Perl! (c))
and several good points:
1) simplicity.
2) eliminating of redundancy. We could write all the code involving named
arrays and hashes using _only_ named scalars with references to arrays and
hashes, so why to have both ways?.
3) no logical separation between CORE and extrnal data containers (yeah,
i know about tying, but why we have separate classes and tyers in perl5?
is there reason to have write that (tied $var)-method.. in my proposal it
would be matter of difference between $var.method and @var.method;
4) using references to containers isn't harder then using containers
theyself, because it's a same.
5) one namespace instead of three.
There's plenty of other classifications of variables which would want to
have separate nonclashing namespaces, (global/private, instance/class
etc.) but we for whateer reason stick with classifing thousands of
different container types as three major.
6) syntax would be much the same as what perl5 programmers used to see.
just try to look on your perl5 code in my way, and it would work! The only
thing that they should keep in mind is that $a and @a is the same..
ah, proposed model could prevent some minor optimizations.. but all thoose
optimizations are gone too if you going to use references to arrays
instead of arrays itself, aren't they? and if not, than there's no
trouble..
P.S Yeah, I see, it looks closer to Certain Other Languages. but why not
if it's simplier and maybe even better? and using @ and % as shorthand to
that clumsy and verbose to is Array or is Hash is cool, I think, and
it could be a distinctive feature, which could help us to withstand bitter
of being less distinctive.
P.P.S I had never feel enough inner strength in myself to be a
revolutioner. So I suppose I just don't see something important.. so bring
me to Right Way, please..
P.P.P.S. If answer on my why? would be just because! I would take it
silently.
P.P.P.P.S
open $file, filename;
print @file;
...
P.P.P.P.P.S. oooh.. sh$t! i forgot about @_ ! :) but maybe $_ is an Args
object? so $_[0] is here, scalar $_ is here for little unprototyped blocks
in map and others, and even $_{...} syntax for named args too, it's only
matter of viewpoint?..
P.P.P.P.P.P.S I'm going to write a grammar to write such a perl dialect
strikeif/strike when you'll decline my proposal.
Re: Return with no expression
On Fri, 20 Aug 2004 09:21:02 +0100, Matthew Walton [EMAIL PROTECTED] wrote: On 19 Aug 2004, at 18:04, Luke Palmer wrote: [...] my $num = $param == 0 ?? 0 : rand $param; my $num = $param == 0 ?? 0 :: rand $param; surely? a little off theme.. I wanna ask, could be there in perl6 any difficulties with recognizing C:: as part of C... ?? ... :: ... and C:: as module sigil? Does it involve some DWIM? Would we have mandatory space after C?? :: ? I didn't get perl6 syntax well yet, so if it's true, you can give better examples yourself..
Re: String interpolation
On Wed, 21 Jul 2004 10:21:58 -0700 (PDT), Austin Hastings
[EMAIL PROTECTED] wrote:
--- Larry Wall [EMAIL PROTECTED] wrote:
If {...} supplies list context by default, most
intepolations are either the same length or shorter:
$($foo) {$foo}
@(@foo) [EMAIL PROTECTED]
$(@foo) [EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Tres PHP, sir.
hm.. and what if all the program inside quotes?..
step by step,
I've just tested that in perl5, just to improve my built-in head perl5
parser:
my $d=a;
print [EMAIL PROTECTED] $d='b']}--$d--\n;
print $d\n
__END__
--a--b--a--
a
funny.
that means it's equivalent to:
my $d=a;
print -- . $d . -- . join( $, do { my $d='b' } ) . -- . $d . --;
...
with all the scoping behavior. hm, now it's slightly clearer to me.
I used $d='b' ,and not $d=b above, just because it should be $d=\b\
yes, I know, perl5 parser makes several passes on quotes, and when it sees
open quote, it finds closing quote first, then parses all inside.
AFAIK, perl6 will be one-passing (with backtracking), and with new rules
it should be much easier to make a parsing recursion.. do we need in
this \ ?. why not to parse strings as rules? so here's the
Question:
perl6, Larry's new syntax:
my $d=a;
print --$d--{my $d = b }--$d--\n;
^ ^
is it correct?
if answer is yes, I can imagine one of the (not the best) styles of
perl6 CGI programming:
#!/usr/bin/perl6
use All::You::Need;
print END
Content-type: text/html
!DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.0//EN
htmlhead title{...}{ #not decided yet
} /title
/head
body
{ my $res;
... #initialization
if $condition {
...;
$ret = qq{
psome html code here/p
oh my!... look here: {
{ my @res;
for CGI.param {
... # some sophisticated code
}
@res # of course we could (and should) use just
# Cmap or Cgrep here
}
don't you feel horror as me? it's a emhtml/em again!
}
}
else {
$ret = another piece of strangeness
}
$ret
}
html once again
/body
/html
END
__END__
looks somewhat similar to PHP.
is it readable?.. hm.. not less than {} inside rules, I think.. (I'm not
speaking about beauty now)
and if Cret for returning results from bare blocks (do, map, grep, and
such) would be in core, it could be even more (slightly) better.
IMHO, for user-level programmer, difference between {} and /{}/ isn't
very big. Yes, first is executed when it interpolated, second only
declares and executed only when called, but /.../ in void context is
called immediatelly.
( hm.. to push parallelism further, what about reference to interpolator..
hehe, think of lazy interpolation... *grin... nevermind..)
Oh my.. if my guessing about one-pass compilation of quoting constructs
was correct, does it mean that heredoc inside heredoc is possible?! :)
wow!. it's possible in perl5 too:
print FIRST;
1
2
@{[SECOND]}
3
4
SECOND
5
FIRST
__END__
1
2
3
4
5
Re: This week's summary
On Tue, 20 Jul 2004 19:15:49 +0200, Juerd [EMAIL PROTECTED] wrote:
The Perl 6 Summarizer skribis 2004-07-20 14:46 (+0100):
Another subthread discussed interpolation in strings. Larry'schanged
his mind so that $file.ext is now interpreted as
$object.method. You
need to do ${file}.ext or $( $file ).ext. Or maybe
$file.ext
by analogy with %foobar. James Mastros pointed out that . is
rather ambiguous in a literal string; sometimes a full stop is just
a
full stop.
My preference is $file\.ext. Clear, light and ascii.
Juerd
That's my preference too. But what if we have (perl5) ${n}th occurence ?
$n\th won't work because of \t special meaning...
I think, better if . would be interpreted as method call only after
\$ident, \@ident, \%ident or \ident, so
...leading dots?.. hm..
would not require \ before dots, but
text ~#~$obj.method.method2~#~ text
would be interpreted as it should.
I think, real period will be used more often than .topicsMethod
interpolating , and $(.topicsMethod) or $_.topicsMethod look nice
enough, so there's no need to add special behavior to . not preceded by
sigilled expression..
ah, one more problem. perl5-style ${var}.NotAMethod could save us in
some case, but what if you need to interpolate $var.method.NotAMethod ?
should it be ${var.method}.NotAMethod ?.. or
$($var.method).NotAMethod is only solution?
Re: String interpolation
On Tue, 20 Jul 2004 16:06:40 -0700, Larry Wall [EMAIL PROTECTED] wrote:
Actually, I've been rethinking this whole mess since last week, and
am seriously considering cranking up the Ruby-o-meter here just a tad.
At the moment I'm inclined to say that the *only* interpolators in
double quotes are:
\n, \t etc.
$foo
@foo[$i]
%foo{$k}
{EXPR}
where the last provides a list context to EXPR. So all of these
would require curlies:
{foo()}
[EMAIL PROTECTED]
{%foo}
{$foo.bar}
{Dog.wag}
{.count}
{~localtime}
[EMAIL PROTECTED]
[EMAIL PROTECTED] '.'}
{$x.as %10.5d}
Note that this not only fixes the Perl 6 % in sprintf issue, but
also the Perl 5 @ in email address issue. It also generalizes the
notion that curlies (almost) always indicate a closure everywhere.
On the other hand, it undoes my stated A12 policy that $x.foo can be
used anywhere $foo can. On the gripping hand, it enables {.foo}
where we would have had a lot of $_.foo, and I think that's an
improvement in readability, at least for people who believe in topics.
ah.. how poorly.. and how sufficient!.. But it's.. it's just not quite
like in perl5.. But I can adopt myself. :) I doubt about @arr disabling,
but {} interpolator is cool!
(hm.. looks like Perl6 will not require special HTML templating packages
in 90% cases.. qq[ tag attr={.property} ] would be enough for me almost
always)
some questions:
1) is @a[1][2]{'a'}b interpolateable? and what about @a[1]('arg')[3]?
2) what's the default separator for list interpolation?
{1,2,3} eq 123 or
{1,2,3} eq 1 2 3 ?
and is there any way to redefine it, as assigment to perl5 @ does? I
can't figure to which object or class that property could belong, so maybe
there should be just lexically scoped pragma...
Re: if not C, then what?
On Fri, 9 Jul 2004 20:14:32 -0400, Joe Gottman [EMAIL PROTECTED]
wrote:
-Original Message-
From: Larry Wall [mailto:[EMAIL PROTECTED]
Sent: Friday, July 09, 2004 2:33 PM
To: [EMAIL PROTECTED]
Subject: Re: if not C, then what?
On Fri, Jul 09, 2004 at 11:23:09AM -0700, Austin Hastings wrote:
: Will there be a statement modifier version of Cwhen?
:
: print, next when /stgh/;
Yes, though in this case it's indistinguishable from Cif, since //
defaults to $_ anyway. However, these are different:
print, next when 3;
print, next if 3;
Will given be a statement modifier also? This would be useful for
quick
topicalization:
say $_ = %hash{$_} given get_random_key();
Joe Gottman
hm...
does perl5ish
say $_ = %hash{$_} for get_random_key();
become unusable suddenly?
Re: if not C, then what?
On Fri, 9 Jul 2004 13:19:46 -0700 (PDT), Austin Hastings
[EMAIL PROTECTED] wrote:
--- Larry Wall [EMAIL PROTECTED] wrote:
If there reasonably can be block modifiers, I will unreasonably
declare that there can't be. You can always say:
do { print; next; } if|when /stgh/;
(It's still the case that do-while is specifically disallowed, however.)
But I also want do/while to work, solely because repeat/until sucks.
What's the big deal there?
hm..
do {...} while ...
sucks much more:) just because it used as loop, but it isn't really a
loop, so you cannot use Cnext or Credo.. but IMNSHO to specifically
disallow it is somewhat unnatural, even if it could save from mistakes
many of us, who will think it works perl5ish way... maybe it just should
be written with BIG letters in perl6syn:
W A R N I N G ! ! !
do {...} while ...
DOES CHECK CONDITION (look here) __**BEFORE**__ (look here) TRYING
TO EXECUTE CDO BLOCK. (look here ^^^)
because Cdo isn't something special anymore. So just use repeat/until
(or something)
(I correctly guessed true reasons for that, did I? :)
--
plz, ekskuze ma french.
Alexey
Re: if not C, then what?
On Fri, 9 Jul 2004 11:13:29 -0700, Larry Wall [EMAIL PROTECTED] wrote:
On Fri, Jul 09, 2004 at 10:39:56AM +0200, Michele Dondi wrote:
: On Thu, 1 Jul 2004, Alexey Trofimenko wrote:
:
: if we really about to lose C-style comma, would we have something new
: instead?
:
: A late thought, but since I am one of thow whose' keen on the
:
: print,next if /stgh/;
:
: kinda syntax too, and I, for one, will regret not having it anymore, I
: wonder wether something vaguely like the following example could (be
made
: to) work:
:
: print.then{next} if /stgh/;
That's unnecessary--the comma still works perfectly fine for this,
since comma still evaluates its arguments left-to-right. The *only*
difference about comma is what it returns in scalar context. Most uses
of the so-called C-style comma (including this one) are actually in
void context, and in that case whether the return value is a list or
the final value Doesn't Really Matter.
Larry
perl is filled with functions which do different things in different
contexts. It seems that in perl6 with plenty of new contexts, it will
be even more stimuls for that habit. So real question is:
in expression C a(),b(),c() , used in void context, what context is
given to a() and b()? is there any issues which do not allow us to imply
void context instead of list context here?
Re: if not C, then what?
On Fri, 9 Jul 2004 18:25:40 -0700, Larry Wall [EMAIL PROTECTED] wrote: On Sat, Jul 10, 2004 at 05:12:54AM +0400, Alexey Trofimenko wrote: : perl is filled with functions which do different things in different : contexts. It seems that in perl6 with plenty of new contexts, it will : be even more stimuls for that habit. So real question is: : in expression C a(),b(),c() , used in void context, what context is : given to a() and b()? is there any issues which do not allow us to imply : void context instead of list context here? Not that I'm aware of, unless the actual creation of the list in list context has some side effects that wouldn't happen in void context. But maybe functions will be written to treat void context as a funny form of list context, and do the side effects without generating the list. And in a sense, since a list context wants 0 arguments or more, and we'll probably support list contexts that want a specific number of arguments max, void context is just a list context with a max of 0 values wanted. But then maybe it wouldn't be expected to generate all the side effects for the whole list... I'm thinking about cases when generating list is expensive, and function is smart enough to do not bother itself for such an overhead when it not asked to. And also about /.../ which does something totally different when it called in void context. If primary purpose for C, in void context is using in statements with modifiers, then it's just a funny C; with just a little higher precedence, and any programmer would be expecting the same behavior - void context for all operands.. In any event, I'd say that if we're gonna call a() and b() in void context, we should probably also call c() in void context too, since we're breaking the basic asymmetry of C's comma operator. that was assumed:)
Re: = brother
On Fri, 9 Jul 2004 18:00:44 -0700, Larry Wall [EMAIL PROTECTED] wrote:
On Sun, Jun 20, 2004 at 03:41:41AM +0400, Alexey Trofimenko wrote:
: There was some talks about hash keys autoquoting and barewords.. later
are
: gone and former is disambigued by forcing to write %hash{'key'} or
: %hashkey ( as opposite to %hash{key} which is now %hash{key()} )..
: right?..
: that's almost ok to me, if there's any hope that will have a
_standard_
: way to type accross all the editors:) (btw, I also hope I would never
: happen to mantain a perl6 program written by Chineese programmer, who
: thinks that chineese identifiers are cool)..
:
: but now I'm curious what you gonna do with = autoquoting behavior:
:
: shift = 'value' is the same as
: shift() = 'value'or
: 'shift' = 'value'in perl6?
:
: or in this particular case consistancy doesn't matter? ,)
Well, consistency with *what* is the question. The default Perl 6
design rule is that, unless we've said otherwise, Perl 6 is consistent
with Perl 5. So for the moment, = still autoquotes its left side.
only if it does look like an outlawed bareword?.. ah.. 100% perl5 syntax.
I like that:)
Arguably, the :shiftvalue syntax makes it easier to quote both
sides of a pair, so perhaps there's a little less need for an
autoquoting =. But I think that generating non-quoted keys for
subscripting happens a lot more often than non-quoted keys for pairs,
so I'm inclined to leave the autoquoting of = in for now.
Larry
strange, but :shiftvalue looks a little more noisy to me than shift =
'value',
oh.. I have a question.
in
%hash := { :keyvalue :key2value :key3}
there's no need to put comma between, right?
I wonder about mixed synax:
%hash = ( :keyvalue
:key2value
:key3
key4 = 'value',
'key5','value',
key6 value key7 value )
Did I make mistakes here?
if all was right, than I can figure that :key value (with whitespace
between) is outlawed..
Bad Thing for people who like to write pairs in columns.
ah.. sorry about messing up all question in one post, but I have one more:)
if key could be of any type, not only strings, than what will be with
numeric keys? would they be converted to strings automatically?
Re: if not C, then what?
On Thu, 1 Jul 2004 16:14:37 -0700 (PDT), Jonathan Lang
[EMAIL PROTECTED] wrote:
Actually, the whole purpose of the C-style comma is to allow you to place
multiple expressions in a place that's only designed to take one, such as
the various divisions within a loop control set (loop ($i = 0, $j = 1;
$i
10; $i++, $j*=2) {...}). For something like this, you might be better
off doing something like
last($a, $b, $c)
instead of
$a then $b then $c
(where last is a sub that takes a list of arguments, evaluates them one
at
a time, and returns the value of the last one).
I remember perl5 scalar:
scalar($a, $b, $c)
f.e.:
sub test {print wantarray ? list\n
: defined wantarray ? scalar\n : void\n}
scalar (test,test,test)
prints
void
void
scalar
...
hm.. sorry, scalar() isn't needed at all:)
2+(test,test,test)
gives the same.. it's a perl5 comma's behavior, not perl5 scalar()
...
ok, all I want is an ability to write operator which wouldn't try to
create lists or store result of first operand and will call it in _void_
context, so I could easily write short postfix loops and conditionals when
I want to.
Cmap Cgrep and lazyness
consider this:
say for map {...} grep {...} map {...} 1..1_000_000
as far as I can imagine, in perl5 it does:
1)flatten 1..1_000_000 into anonimous array; (maybe in this particular
case it is optimized in perl5, like it done in Cforeach.. I don't know.)
2)map trough it elements and store results in another anonimous array of
one million elements;
3)then GC probably frees memory of 1..1_000_000
...etc. Please, correct me if I'm wrong.
that's probably fast but not memory efficient. what if after grep we'll
have only 1000 elements, but to compute them we used at least 2_000_000
scalar cells.
apply to it perl6 GC, which wouldn't always free memory immediately, so
it could eat 3_000_000 or more.
ok, I know, that 1..n will return an iterator in perl6, which is called
only when new item needed. great.
what I want to ask - would map and grep return an iterators too?.. if
it's true, then previous construct becames very memory efficient, like if
I write
loop ( ... ; ... ; ... ) {...; next if ...; ...; say}
but probably even faster (of course if iterator call wouldn't involve too
much overhead). Only one drawback is that now map and grep are forbidden
to have side effects which is probably a Good Thing.. no one knows when
iterators will be called later and in which order.
hm.. It could be a little too functional, though, for perl, which is
filled up by side effects. for example, $filehandle is iterator too, but
it has side effect of changin' position in file. now
sub process (@a is Lazy) { map {...} @a }
becomes somewhat dangerous if called as
@b = process $file
(assuming we have lazy arrays too. maybe it should be := insted of = ?)
..because it can mess up all successive operations with $file.. (hm.. it
will read it all to the eof anyway,so there's little chance that there
would be any successive operations.. but what if next line is close
$file? I hope you understand what I tried to illustrate. I have no
functional programming experience, and I don't know how languages with
lazy evaluation avoids problems with files. Maybe it's easy.(?))
ok.. I'm sure it was discussed before, so what you decided?
Re: if not C, then what?
On Wed, 30 Jun 2004 19:41:24 -0600, Luke Palmer [EMAIL PROTECTED] wrote:
Alexey Trofimenko writes:
if we really about to lose C-style comma, would we have something new
instead?
new C,,( as I've been told here by wise ones), doesn't guarantee order
in which its operands will be evaluated, and even doesn't guarantee that
they won't be optimised away before evaluating, if all expression is in
void
context.. right?
Nope, that was just silliness. Although the scalar comma is going away
in favor of a list constructor, I presume that there will be no
opimizing away of elements, and that they will probably still be
evaluated left to right. Optimizations that you get from changing the
evaluation order aren't big enough to warrant such a strange semantic
effect.
BUT: the subexpressions will be evaluated in list context.
I'm thinking about Cthen, analogious to old C, (maybe with lower
precedence than Cand and Cor have?)
pray_to $_ then sacrifice $virgin for @evil_gods
hm.. maybe Cthen should make first action in void context (I hate
noise
when doing business)
That's interesting. I brought up the same thing and proposed the same
solution just a few months ago. Same keyword and everything :-)
hm:) I'm sorry for idea stealing. I'm here only month.. Maybe it means
this is natural solution for many people's way of thoughts?..)
Larry didn't go for it. Note, we already have an operator that puts its
left side in void context and evaluates it before its right one: we call
it C;.
Larry didn't go.. ok, that is it! I Want To Write My Own Grammar(TM) :)
Just because that construct would be more useful for me than many we
already have in the core. Now I'm interesting, would it be difficult. That
is - would it be difficult to write operator, which evaluates it's left
operand in void context, and do not tries to store results or to create
lists or all the unneded activity wich C, will do.. (I suspicious to
macroses - they could have their major caveat, we just not find it yet..)
BTW is C; an operator really? :) if it is, then it has lower precedence
than statement modifers, and that means that they are really operators
too, which leads us to thinking about several modifiers possibility
(again!).. but Larry didn't go for it, I know :)
@
do { pray_to $_; sacrifice $virgin } for @evil_gods;
Luke
note about Cdo - I think ret() mentioned in one of Apocalypses should be
in core.. just because it's sometimes too difficult (i'm lazy) to place
return value at the end of complicated Cdo, Cmap, Cgrep etc blocks.
If I use curlies, I place a whole program in it:)
and, again about C,
what about C,, ? what it would do? in perl5 this has no effect, but what
about perl6? (something tells me that it would be compile time error
probably.)
maybe (1,,2) could be the same as (1,undef,2)? but someone immediately
will write subroutine callable as
mysub 1,2,3,,,4
perl gives a lot of freedom, and I like that.. but do we allow such
silliness? :)
(P.S. my lazyness murmurs to me that ,, would be niccce.. oh my.. no-o!)
if not C, then what?
if we really about to lose C-style comma, would we have something new
instead?
new C,,( as I've been told here by wise ones), doesn't guarantee order
in which its operands will be evaluated, and even doesn't guarantee that
they won't be optimised away before evaluating, if all expression is in
void
context.. right?
so it will be erroneous to write:
pray_to $_, sacrifice $virgin for @evil_gods
because it could be executed as:
sacrifice $virgin, pray_to $_ for @evil_gods
that is against rites;
or even optimized away as:
sacrifice $virgin for @evil_gods
which is a senseless loss of costly and rare resources.
And I can't just write
pray_to $_ and sacrifice $virgin for @evil_gods
because prayer result is almost always undefined, ..but who knows?
I'm thinking about Cthen, analogious to old C, (maybe with lower
precedence than Cand and Cor have?)
pray_to $_ then sacrifice $virgin for @evil_gods
hm.. maybe Cthen should make first action in void context (I hate noise
when doing business)
P.S. of course, I can just use
for @evil_gods { ... }
but I thought there's more than one way to sacrifice It... I'm just afraid
of Repetitive Injure..
BTW, slight improvisations don't not harm in such things...
P.P.S. do we have a way to imply void context on function inside
expression, something like Cscalar, C+, C~, C? do?
--
$_ = join q--, map++$_=splitq qq, q
xitrswzmnsgdqwakzbjwodqkwoqhdrswx xor y yayys x y yxy y x print
Re: if, loop, and lexical scope
On Tue, 29 Jun 2004 10:52:31 -0400, Jonadab The Unsightly One [EMAIL PROTECTED] wrote: People who think in terms of statements often get mixed up when they put complex expressions in void context, expecting them to be treated as statements. print(2+3)*7; is another example. Perl doesn't have statements in the same sense that Pascal does. It has expressions. hm.. still it have modifers like postfix Cfor, Cwhile, Cif etc., which are statement ones, not expression.. hm.. just consider all the mess(and fun!) if all the control structures and modfiers would become ordinary expressions.. but it's a perl, not lisp or haskel or whatever..
Re: user-defined operators?
On Thu, 24 Jun 2004 10:55:26 -0700, Larry Wall [EMAIL PROTECTED] wrote:
Well, any operator or function that knows how to call a closure can
function as a short-circuit operator. The built-in short-circuit
operators are a bit special insofar as they're a kind of macro that
treats the right side as an implicit closure without you having to
put braces around it. No reason in principle you couldn't write your
own infix macro to do the same thing.
if I got it right, you mean that in perl6 it would be correct (perl5
syntax):
$a and my $b=1;
is the same as
$a and do {my $b=1}
or, more correct:
$a and sub {my $b=1}-()
in perl5 it isn't the same. What about lexical scoping? or implicit
closure shouldn't be taken literally?
if, loop, and lexical scope
AFAIR, I've seen in some Apocalypse that lexical scope boundaries will be
the same as boundaries of block, in which lexical variable was defined.
so, my question is, what the scope of variables, defined in Cif and
Cloop conditions?
in perl5:
my $a=first\n;
if (my $a=second\n) {print $a}
print $a;
prints
second
first
if I got it right, in perl6 same program will print
second
second
or will emit warning about redeclaring variable in the same scope..
sad. In Cif case it isn't so significant, but what about Cloop?
cite from Apocalypse4:
...
The continue block changes its name to NEXT and moves inside the block it
modifies, to work like POST blocks. Among other things, this allows NEXT
blocks to refer to lexical variables declared within the loop, provided
the
NEXT block is place after them. The generalized loop:
loop (EXPR1; EXPR2; EXPR3) { ... }
can now be defined as equivalent to:
EXPR1;
while EXPR2 {
NEXT { EXPR3 }
...
}
...
so,
loop (my $i=1;$i10;$i++) { ... }
will declare $i for the rest of the block, in which loop is placed, won't
it?
I feel that I will write things like:
{loop (my $i=1;$i10;$i++) {
...
}}
But I really hope that I missed something important, stating that theese
curlies are not necessary.
Re: unicodian monospace fonts for windows(?)
On Sun, 20 Jun 2004 18:37:03 -0700 (PDT), Goplat [EMAIL PROTECTED]
wrote:
--- Alexey Trofimenko [EMAIL PROTECTED] wrote:
oh my.. it seems to me, that Perl6 starts new age of ASCII-graphics.
(not
ASCII, really.. maybe Uni-graphics?)..
but now i have this issue: I'm coding on Windows, there's already two
unicode compliant monospace fonts: Lucida Console and Courier New. And
I
do not like both of them, (f.e. in Courier { and ( looks almost the
same, and lucida has too crude letters). Until now I used to use
Fixedsys
(which can display, but not , for example)
So I have a question - does anyone know the place where I can get free
monospace unicode font for windows, good for programming? or maybe
there's
good fonts for *nixes, which could be converted?
There's Fixedsys Excelsior, you can get it at http://www.fixedsys.org/.
It
has 2 bugs but you can fix them in a hex editor. First, it has the wrong
PANOSE proportion type so it's not recognized as monospaced, to fix that
change byte 19B from 04 to 09. Second, the underline is outside of the
character cell, to fix that change byte 5BFC9 from 56 to F6, and 5BFCB
from
82 to 0A.
wow.. unicodian fixedsys. thanks!.. btw, it has rather ugly cyrillics,
with glyphes, not fitting in bounding boxes.. can you tell me, which tool
did you use to make changes you told me before? Maybe i can fix it slightly
= brother
There was some talks about hash keys autoquoting and barewords.. later are
gone and former is disambigued by forcing to write %hash{'key'} or
%hashkey ( as opposite to %hash{key} which is now %hash{key()} )..
right?..
that's almost ok to me, if there's any hope that will have a _standard_
way to type accross all the editors:) (btw, I also hope I would never
happen to mantain a perl6 program written by Chineese programmer, who
thinks that chineese identifiers are cool)..
but now I'm curious what you gonna do with = autoquoting behavior:
shift = 'value' is the same as
shift() = 'value'or
'shift' = 'value'in perl6?
or in this particular case consistancy doesn't matter? ,)
div operator
what do you think about adding Cdiv operator, akin %, to perl6 core? I mean, as$a % $b really does int($a) % int($b) and returns modulous, so $a div $b really does int( int($a) / int($b) ) and returns integer division. but with native integers, declared as such, and with constants it should be optimized and done really fast yes, I realize that it wouldn't speed Perl up much, but I like idea that such a simple operation can be done using one simple machine instruction. And I use such a function often, but I hate that it uses floats internally. maybe there should be another name (possible name clashing with perl6-CGI.pm analogue ;) ) or even unicode version.
unicodian monospace fonts for windows(?)
oh my.. it seems to me, that Perl6 starts new age of ASCII-graphics. (not
ASCII, really.. maybe Uni-graphics?)..
but now i have this issue: I'm coding on Windows, there's already two
unicode compliant monospace fonts: Lucida Console and Courier New. And I
do not like both of them, (f.e. in Courier { and ( looks almost the
same, and lucida has too crude letters). Until now I used to use Fixedsys
(which can display, but not , for example)
So I have a question - does anyone know the place where I can get free
monospace unicode font for windows, good for programming? or maybe there's
good fonts for *nixes, which could be converted?
Re: unicodian monospace fonts for windows(?)
On Sun, 20 Jun 2004 15:06:33 +0400, Andrew Shitov [EMAIL PROTECTED] wrote: AT oh my.. it seems to me, that Perl6 starts new age of ASCII-graphics. (not AT ASCII, really.. maybe Uni-graphics?).. I hardly think Perl 6 should avoid any characters other than ASCII. For example we have at least three Russian encodings and it is acceptable only because we have no choice: we face the fact that we have lots of encodings. As long as Perl 6 is still in the phase of development, it is possible to buid the language that use PLAIN characters. -- Andrew, [EMAIL PROTECTED] unicode is only way to get rid of the mess with multiple encodings - you'll have the same program on windows or linux, and do not worry about which encoding should be used for string constants in code - KOI8-R or CP1251 or even (is it used?) ISO-I-forget-the-number, just because your code will be in machine independent UTF-8, and output will be done through system dependent io-layer. That's ok and fine.. but I must agree, that using fancy characters for identifiers and operators really can make problems for people. Not all people uses vim, you know, not all (very good and handy if not to use Unicode) editors allow to enter such characters.. and there's psychological reasons too - how to read such a program? :) @a @b array a ..er..broken bar array b.. ok, 'twas a joke.. but this looks obfuscating.. if someone writes a module using hiragana, and I want to read the sources to understand how it works, I'll meet a problem, because I'm doubt if I can distinguish one letter from another.. I have good audio memory, but bad video memory :) so, unicode is good, but I think that this should be explicitly said, that modules for public using should avoid using unicode operators and subs name as much as possible. It's against internationality of programmers community. I'll want to understand what programs do, and want to edit them too, if need arise. -- Excuse my French.. Alexey Trofimenko
Re: div operator
On Sun, 20 Jun 2004 15:57:48 +0100, Jonathan Worthington [EMAIL PROTECTED] wrote: Alexey Trofimenko [EMAIL PROTECTED] wrote: what do you think about adding Cdiv operator, akin %, to perl6 core? I mean, as$a % $b really does int($a) % int($b) and returns modulous, so $a div $b really does int( int($a) / int($b) ) and returns integer division. but with native integers, declared as such, and with constants it should be optimized and done really fast yes, I realize that it wouldn't speed Perl up much, but I like idea that such a simple operation can be done using one simple machine instruction. And I use such a function often, but I hate that it uses floats internally. I'd imagine that if you declare a variable as an int, the compiler would be able to generate optimal code for the % operator anyway, so you'd get the speed you wanted. Jonathan of course! but what I'm talking about is integer / , (not %, which we have already). I talked about division, which takes integer args and return _integer_ result. Sometimes you need exactly this, and Perl would never guess it, even if both args of / are integer, but what if we're expect fraction results? So now perl always calcs float division.. One example - $t = time - $when_it_happen; $sec=$t%60; $t=int($t/60); $min=$t%60; $t=int($t/60); $hours=$t%24; $t=int($t/24); $days=$t; return time_elapsed($days,$hours,$min,$sec)
