Re: Embedded comments: two proposed solutions to the comment-whole-lines problem
On Tue, Aug 11, 2009 at 8:59 AM, Jon Lang wrote:
> Ben Morrow wrote:
> > However, I would much rather see a general syntax like
> >
> >(# ... )
> >{# ... }
> >[# ... ]
> >
>
a preceding ':' (colon) makes it *notionally*
a null-label-block-comment-construct.
>
> > with no whitespace allowed between the opening bracket and the #: this
> > doesn't seem to conflict with anything. Allowing <# ... > in rules would
> > also be nice.
>
> That's rather elegant. It's no longer than the current embedded
> comment syntax, and avoids the start-of-line issue. The only
> complication arises when you prepend the brackets with a quote or
> pseudo-quote character:
>
> say q(# is this a string or a comment?); # DWIM -> string.
>
> --
> Jonathan "Dataweaver" Lang
>
Re: Embedded comments: two proposed solutions to the comment-whole-lines problem
On Mon, Aug 10, 2009 at 10:31 AM, Carl Mäsak wrote:
> In my post "Three things in Perl 6 that aren't so great" [0], I
> outline three things about Perl 6 that bug me at present. Commenter
> daxim made what seems to me a sensible proposal [1] for solving the
> third problem, "Comments in the beginning of lines":
>
> daxim (]):
> ] Let single # be used for commenting out, no matter what follows.
> ] Let ## (perhaps also ### and so on) switch on the special behaviour
> ] of brackets etc.
>
While I like the idea, ## occurs frequently in much existing code,
a more selective pattern would help.
like "#{" and "#}"
- explicit, DWIM block constructs
or qr/^\s*\#{3,}:[\[\{\(\<]/etc ..
- multiple-sharps makes the comment-block more visible
- any block-punctuation works (why limit it?)
This would clash far less with existing code,
and thus be usable there incrementally.
And this makes it a more portable, POD++ ish feature.
is perl5 -Dmad output used in perl 6 ??
perl5 has a facility to dump the optree in XML, which is currently not regression tested. Ive submitted a test-file which tests the XML output against a few golden-samples, but its been ignored/overlooked. So let me ask: is MAD XML output used in any way currently (or in future) ? is there a DTD or SCHEMA to validate with ? can anyone suggest a short list of (non-)? validating XML parsers that, if found on a box, could be used to test that the MAD output is well formed xml, legal - conforming to the DTD. Im on linux, so I'll probably use xmllint, what about windoze ?
qq:i
since the qq:X family has recently come up, Id like to suggest another.
qq:i {} is just like qq{} except that when it interpolates variables,
those which are undefined are preserved literally.
its purpose would be to support the construction of strings for
subsequent eval'g, particularly where you have one or more variables
to interpolate, so you cant just use q{}, but you also have lots of
other vars that yould prefer not to backwhack.
its like closures on my vars, only differnt.
for $memberfn (qw( foo bar belch )) {
# forgive errant? p5 syntax - I dont do this often
*{__PACKAGE__}::${memberfn} = eval sub qq:i {
my $self = shift; # $self is
undef when interpolated, so preserved
$self->{member}{$memberfn} = 1; # $self preserved, $memberfn
interpolated
... # presumably something useful (but not in this example)
}
or die "badness happend";
}
Or maybe this is all superseded by p6 features, Im just cant keep up.
(as you can tell from the p5 code)
Theres also some room for unholiness tho;
my @args = @{$template{args}};
my $body = $template{body};
eval sub qq:i{
my ($self, @args) = @_;
$body;
}
Re: Why do users need FileHandles?
Luke Palmer wrote: It's likely that CPAN will have a Bundle::EYEWTIBWATA. [1] [1] Everything You Ever Wanted To Install But Were Afraid To Ask EYEWTIBWATL eye-witty-bwattle .. But Were Always Too Lazy
Re: Arrays: is computed
[EMAIL PROTECTED] wrote: Shouldn't access to 'is computed' arrays be read-only? If you want to be able to consume the elements by shifting, you can always create a tied object that kees a cursor and a reference to the underlying array and gives you that access (and it could die for splicing, etc.)... Regards, -- Gregor ICBW - but didnt 'is computed' evolve from 'is default' ? if so, then read-only is not appropriate, insofar as the default value was only there to save space until the element at a given index was assigned to..
~> and <~ become |> and <| (was L2R/R2L syntax )
Damian Conway wrote:
Can I suggest that an alternative solution might be the following:
So an L2R array-processing chain is:
@out = @a ~> grep {...} ~> map {...} ~> sort;
There might also be a be special rule that, if the RHS is
a variable, the LHS is simply assigned to it. Allowing:
@a ~> grep {...} ~> map {...} ~> sort ~> @a;
Further suppose that <~ takes its right argument, and binds
it in the indirect object slot of the left argument, which
argument it then calls. So an R2L array-processing chain is:
@out = sort <~ map {...} <~ grep {...} <~ @a;
Or, under a special rule for variables on the LHS:
@out <~ sort <~ map {...} <~ grep {...} <~ @a;
That way, everything is still a method call, the ultra-low precedence of
<~ and ~> eliminate the need for parens, and (best of all) the
expressions
actually *look* like processing sequences.
Damian
my knee-jerk reaction,
|> is evocative of pipelines in bash, etc...
<| is somewhat less evocative, but related to <(cat *) as a
sub-process (in csh ??)
yours feels slightly less noisy, but also less familiar/mnemonic.
related-constants namespace
ive oft wondered how a constant/parameter namespace could be designed to: - lighten Exporter symbol export in perl 5 - expose (for example) POSIX constants in only the contexts where theyre meaningful within a POSIX call - ex various c-open flags (im too lazy to cite any currently) ie disambiguate with tighter context (so that full::names arent needed (ie in argument to POSIX::open or whatever) - unify perl 5 -> 6 (clarify path between) related : (tho I cant synthesize a decent explanation) the recent p5p machinations in the :via namespace File::Spec (iirc) or ancestors, and its parameter functions - forgive any misattribution lazy evaluation of %Config ? Can topicalizers help to provide a semantic context in argument-lists ? can this help ascertain the 'constness' of a function so that export, run costs are minimized. sorry, since this is a kinda punt on my own investigations.
eval {} or carp "blah: $@"
with p5, Ive often written
eval {} or carp "$@ blah";
it seems to work, and it reads nicer (to my eye) than
eval {}; if ($@) {}
but I surmise that it works cuz the return-value from the block is non-zero,
for successful eval, and 0 or undef when block dies, not cuz of magical
treatment of $@.
I gather that ';' is unneeded in p6, and given that $! is the
'exception'al topicalizer,
is this construct no longer reliant on the last value in the eval block ?
put another way, does the 'topicalizer' reflect the exit condition of
the closure ?
Re: Loop controls
Damian Conway wrote:
>Luke Palmer wrote:
>
>>Ooh! Why don't we have a dont command! With several variants:
>>dont FILE
>>dont BLOCK
>>
>>dont { print "Boo" }
>>
>>Would print:
>>
>>
>
>You really *should* be more careful what you wish for Luke.
>The following was just uploaded to the CPAN...
>
>Damian
>
>
>-cut--cut--cut--cut--cut--cut-
>
>NAME
>Acme::Don't - The opposite of `do'
>
>VERSION
>This document describes version 1.00 of Acme::Don't, released May 1,
>2002.
>
>SYNOPSIS
>use Acme::Don't;
>
>don't { print "This won't be printed\n" };# NO-OP
>
>DESCRIPTION
>The Acme::Don't module provides a `don't' command, which is the opposite
>of Perl's built-in `do'.
>
>
>AUTHOR
>Damian Conway ([EMAIL PROTECTED])
>
>BLAME
>Luke Palmer really should be *far* more careful what he idly wishes for.
>
>BUGS
>Unlikely, since it doesn't actually do anything. However, bug reports
>and other feedback are most welcome.
>
>
feature request :
Acme::Dont::Obstruct
We need a dont that will prevent *bad things*, to wit:
dont ( 'let MS get away with it');
dont ( 'rape the planet');
dont ( 'sack ANWAR');
dont ( 'accept Bushs Energy Plan');
dont ('pass CBTBPTA*%#$');
in this light, your *impressive* module has the shortcoming that it cant
stop stuff when its not used.
Ex: W was able to hold secret energy meetings with the oil industry, w/o
the participation of *any*
environmental groups. Shades of Hillarys health plan that was
pilloried. Wheres the uproar now ?
Now the real trick will be getting this module to insert itself into
code w/o explicit 'use'
stuff it into universal ??
can you make a module that can do that ? huh ? huh ?
Re: Loop controls
Dan Sugalski wrote: > At 1:07 PM -0400 4/30/02, Miko O'Sullivan wrote: > >> > Damian, now having terrible visions of someone suggesting >> C ;-) >> >> Then may I also give you nightmares on: elsdo, elsdont, elsgrep, >> elstry ... > > > Has anyone brought up elselse or unlessunless yet? > and since this line of conjecture keeps going, andif orif orelse
Re: Loop controls
so, assuming we have;
print 'you gave me: @wordlist = ';# single quote - no interpolation
for @words -> $it {
print;
FIRST { print '(' }# provisionally
NEXT { print ',' }
LAST {print ');' }
}
# and maybe
else {
print "();\n";
}
this yields:
you gave me: @wordlist = ();
or if (@wordlist) {
# (damn - i want to say orif ;-)
you gave me: @wordlist = (alpha,beta,gamma,);
whereas
print 'you gave me: @wordlist = (', join(',', @words), ")\n";
doesnt include the last comma.
if I remember the thread (now deleted, so cant be accurate)
the last comma would be in there, unlike if it were in a join.
cuz NEXT is a block terminator, not a block-inbetweener
this is vaguely unfortunate, as its not so simple to write
loops to generate SQL ( which isnt as friendly wrt to extra commas as
perl is )
separately ( to re-iterate earlier good thoughts ):
loop {} else {}
would be more visually distinct (easier to read) as
loop {} otherwize {}
esp when loop block is bigger than a screenful, new keyword keeps us
from looking for the if,
and it fits better with natural language (or at least dictionary language )
where the connotation is a final alternative to lots of choices.
http://webster.com/cgi-bin/dictionary?va=otherwise
Main Entry: *^1 oth·er·wise*
Pronunciation: -"wIz
Function: /pronoun/
Etymology: Middle English, from Old English (/on/) /Othre wIsan / in
another manner
Date: before 12th century
*:* something or anything else *:* something to the contrary
vs
Main Entry: *^1 if*
Pronunciation: 'if, &f
Function: /conjunction/
Etymology: Middle English, from Old English /gif; /akin to Old High
German /ibu /if
Date: before 12th century
*1 a* *:* in the event that *b* *:* allowing that * c* *:* on the
assumption that *d* *:* on condition that
*2* *: WHETHER
*
*3* -- used as a function word to introduce an exclamation expressing a
wish
*4* *:* even though
- *if anything* *:* on the contrary even *:* perhaps even
look ma, no typing..
Re: rethinking printf
Rich Morin wrote:
> At 11:24 PM -0500 3/6/02, Uri Guttman wrote:
>
>> qn would be just like qq but not allow any
>> direct hash interpolations (%foo or %foo{bar}). you can always get those
>> with $() if needed. this solves the common case with a minimal of noise
>> and the uncommon case has a simple out of using $(). no need for wacko
>> ways to put in \n. it is double quotish in all ways but one and mainly
>> to be used for printf format strings.
>
>
> I also like this because it allows a typical format string to be
> converted
> merely by adding a two-character prefix:
>
> printf("The value is %7.2f\n", $foo);
> ---
> printf(qn"The value is %7.2f\n", $foo);
>
> -r
if qf() is defensible, it should pass some generality tests;
1. make it 'replace' printf
print qf'%s %d', $somestring, $someint;
2. make it 'replace' sprintf.
$res = qf('%s %d %d', $somestr, $anint)
3. detect the silent error above - insufficient args.
this quote-like operator is now a list-op, and a smart one.
4. make it know whether %s means hash interpolation or printf-format-spec
a. ive seen perl5 warn about escaping @ when printing undefined / undeclared
@array (cant seem to replicate now :-/ )
b. the universe of printf format specs is pretty small, it really only
interferes
with (the expansion of: @{[ each %s ]} ) a few single letter hashes %s,
%d, etc..
c. item b implies a run-time check to see that no %s, %d, are hidden by
a format-spec
interpretation, but that is excessive; a comment in `perldoc -f printf`
would address
that rather fully.
