Allison Randal <[EMAIL PROTECTED]> writes:
> Miko O'Sullivan wrote:
>>
>> Therefore, I propose that members of the language list provide summaries
>> of the discussions in the group. Each summary describes a proposed idea
>> feature of the language, then summarizes the list's feelings on the ide
> print "---" # must read the next line to
> # figure out if new line is statement terminator or not
>if $condition";
Yes, let's expand that example, and assume the "semicolons optional
where obvious" proposal.
sub foo
{
print "abcde"
if $condition
{
print "fghij"
}
}
>> I don't mean to be abrupt here, especially seeing as how this list has
>> been so patient with some of my ideas but... PLEASE NO. The rules you
>> suggest for keeping track of when a semicolon is required sound more
>> confusing than the simple rule of "end of statement, put semicolon".
>
> As
On Mon, Feb 03, 2003 at 08:19:29PM -0500, Miko O'Sullivan wrote:
> On Tue, 4 Feb 2003, [iso-8859-1] Stéphane Payrard wrote:
>
> > In the tradition of Perl concision, I would like newline to be a
> > statement terminator everywhere it can: that is when
> >a) the parser expects an operator
>
Miko O'Sullivan wrote:
>
> NOTE TO ALLISON RANDAL: in your face-to-face meetings next week, please
> make sure that "Larry Wall" isn't really Guido van Rossum with a fake
> mustache.
Righto. No reptiles, only jewels and birds. And possibly the occasional
snark. ;)
Allison
On Mon, Feb 03, 2003 at 06:11:23PM -0700, Luke Palmer wrote:
[snip]
>
> See, this is the main, unPerlish thing you're doing. You're enforcing
> particular styles upon people, something Perl is proud of *not* doing.
>
> Let's not forget the often occurence of:
>
> $fh = open 'foobar'
>
Miko O'Sullivan wrote:
>
> Therefore, I propose that members of the language list provide summaries
> of the discussions in the group. Each summary describes a proposed idea
> feature of the language, then summarizes the list's feelings on the idea.
> Different opinions will be presented. The su
> It would be trivial with a grammar munge to implement this (heck, I
> did it with a source filter in Perl 5). Surely CPAN6 (6PAN/CP6AN/??)
> will come out with one of these right off the bat, so you could do:
>
> use Grammar::ImplicitSemicolon;
>
> Or something like that, and be done with
On Tue, 4 Feb 2003, [iso-8859-1] Stéphane Payrard wrote:
> In the tradition of Perl concision, I would like newline to be a
> statement terminator everywhere it can: that is when
>a) the parser expects an operator
> _and_ b) we are not in the middle of a parenthesised expression.
I don
>
> Multiline atomic statements just have to be broken at the right
> place to avoid to break them:
Sorry about my English. Let me reformulate.
When folding an atomic statement, it becomes two statements or its
meaning is unchanged depending if an operand is expected or not at the
position of th
> Date: Tue, 4 Feb 2003 01:57:00 +0100
> From: =?iso-8859-1?Q?St=E9phane?= Payrard <[EMAIL PROTECTED]>
>
> In the tradition of Perl concision, I would like newline to be a
> statement terminator everywhere it can: that is when
>a) the parser expects an operator
> _and_ b) we are not in
In the tradition of Perl concision, I would like newline to be a
statement terminator everywhere it can: that is when
a) the parser expects an operator
_and_ b) we are not in the middle of a parenthesised expression.
Accessorily, it would also help people to switch back and forth
betwee
> > I guess what I'm saying is that someone needs to provide a real-world,
> > non-contrived, example showing ??= in use.
> Fair enough. Real World, Non-Contrived: In all databases that I've ever
> worked with there are exactly two possible values for a boolean database
> field. Those two values
Dan Sugalski wrote:
Tomorrow (tuesday) I'm heading out to Seabastapol CA for a week-long
perl 6 design get-together thingie.
When you are on it, please - again - have a look at our current string
behaviour. Keywords are: string_set, string header reusing, 50 % more
performance with life cy
Thats a great idea.
Murat
Dan Sugalski wrote:
> At 8:39 PM +0100 2/3/03, Jerome Quelin wrote:
> >Dan Sugalski wrote:
> >> *) Property: A named thing attached to an object. Properties are
> >> global to the object and public--i.e. there's no implicit hiding,
> >> namespaces, or whatnot. There can be only one foo property
On Mon, Feb 03, 2003 at 12:15:32PM -0500, Dan Sugalski wrote:
> *) Method: Some sort of action that an object can do. Methods are
> global and public--only one foo method for an object. Methods may be
> inherited from parent classes, or redefined in a particular class.
> Redefined methods hide
At 8:48 PM +0100 2/3/03, Jerome Quelin wrote:
Dan Sugalski wrote:
At 8:39 PM +0100 2/3/03, Jerome Quelin wrote:
>Dan Sugalski wrote:
>> *) Property: A named thing attached to an object. Properties are
>> global to the object and public--i.e. there's no implicit hiding,
>> namespaces, or w
Dan Sugalski wrote:
At 10:07 AM +0100 1/30/03, Leopold Toetsch wrote:
Changing the addressing scheme to opcode offsets relative to code
The big problem with this is you're increasing non-local call
performance for normal running. I don't think this is a good idea--while
you'll save maybe 50
At 8:39 PM +0100 2/3/03, Jerome Quelin wrote:
Dan Sugalski wrote:
*) Property: A named thing attached to an object. Properties are
global to the object and public--i.e. there's no implicit hiding,
namespaces, or whatnot. There can be only one foo property on an
object, for example
[...]
Th
SUMMARY
Members of the Perl6 Language list produce summaries discussions of
proposed features of the Perl6 language. These summaries will improve the
signal to noise ratio for Larry and his lieutenants as they try to keep up
with feelings in the list. See http://www.idocs.com/perl6/ for the firs
Damian wrote:
> This is just to let everybody know that I will be unsubscribing from
> p6-lang for the foreseeable future, effective immediately.
>
> I deeply regret that I simply no longer have the time to cope with the
> volume of messages being generated here. Unfortunately, the exigencies of
Dan Sugalski wrote:
> *) Property: A named thing attached to an object. Properties are
> global to the object and public--i.e. there's no implicit hiding,
> namespaces, or whatnot. There can be only one foo property on an
> object, for example
[...]
> The interpreter must handle class hierarchy stu
Folks,
I made a bet with Guido van Rossum that Parrot'd be faster at
executing a pure python benchmark of some sort (to be determined)
with the challenge details announced at OSCON 2003 and the results
tried at OSCON 2004. If I lose, I owe Guido $10 and a round of beer
for the zope/pythonlabs
At 6:25 PM + 2/3/03, Andy Wardley wrote:
Dan Sugalski wrote much sense, including these gems:
*) Method: Some sort of action that an object can do. Methods are
global and public--only one foo method for an object. Methods may be
inherited from parent classes, or redefined in a particular c
> -Original Message-
> From: Andy Wardley [mailto:[EMAIL PROTECTED]]On Behalf Of Andy Wardley
>
> Dan Sugalski wrote much sense, including these gems:
> > *) Method: Some sort of action that an object can do. Methods are
> > global and public--only one foo method for an object. Methods ma
Dan Sugalski wrote much sense, including these gems:
> *) Method: Some sort of action that an object can do. Methods are
> global and public--only one foo method for an object. Methods may be
> inherited from parent classes, or redefined in a particular class.
> Redefined methods hide parent cla
Okay, I figure it's time for a quick status report from me, since
I've been missing from the list of late and it's been showing. (Leo's
been doing grand things but at some point he's going to run out of
old mistakes of mine and'll need new ones to work with :)
Tomorrow (tuesday) I'm heading out
Okay, just to get some stuff defined and the problem space sorted
before I try and work on it:
Definitions:
*) Object: An opaque thingie with properties, attributes, and methods
*) Property: A named thing attached to an object. Properties are
global to the object and public--i.e.
At 10:07 AM +0100 1/30/03, Leopold Toetsch wrote:
Changing the addressing scheme to opcode offsets relative to code
start would simplify all kinds of (non local) control flow changes. As
real world programs mostly consists of such subroutine calls, these
would be simplified a lot (and would then n
The last 3 commits made native compiled PBCs (via pbc2c.pl) run a little
bit better:
Failed TestStat Wstat Total Fail Failed List of Failed
---
t/op/hacks.t 1 256 31 33.33% 1
t/op/integer.t4 10
Argh. Please disregard that last message as the ramblings of a
pre-caffeinated mind.
/s
On Mon, 3 Feb 2003, Sean O'Rourke wrote:
> On Mon, 3 Feb 2003, Dave Mitchell wrote:
> > $var ??= 'succeeded' :: 'failed';
>
> Aha!
>
> $var && 'succeeded' || 'failed';
>
> Thank you, precedence.
>
> /s
>
On Mon, 3 Feb 2003, Dave Mitchell wrote:
> $var ??= 'succeeded' :: 'failed';
Aha!
$var && 'succeeded' || 'failed';
Thank you, precedence.
/s
On Mon, 3 Feb 2003, Deborah Ariel Pickett wrote:
> I guess what I'm saying is that someone needs to provide a real-world,
> non-contrived, example showing ??= in use.
Fair enough. Real World, Non-Contrived: In all databases that I've ever
worked with there are exactly two possible values for a b
James --
I'm open to other ideas. I've toyed with learning DAML and RDF for some
ontology stuff I'm interested in, but so far I haven't had the mental
"click"
that would make me feel comfortable working with them. I do have a good
comfort level with XML in general.
I am pondering the sorts of tr
On Mon, Feb 03, 2003 at 06:25:09AM -0800, Austin Hastings wrote:
> The only time this doesn't change type (arguably a bad thing in its own
> right) is when you're doing boolean ops. And for those, there exist
> boolean operators.
Changing type is a very Perlish thing to do.
> > How 'bout a shortc
--- Miko O'Sullivan <[EMAIL PROTECTED]> wrote:
> SUMMARY
>
> C<$var ?= $x : $y> as a shortcut for C<$var = $var ? $x : $y>.
>
>
> DETAILS
>
> We have ||=, +=, -=, etc. These shortcuts (I'm sure there's some
> fancy
> linguistic term for them) save us a few keystrokes and clean up the
> code.
--- [EMAIL PROTECTED] wrote:
> I just committed some changes to the Jako compiler that add a '-x'
> switch. Using jakoc -x will cause the compiler to emit the parse tree
> as XML (via SAX events sent to XML::Handler::YAWriter).
>
Sounds interesting. I have to look into this,
i have dropped xml i
I just committed some changes to the Jako compiler that add a '-x'
switch. Using jakoc -x will cause the compiler to emit the parse tree
as XML (via SAX events sent to XML::Handler::YAWriter).
It still has some worts, but it didn't die when I turned it loose on the
Jako examples.
There are a few
# New Ticket Created by Joe Yates
# Please include the string: [perl #20666]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=20666 >
Line numbers reported by Assemble.pl are array indices AFTER the removal of
macros.
This
40 matches
Mail list logo
