subject line of all future correspondence about this issue.
> > > # http://rt.perl.org/rt3/Ticket/Display.html?id=43078 >
> > >
> > >
> > > TODO: Describe how lexical naming system interacts with non-ASCII
> > character
> > > sets.
it should be a good model for every Perl 6 developer. And it
should use the same naming conventions which are usual for Perl 6.
I don't know if there are some naming conventions for Perl 6 released
yet, if not I strongly recommend to take this ones who are common for
Perl 5. In other words:
# New Ticket Created by Paul Cochrane
# Please include the string: [perl #43093]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=43093 >
Hi all,
This patch corrects some of the pod in docs/ to reflect the fact that
develope
Will Coleda (via RT) writes:
# New Ticket Created by Will Coleda
# Please include the string: [perl #43078]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=43078 >
TODO: Describe how lexical naming system interacts w
# New Ticket Created by Will Coleda
# Please include the string: [perl #43078]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=43078 >
TODO: Describe how lexical naming system interacts with non-ASCII character
s
his issue.
: > # http://rt.perl.org/rt3/Ticket/Display.html?id=41623 >
: >
: >
: > pge's syntax for specifying ops to the op precedence parser should
: > follow the perl 6 spec in it's op rule naming convention. that is,
: > 'infix:+'
: > 'circumf
;
> pge's syntax for specifying ops to the op precedence parser should
> follow the perl 6 spec in it's op rule naming convention. that is,
> 'infix:+'
> 'circumfix:( )'
>
> should be
> infix:<+>
> circumfix:<( )>
We s
l 6 spec in it's op rule naming convention. that is,
'infix:+'
'circumfix:( )'
should be
infix:<+>
circumfix:<( )>
~jerry
Allison Randal wrote:
How about "Partridge"? It starts with 'p', it's a bird, and brings to
mind "Partridge in a Pear Tree" which goes with the theme of
tree-based compiler tools (PGE outputs trees, TGE munges trees). We
can pretend we named it after Kurt Partridge for his work on ZPL or
Andre
How about "Partridge"? It starts with 'p', it's a bird, and brings to
mind "Partridge in a Pear Tree" which goes with the theme of tree-based
compiler tools (PGE outputs trees, TGE munges trees). We can pretend we
named it after Kurt Partridge for his work on ZPL or Andrew Partridge
for his wor
On Mon, Sep 19, 2005 at 11:18:17PM -1000, Joshua Hoblitt wrote:
> On Tue, Sep 20, 2005 at 12:33:38AM -0700, Brent 'Dax' Royal-Gordon wrote:
> > > > I submitted the patch below my sig way back in August 2002, in ticket
> > > > 16622. It documented th
On Tue, Sep 20, 2005 at 12:33:38AM -0700, Brent 'Dax' Royal-Gordon wrote:
> > > I submitted the patch below my sig way back in August 2002, in ticket
> > > 16622. It documented the then-current naming conventions for
> > > structures. Is it still accurate
> > I submitted the patch below my sig way back in August 2002, in ticket
> > 16622. It documented the then-current naming conventions for
> > structures. Is it still accurate and/or a good idea? Should it (or an
> > up-to-date version of it) be committed?
>
>
Simon Glover <[EMAIL PROTECTED]> wrote:
> ... However, if we
> want to create an anonymous subclass, using the 2-argument form of the
> subclass op, then we hit a problem -- the code:
> newclass P0, "City"
> subclass P1, P0
> newclass P2, "State"
> subclass P3, P2
> en
# New Ticket Created by Simon Glover
# Please include the string: [perl #33103]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=33103 >
This code snippet:
newclass P0, "City"
subclass P1, P0, "New York"
Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]> wrote:
> The naming of the interpreter structure has changed. The struct is
> now called "parrot_interp_t";
Thanls,
leo
The naming of the interpreter structure has changed. The struct is
now called "parrot_interp_t"; use of the typedef "Interp" is now
recommended in function declarations and definitions (e.g. C).
This will affect many pending patches. If you're working on a patch,
ple
I submitted the patch below my sig way back in August 2002, in ticket
16622. It documented the then-current naming conventions for
structures. Is it still accurate and/or a good idea? Should it (or an
up-to-date version of it) be committed?
(It's almost certainly been line-wrapped in
At 10:41 PM +0100 2/17/04, Leopold Toetsch wrote:
Dan Sugalski wrote:
Either way, I don't think IMCC should have to deal with language
symbols explicitly.
Zhat's true. But still we need to know, *what are* language symbols.
I've stated several times that for the spilling code its essential
to k
Dan Sugalski wrote:
Either way, I don't think IMCC should have to deal with language symbols
explicitly.
Zhat's true. But still we need to know, *what are* language symbols.
I've stated several times that for the spilling code its essential to
know, if a symbol has already a store in either lex
At 12:26 PM -0500 2/11/04, Melvin Smith wrote:
The request, mainly, is for imcc to handle sigil characters
from other languages which basically equates to exposing
a lot to imcc from the high-level language.
If you're looking for a "How do I use $foo in my imcc code?" then I
have one of two answer
Melvin Smith <[EMAIL PROTECTED]> wrote:
> Another option is to use quotes for symbols with sigils,
And we have to cope with unicode finally. So I'd vote for that
alternative. *But* as code normally comes out of a compiler and there
may be many different compilers, we can't deal with arbitrary sym
nvisage something like:
$'%foo' = new PerlHash
But is that all that more readable than:
$Hfoo = new PerlHash
I would say we should definitely go with something like this if
registers held more permanent values. But in writing my own compilers,
I've found that most of my regis
On Wed, 11 Feb 2004 15:04:53 -0500, Matt Fowles
<[EMAIL PROTECTED]> wrote:
>All~
>
>I don't like the leading C<.> option, what about having a leading _ for
I don't care. Really, I don't care. I kinda like $, but I don't care.
I currently get by just with $[I.N.S.P]nnn symbolic temporaries
because
Hi,
> I don't like the leading C<.> option, what about having a leading _ for
> temporaries instead and allowing any non-space, non-operator character
> in symbol names, so _$foo would be a valid temp. This has the advantage
> of not conflicting with symbolic registers.
>
But could it potentially
All~
I don't like the leading C<.> option, what about having a leading _ for
temporaries instead and allowing any non-space, non-operator character
in symbol names, so _$foo would be a valid temp. This has the advantage
of not conflicting with symbolic registers.
The other option is to force
RFD = Request For Discussion ;)
Much discussion has been made on IRC concerning
symbol names.
The request, mainly, is for imcc to handle sigil characters
from other languages which basically equates to exposing
a lot to imcc from the high-level language. I won't
argue how much of that is good or b
+
+Functions with external visibility should be of the form C,
+and should only use typedefs with external visibility (or types defined
+in C89). Generally these functions should not be used inside the core,
+but this is not a hard and fast rule.
=item *
Variables and structure names should be
m C,
+and should only use typedefs with external visibility (or types defined
+in C89). Generally these functions should not be used inside the core,
+but this is not a hard and fast rule.
=item *
Variables and structure names should be all lower-case, eg C.
+See L<"Structure
should only use typedefs with external visibility (or types defined
+in C89). Generally these functions should not be used inside the core,
+but this is not a hard and fast rule.
=item *
Variables and structure names should be all lower-case, eg C.
+See L<"Structures and Typedefs"&
At 05:16 PM 6/7/2002 -0700, Brent Dax wrote:
>Subject says it all. Updates conventions to be consistent with much of
>the core. Unfortunately, that doesn't include 'struct Parrot_Interp'.
I'll work on bringing the source up to date as soon as pending patches are in.
-Melvin
Subject says it all. Updates conventions to be consistent with much of
the core. Unfortunately, that doesn't include 'struct Parrot_Interp'.
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
Early in the series, Patrick Stewart came up to us and asked how
Rather than naming all the basic Parrot types (I mean classes
that are exposed at the PASM level) Parrot*
(ParrotPointer, ParrotSub, ...) I propse we name them by their
simple names and require all new languages to prefix their
types ala PerlString, etc. We already have Array and Intqueue
that
On Fri, 11 Jan 2002, Jonathan Leffler wrote:
> On Thu, 10 Jan 2002, Steve Fink wrote:
>
> >[...] I'd like to propose a convention [...] By example:
> >
> >struct somename_t { ... };
> >typedef struct somename_t { ... }* Somename;
> >
> >The non-typedef'd name of a struct type ends in _t.
>
> Is
On Fri, Jan 11, 2002 at 11:45:03AM -0800, Jonathan Leffler wrote:
> On Thu, 10 Jan 2002, Steve Fink wrote:
>
> >[...] I'd like to propose a convention [...] By example:
> >
> >struct somename_t { ... };
> >typedef struct somename_t { ... }* Somename;
> >
> >The non-typedef'd name of a struct ty
On Thu, 10 Jan 2002, Steve Fink wrote:
>[...] I'd like to propose a convention [...] By example:
>
>struct somename_t { ... };
>typedef struct somename_t { ... }* Somename;
>
>The non-typedef'd name of a struct type ends in _t.
Is this a good idea? The _t suffix is reserved by POSIX for use b
At 11:34 PM 1/10/2002 +, Tom Hughes wrote:
>In message <20020110201559$[EMAIL PROTECTED]>
> "Melvin Smith" <[EMAIL PROTECTED]> wrote:
>
>Well sizeof(Foo) and sizeof(*foo) are not actually the same thing
>at all there because Foo is presumably a typedef for a pointer type
>so sizeof(F
In message <20020110201559$[EMAIL PROTECTED]>
"Melvin Smith" <[EMAIL PROTECTED]> wrote:
> > Foo foo = (Foo) malloc(sizeof(*foo));
> >? Does ANSI allow using sizeof on a variable declared on the
> > same line?
>
> Wouldn't sizeof(Foo) be safer here? At the logical time of the
> call *f
On Thu, Jan 10, 2002 at 03:18:33PM -0500, Melvin Smith wrote:
> Eep, to answer the original subject of your mail, I think its a good idea
> to start with the _t typedef standard.
except that POSIX (IIRC, but it's either them or ANSI) reserves all names
ending in _t for themselves. So any other na
On Thu, Jan 10, 2002 at 02:31:24PM -0600, David M. Lloyd wrote:
> On Thu, 10 Jan 2002, Steve Fink wrote:
>
> > The naming of things is getting a bit messy. I'd like to propose a
> > convention that I use in my work. It's compatible with the last draft
> > of
On Thu, Jan 10, 2002 at 02:31:24PM -0600, David M. Lloyd wrote:
> After looking through PDD 7, I wonder: were we planning on doing any of
> this stuff? If so, maybe we should step back for a moment and do it. :-)
> If developers are expected to follow these guidelines (not that I've done
> any de
On Thu, 10 Jan 2002, Steve Fink wrote:
> The naming of things is getting a bit messy. I'd like to propose a
> convention that I use in my work. It's compatible with the last draft
> of PDD 7 that I could find:
> http://www.mail-archive.com/perl6-internals%40perl.org/msg0
Eep, to answer the original subject of your mail, I think its a good idea
to start with the _t typedef standard.
-Melvin Smith
IBM :: Atlanta Innovation Center
[EMAIL PROTECTED] :: 770-835-6984
> Foo foo = (Foo) malloc(sizeof(*foo));
>? Does ANSI allow using sizeof on a variable declared on the
> same line?
Wouldn't sizeof(Foo) be safer here? At the logical time of the
call *foo points to undefined. Technically its not a deref but
still looks scary. In C++ it might be confusing if you
The naming of things is getting a bit messy. I'd like to propose a
convention that I use in my work. It's compatible with the last draft
of PDD 7 that I could find:
http://www.mail-archive.com/perl6-internals%40perl.org/msg03422.html
By example:
struct somename_t { ... };
type
On Tue, Sep 18, 2001 at 07:52:06PM -0400, Dan Sugalski wrote:
> More to the point, it needs typing exactly twice--once in the .ops file
> that defines the opcode function body, and once in opcode_table. The
> assembler, of course, uses the smaller name.
Three times: And once to name the test ca
At 04:31 PM 9/18/2001 -0700, Dave Storrs wrote:
> So, yes, you'd get 'mul_i_ic_ic', but who cares? It's not really
>that hard to type, and it is absolutely unambiguous. If you want to make
>the interpreter magically deduce the full opcode name from the prefix,
>that's cool, too.
More to
There was a thread on this recently, but I'm not sure what was
resolved. Do we have a standard naming convention for opcodes?
Personally, I'd like to see that we stick with (what I thought was) the
original plan: a nice, simple ruleset that produces long but predictable
names.
On Fri, Sep 07, 2001 at 10:32:42AM -0400, Dan Sugalski wrote:
> Simon's going there already. We should fix the docs up, though. (I have a
> bunch of PDDs to update and submit. I think they're going to go into the
> CVS repository too, once it's fully operational, so I don't lose track of
> thin
At 04:55 PM 9/6/2001 -0700, Benjamin Stuhl wrote:
>I had a thought this morning on funtion/struct/global
>prefixes for Parrot. If we really plan to also run
>Python/Ruby/whatever on it, it does not look good for the
>entire API to be prefixed with "perl_". We really (IMHO)
>ought to pick something
On Thu, Sep 06, 2001 at 04:55:49PM -0700, Benjamin Stuhl wrote:
> I had a thought this morning on funtion/struct/global
> prefixes for Parrot. If we really plan to also run
> Python/Ruby/whatever on it, it does not look good for the
> entire API to be prefixed with "perl_". We really (IMHO)
> ough
I had a thought this morning on funtion/struct/global
prefixes for Parrot. If we really plan to also run
Python/Ruby/whatever on it, it does not look good for the
entire API to be prefixed with "perl_". We really (IMHO)
ought to pick something else so that we don't give people a
convenient target
52 matches
Mail list logo
