Re: Introduction to Synopses
On 09/30/2013 02:16 AM, Patrick R. Michaud wrote: On Mon, Sep 30, 2013 at 02:03:43AM +0800, Richard Hainsworth wrote: Not wising to disagree with PM, but |docs/feather/syn_index.html states on line 1:| The Synopsis documents are to be taken as the formal specification for Perl 6 implementations What follows is just my opinion, there's plenty of room for reasonable disagreement. It would be useful at some stage to come to a consensus about how to describe Perl6. Over the last couple of years I've come to disagree with this statement in syn_index.html . Informally we often talk about the synopses as being the official spec, and I'm as guilty of that as anyone else. Larry Wall's ideas about language development differ from the paradigm that existed before. In one of the paradigms, a language designer creates a specification (eg. C) and then an implementation is created. This leads to the necessity for very tedious and specific specs. As pointed out in Synopsis 1, it implies perfect knowledge before the language has been created. What's new here is the three different components all moving together, and also that the language is defined in terms of both the specification and the tests. In the traditional sense, the specification of Perl6 is the combination of Synopses and Test Suite. But the Synopses on their own do not define Perl6, as you have pointed out. What I have suggested is to use another word describe (or perhaps define might be better) instead of specify. Specification has been used in the Perl6 community to mean the Synopses so I suggest keeping that identity. However, we use another word to describe the combination. Even the name of the repository holding the synopses is given as specs. But as all of us know, some parts of the synopses are incredibly slushy, or even quite fluid, and so it's not something that people can really treat as truly specification. And there are countless parts of the synopses that have radically changed as a result of lessons learned in implementation... (I can tell long stories about S05!). Thus it was recognized early on (in Synopsis 1) that acceptance tests provide a far more objective measure of specification conformance than an English description. There are likely things that need to be spec that cannot be fully captured by testing... but I still believe that the test suite should be paramount. Perl6 language development is a gradual change of specification, test suite and implementation until the specification is proven by implementations, which all pass the test suite, for some sense of 'proven' and some set of 'implementations'. A version of Perl6 is described by the combination of a specification suite and a test suite. I'd prefer that versions of Perl 6 be captured solely by the test suite. I don't know how practical this is, though. I don't like the notion of specification suite... it feels too nebulous to me. A version of Perl6 is declared to be ready when there is at least one full implementation exists that generates code considered to be sufficiently fast and memory efficient. I also don't like the idea of defining readiness in the abstract. Something is ready when it is capable of solving the problem(s) to which it is being put. When is can a version of Perl6 be considered to have evolved? Rakudo is already being used to solve problems. I have used it to solve problems. Maybe not a vast range of problems, nor is the speed impressive. A language is in itself an abstract thing. Pm
Re: Introduction to Synopses
Hi Richard, On 09/29/2013 07:28 AM, Richard Hainsworth wrote: Some suggestions about documentation. Originally the Synopses were implementation oriented sumaries of the previous description base Apocalypses. That meant that the Synopses were derivative and secondary to the Apocalypses However, the Synopses are now primary specification and the Apocalypses have only historical significance. Also there are more Synopses than Apocalypses. I suggest the introductory paragraphs to the Synopses are changed to reflect this. A good idea. Please do it! The page you're probably think of is in the perl6/mu repo on github in the file docs/feather/syn_index.html. If you have a github user name, please tell me, and I can give you commit access. Cheers, Moritz
Re: Introduction to Synopses
On Sun, Sep 29, 2013 at 01:28:48PM +0800, Richard Hainsworth wrote: However, the Synopses are now primary specification and the Apocalypses have only historical significance. Also there are more Synopses than Apocalypses. One correction: The test suite (roast) is the primary specification (see Synopsis 1). To me, the Synopses are the English description of our understanding of the specification / language, as well as a roadmap for growth in the future. Pm
Re: Introduction to Synopses
Not wising to disagree with PM, but |docs/feather/syn_index.html states on line 1:| The Synopsis documents are to be taken as the formal specification for Perl 6 implementations I have seen elsewhere, can't remember where, that the parser written by Larry is also considered a part of the specification. Is this correct? From Synopsis 1: Perl 6 is anything that passes the official test suite hacking on any implementation of Perl 6 to make it conform to the test suite ... hacking on the test suite to make it reflect consensus of specification parts of the spec are already effectively frozen ...specced features ... not ... proven in an implementation ... considered ... conjectural May I suggest we add the following language to Synopsis 1 to capture all these statements? Perl6 language development is a gradual change of specification, test suite and implementation until the specification is proven by implementations, which all pass the test suite, for some sense of 'proven' and some set of 'implementations'. A version of Perl6 is described by the combination of a specification suite and a test suite. The specification suite consists of the Synopses and the parser written in Perl6 A full implementation generates code that passes the entire test suite. A version of Perl6 is declared to be ready when there is at least one full implementation exists that generates code considered to be sufficiently fast and memory efficient. On 09/29/2013 09:13 PM, Patrick R. Michaud wrote: On Sun, Sep 29, 2013 at 01:28:48PM +0800, Richard Hainsworth wrote: However, the Synopses are now primary specification and the Apocalypses have only historical significance. Also there are more Synopses than Apocalypses. One correction: The test suite (roast) is the primary specification (see Synopsis 1). To me, the Synopses are the English description of our understanding of the specification / language, as well as a roadmap for growth in the future. Pm
Re: Introduction to Synopses
On Mon, Sep 30, 2013 at 02:03:43AM +0800, Richard Hainsworth wrote: Not wising to disagree with PM, but |docs/feather/syn_index.html states on line 1:| The Synopsis documents are to be taken as the formal specification for Perl 6 implementations What follows is just my opinion, there's plenty of room for reasonable disagreement. Over the last couple of years I've come to disagree with this statement in syn_index.html . Informally we often talk about the synopses as being the official spec, and I'm as guilty of that as anyone else. Even the name of the repository holding the synopses is given as specs. But as all of us know, some parts of the synopses are incredibly slushy, or even quite fluid, and so it's not something that people can really treat as truly specification. And there are countless parts of the synopses that have radically changed as a result of lessons learned in implementation... (I can tell long stories about S05!). Thus it was recognized early on (in Synopsis 1) that acceptance tests provide a far more objective measure of specification conformance than an English description. There are likely things that need to be spec that cannot be fully captured by testing... but I still believe that the test suite should be paramount. Perl6 language development is a gradual change of specification, test suite and implementation until the specification is proven by implementations, which all pass the test suite, for some sense of 'proven' and some set of 'implementations'. A version of Perl6 is described by the combination of a specification suite and a test suite. I'd prefer that versions of Perl 6 be captured solely by the test suite. I don't know how practical this is, though. I don't like the notion of specification suite... it feels too nebulous to me. A version of Perl6 is declared to be ready when there is at least one full implementation exists that generates code considered to be sufficiently fast and memory efficient. I also don't like the idea of defining readiness in the abstract. Something is ready when it is capable of solving the problem(s) to which it is being put. Pm
Re: Introduction
On Fri, Dec 16, 2005 at 12:11:45AM -0800, David Romano ([EMAIL PROTECTED]) wrote: progress: how do I get a perl.org subversion account? Is that after the module author accepts the proposal? I can set you up with the svn.perl.org access. You need an account on perl.org, and then you'll tell me what project you want set up. Let us know how it goes! We're glad to have you join us. xoxo, Andy -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: introduction
Comrade Burnout wrote: I remember seeing that the list-joining thingie mentioned an introduction once someone joined, so here it is: I'm geektron on perlmonks, and Brian Clarkson IRL. I've talked a bit to Mr. Lester and Mr. Kinyon about tests, and decided that learning some good testing skills while doing something useful added up to joining this list and the Phalanx project. I'm not sure where to start other than this. So hi and stuff. Re: Phalanx: If you're interested in working on this in an F2F manner (other hoplites in the same room!), sign up on the HereToHelp page of the Phalanx kwiki (http://phalanx.kwiki.org/index.cgi?HereToHelp) and indicate what city or metro area you live in. Or hook up with one of the local Perlmonger groups listed on the kwiki home page if you're in one of those areas. Jim Keenan
Re: introduction
Comrade Burnout wrote: I'm not sure where to start other than this. So hi and stuff. Hi, Brian. -- Ian Langworth Project Guerrilla Northeastern University College of Computer and Information Science
[perl #19872] Fwd: Re: Introduction and cygwin results
# New Ticket Created by James Michael DuPont # Please include the string: [perl #19872] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt2/Ticket/Display.html?id=19872 Missing header file for cygwin --- James Michael DuPont [EMAIL PROTECTED] wrote: From James Michael DuPont Fri Jan 3 11:01:39 2003 Received: from [194.202.25.243] by web13307.mail.yahoo.com via HTTP; Fri, 03 Jan 2003 11:01:39 PST Date: Fri, 3 Jan 2003 11:01:39 -0800 (PST) From: James Michael DuPont [EMAIL PROTECTED] Subject: Re: Introduction and cygwin results To: [EMAIL PROTECTED] In-Reply-To: [EMAIL PROTECTED] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Length: 978 --- James Michael DuPont [EMAIL PROTECTED] wrote: Hi There! [SECTION PACKDUMP] make packdump.exe packdump.c: In function `PackFile_Constant_dump': packdump.c:111: structure has no member named `flags' make: *** [packdump.o] Error 1 I have commented that out for now : /*PIO_printf(interpreter, FLAGS= 0x%04lx,\n, (long)self-string-flags); */ Oopps : more then that : pdump.c: In function `main': pdump.c:21: storage size of `file_stat' isn't known pdump.c:37: `O_RDONLY' undeclared (first use in this function) pdump.c:37: (Each undeclared identifier is reported only once pdump.c:37: for each function it appears in.) under cygwin you need : #include fcntl.h mike = James Michael DuPont http://introspector.sourceforge.net/ __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com = James Michael DuPont http://introspector.sourceforge.net/ __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
Re: Introduction and cygwin results
At 10:51 AM -0800 1/3/03, James Michael DuPont wrote: Can someone tell me if anyone uses packdump from cvs? is that an equivalent to ildasm in dotnet? It seems to be broken. Can I dump an set of instructions from a program into a file, and reassemble them? If not, is there a way to dump a parrot program? Not that I know of, I think so, damn, you should be able to, and no no other way. Is there a way to capture the line number, and comments of a perl6 program in parrot? What about high level type information? Line number, yes. Comments, probably not, though it's possible that info can get embedded. What type of high-level info are you looking for? We've all sorts. :) Seriously, if you're looking for variable type info, it'll potentially be there, assuming that it's not been stripped out. I would be willing to port my code to the subset of perl/parrot that is currently supported, where I can i find that? Perl 6 is in languages/perl6, though I think that there's still some stuff missing. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Introduction and cygwin results
--- Dan Sugalski [EMAIL PROTECTED] wrote:
At 10:51 AM -0800 1/3/03, James Michael DuPont wrote:
Can someone tell me if anyone uses packdump from cvs? is that an
equivalent to ildasm in dotnet? It seems to be broken.
Can I dump an set of instructions from a program into a file, and
reassemble them?
If not, is there a way to dump a parrot program?
Not that I know of, I think so, damn, you should be able to, and no
no other way.
Here is my patch for pdump :
But the pdump does not disassemble... i have to look into
dissassemble.pl
Index: packdump.c
===
RCS file: /cvs/public/parrot/packdump.c,v
retrieving revision 1.6
diff -u -r1.6 packdump.c
--- packdump.c 2 Nov 2002 14:57:47 - 1.6
+++ packdump.c 4 Jan 2003 16:18:37 -
@@ -107,8 +107,13 @@
case PFC_STRING:
PIO_printf(interpreter, [ 'PFC_STRING', {\n);
-PIO_printf(interpreter, FLAGS= 0x%04lx,\n,
+
+#ifdef HAS_parrot_string_t_flags
+
+PIO_printf(interpreter, FLAGS=
0x%04lx,\n,
(long)self-string-flags);
+#endif
+
PIO_printf(interpreter, ENCODING = %s,\n,
self-string-encoding-name);
PIO_printf(interpreter, TYPE = %s,\n,
Anyone working on cross compiling? I have a setup here for cross
compiling from debian to windows, but always use autoconf to do that.
Anyone have an idea?
Is there a way to capture the line number, and comments of a perl6
program in parrot? What about high level type information?
Line number, yes. Comments, probably not, though it's possible that
info can get embedded. What type of high-level info are you looking
for? We've all sorts. :)
well as much as you can give me.
Seriously, if you're looking for variable
type info, it'll potentially be there, assuming that it's not been
stripped out.
OK, that is good.
I would be willing to port my code to the subset of perl/parrot that
is
currently supported, where I can i find that?
Perl 6 is in languages/perl6, though I think that there's still some
stuff missing.
Well, I will try that out. Thanks,
mike
=
James Michael DuPont
http://introspector.sourceforge.net/
__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
Re: Introduction and cygwin results
--- James Michael DuPont [EMAIL PROTECTED] wrote: Hi There! [SECTION PACKDUMP] make packdump.exe packdump.c: In function `PackFile_Constant_dump': packdump.c:111: structure has no member named `flags' make: *** [packdump.o] Error 1 I have commented that out for now : /*PIO_printf(interpreter, FLAGS= 0x%04lx,\n, (long)self-string-flags); */ Oopps : more then that : pdump.c: In function `main': pdump.c:21: storage size of `file_stat' isn't known pdump.c:37: `O_RDONLY' undeclared (first use in this function) pdump.c:37: (Each undeclared identifier is reported only once pdump.c:37: for each function it appears in.) under cygwin you need : #include fcntl.h mike = James Michael DuPont http://introspector.sourceforge.net/ __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
Re: Introduction, I suppose.
On Wed, Nov 15, 2000 at 03:29:24AM +, David Grove wrote: If this should be a PDD, I'll be happy to propose it that way, but I will need some slight help in the specific implementation of the C code that does it. I may have misunderstood the purpose of this group, but it's *API*, which means we're not (yet) designing how the parser acts or is implemented, but we're merely talking about how it communicates with the rest of Perl. So I think we're expecting to see things along the lines of: OP* parse(SV *); /* Parse a piece of code, return op tree */ void parse_add_hook(int level, FPTR function, void* data); /* Add a hook (function) to be called at level (level) of parsing */ Have patience. :) -- The angels want to wear my red shoes.
Re: Introduction, I suppose.
On Wed, Nov 15, 2000 at 11:55:27AM +, Simon Cozens wrote: On Wed, Nov 15, 2000 at 03:29:24AM +, David Grove wrote: If this should be a PDD, I'll be happy to propose it that way, but I will need some slight help in the specific implementation of the C code that does it. I may have misunderstood the purpose of this group, but it's *API*, which means we're not (yet) designing how the parser acts or is implemented, but The parser acts and is implemented in a fast, compact, and clean way :-) we're merely talking about how it communicates with the rest of Perl. So I think we're expecting to see things along the lines of: OP* parse(SV *); /* Parse a piece of code, return op tree */ void parse_add_hook(int level, FPTR function, void* data); /* Add a hook (function) to be called at level (level) of parsing */ Yes, that's the kind of stuff we are after. -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: Introduction, I suppose.
Oops. ;-)) And I thought I was on a roll, contributing to the Perl 6 source core thingy... LOL Jarkko Hietaniemi [EMAIL PROTECTED] wrote: On Wed, Nov 15, 2000 at 11:55:27AM +, Simon Cozens wrote: On Wed, Nov 15, 2000 at 03:29:24AM +, David Grove wrote: If this should be a PDD, I'll be happy to propose it that way, but I will need some slight help in the specific implementation of the C code that does it. I may have misunderstood the purpose of this group, but it's *API*, which means we're not (yet) designing how the parser acts or is implemented, but The parser acts and is implemented in a fast, compact, and clean way :-) we're merely talking about how it communicates with the rest of Perl. So I think we're expecting to see things along the lines of: OP* parse(SV *); /* Parse a piece of code, return op tree */ void parse_add_hook(int level, FPTR function, void* data); /* Add a hook (function) to be called at level (level) of parsing */ Yes, that's the kind of stuff we are after. -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
