[svn:perl6-synopsis] r9575 - doc/trunk/design/syn
Author: audreyt Date: Sun Jun 11 17:16:35 2006 New Revision: 9575 Modified: doc/trunk/design/syn/S03.pod Log: * S03: typo, nit, etc, reported by masak++. Modified: doc/trunk/design/syn/S03.pod == --- doc/trunk/design/syn/S03.pod(original) +++ doc/trunk/design/syn/S03.podSun Jun 11 17:16:35 2006 @@ -149,10 +149,10 @@ operators that are known to return numbers, strings, or booleans. (Operators that imply list operations are excluded: C<@>, C<%>, and C, for instance. Hyper operators are also excluded, but -post-assigment forms such as C is allowed.) +post-assigment forms such as C are allowed. All other forms imply list assignment, and will evaluate both sides -of the assignment in list context (eventually). However, this is +of the assignment in list context at runtime. However, this is primarily a syntactic distinction, and no semantic or type information is used, since it influences subsequent parsing. In particular, even if a function is known to return a scalar value from its declaration,
Re: Perl++ Wikicosm (was: OT: wiki engine architecture)
1) Understood. I've been disconnected from Perl for a while, and this is really the first time I've been participating in the Perl community. Thanks for the heads-up. :) 2) I agree that it is both important and pertinent to get the general requirements down for the project, but I do see a need and a benefit to having the architecture forming in the meanwhile. I see how these things can be connected, obviously, but with a fairly flexible architecture it can be easy to expand or change it as needed. If we have the skeletal system in place, we can add the muscle and the skin on as needed. [Read more of my comments below.] 3) I'll be honest and say that I'm not a big fan of the 'Wikicosm' part, but the Perl++ part works for me. I particiularly like simple names. Maybe we could go with something distinctive, much like 'Joomla' is or 'Drupal', etc. Something different, and not nearly as explicit. Mainly speaking on point number 2 again, I agree that we need to be discussing and deciding on the minimal features, but this is does not mean that the architecture should be poorly designed. Even with a weakly implemented yet well designed base, it would be easier to take this minimal wiki and upgrade it into something very powerful. I guess what my very first recommendation (before even a name) is that we have a flexible, well-designed archiecture, preferrably with an MVC pattern, with RESTful-like (URL) mapping, etc. I believe that this will be integral to the successful adoption in the community because it allows for very expansive modification. I will be looking over some other features to recommend. Wherein shall we officially submit our recommendations? Here? And is there a specific way to do so? (This is more of a conversation-generating question.) M.T.
Perl++ Wikicosm (was: OT: wiki engine architecture)
Matt Todd wrote: > On the architecture note, I've written up a quick article about a > possible implementation of the MVC pattern for the wiki. Indeed, it's > a very flexible implementation and really resembles a framework. (To > be honest, it's from my work on my PHP framework.) > > Please take a moment to look through it and let me know what you folks > think. It's not meant to be anything other than a starting point, if > for nothing else then for discussion. > > http://www.maraby.com/lang/perl6/wiki/architecture.html > > Again, let me know what you think. Well, first of all, thanks. 1) s|//|#| # More generally, Perl 6 look and feel. :-) 2) (General comment for all discussions.) It would be nice if any proposal included a clear separation between the long term vision and the *minimal* subset needed to get started *now*, as noted elsewhere: (http://www.nntp.perl.org/group/perl.perl6.users/264), (http://www.nntp.perl.org/group/perl.perl6.users/263). 3) (Quoting from above link): "I propose that the wiki be called P6 to signify its use of Perl6." I presently prefer something like the "Perl++ Wikicosm". Reasons: (a) easy googling (only web hit I see today is my previous use), (b) to avoid implying a pure Perl 6 implementation, (c) I'd like this to serve the Perl 5.8/(5.9/5.10) community as well as Perl 6, and more generally, (d) to serve as a common crossroads for other Parrot-related language interoperability information, among other things. Best regards, Conrad Schneiker http://perl.net.au/wiki/Perl_6_Users_FAQ (Moved from AthenaLab to Perl 6 Wiki.) www.AthenaLab.com (Nano-electron-beam and micro-neutron-beam technology.)
Perl++ Wikicosm (was: wiki engine architecture (was: $1,000 prize for Perl 6 Wiki written in Perl 6))
> -Original Message- > From: A. Pagaltzis [mailto:[EMAIL PROTECTED] > All I can think of is "YAGNI". Good point, but I wonder how many other people recognize the significance of that crypticism? http://en.wikipedia.org/wiki/YAGNI http://www.jera.com/techinfo/xpfaq.html Other good guidelines to keep in mind (for purposes of this project): "Start with the smallest useful feature set." "Do the simplest thing that could possibly work." Best regards, Conrad Schneiker http://perl.net.au/wiki/Perl_6_Users_FAQ (Moved from AthenaLab to Perl 6 Wiki.) www.AthenaLab.com (Nano-electron-beam and micro-neutron-beam technology.)
A question about .begin_eh
I notice the following paragraph, vintage late May, in pdd23_exceptions.pod: A C<.begin_eh> directive marks the beginning of a span of opcodes which the programmer expects to throw an exception. If an exception occurs in the execution of the given opcode span, Parrot will transfer control to I. I assume this means that you intend to replace the current methodology of searching for an Exception_Handler object on the control stack when an error is thrown with a search through sub metadata. How do you envision this interacting with C, e.g.? Currently, it is straightforward for find_exception_handler to DTRT WRT other control stack entries. Would the metadata also contain information about C and such? TIA, -- Bob Rogers http://rgrjr.dyndns.org/ P.S. FWIW, I am asking now because I have begun to work again on dynamic binding -- which of course makes this problem worse.
Re: Continuous testing tools
Michael G Schwern wrote: On 6/9/06, A. Pagaltzis <[EMAIL PROTECTED]> wrote: * Adam Kennedy <[EMAIL PROTECTED]> [2006-06-09 18:35]: > Sorry for the lack of information, but PITA's design is fairly > ambitious, Hmm, I just saw this: http://googleresearch.blogspot.com/2006/04/our-conference-on-automated-testing.html The submission deadline has already passed, but I figure that anyone on this thread will likely be interested about the conference itself. Its September 7 - 8 which puts it the week after YAPC::Europe for those who are planning on flying to the UK for that anyway. Alas, it's looking like YAPC::Europe isn't going to happen for me this year :( But I wonder if Google AU will be doing some form of video-linkup for it. Adam K
Re: [svn:perl6-synopsis] r9536 - doc/trunk/design/syn
On 6/11/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: [...] @@ -147,8 +147,9 @@ precedence levels autoincrement, exponentiation, symbolic unary, multiplicative, and additive; but these are limited to standard operators that are known to return numbers, strings, or booleans. -(Operators that imply list operations are excluded: C<$>, C<@>, -and C, for instance. Hyper operators are also excluded.) +(Operators that imply list operations are excluded: C<@>, C<%>, +and C, for instance. Hyper operators are also excluded, but +post-assigment forms such as C is allowed.) "...are allowed". // masak
YAPC::NA Synopsis Hackathon
I have proposed a synopsis edit hackathon subproject at YAPC::NA. read my ideas at: http://yapcchicago.org/wiki/index.cgi?SynopsisEdit feel free to edit and add your own comments. thanx, uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
