Re: RFD: Built-in testing
Hi
I assume that BDD(Behavior Driven Development) and the vocabulary that
it implies is not a good choice
at this stage ?
:describe("");
$x.should be(1e5) :it("");
and that a module based on the core testing facilities can be built if
someone feels like to.
Well, the vocabulary that it implies is really nice anyway if it can be
of any inspiration^^
http://www.oreillynet.com/pub/a/ruby/2007/08/09/behavior-driven-development-using-ruby-part-1.html
Re: Bite-sized Tasks for the Interested (was Re: Standards bearers)
ispyhumanfly wrote: Hello list, I've created a group on www.hiveminder.org for Perl6 collaborative task tracking and management. I've done some thinking and I've come up with a way in which I would like to maintain this group, its organizers and its members. Organizers ( moderators ) - A group organizer ( much like myself ) has the ability to add tasks to the 'up for grabs' section. This is where all Perl6 related tasks should be placed first, since they have yet to be assigned. An organizer is able to check and see the status of who/what is going on with a certain task that has been assigned to a group 'member'. I believe a group organizer also has the ability to appoint tasks to group members. Members ( our community hackers ) - A group member is an individual who can freely login ( once an invite has been sent to them ), check to see what's 'up for grabs' and self assign a given task to him/herself. These tasks can be monitored by the group organizer(s). [ a call for organizers ] Ok, so here is what I need. I would like a few key individuals ( namely those in a position to make decisions regarding what is/is not a task for Perl6 related development ) to get involved as group organizers. This way key individuals who know what is going on with the group and what needs to be done next are able to post those tasks in the 'up for grabs' section. [ a call for members ] For those of you who are planning on contributing your time and code, a response to me off list would be greatly appreciated. This way I can send you all invites through hiveminder and we'll be well on our way to better Perl6 task organization. >> end note... Any questions? :) Where is the feed? I think that my programming competences are not going to help anyone (unless you want crappy things^^;) I would like to know if there is an on going translation of the doc? If there are 'official' tutorials - translations ? -- シリル・デュモン（Cyrille Dumont） [EMAIL PROTECTED] our work is the portrait of ourselves tel: 03-5690-0230 fax: 03-5690-7366 http://www.comquest.co.jp
Re: perl 6 and web open source projects
herbert breunung wrote: Mark J. Reed wrote: I do think It Would Be Nice If there were a native Perl6 DRY/MVC/OMG/WTF/BBQ webapp dev framework ready to go (go where? into a webapp-oriented P6 distro, natch) around the same time that the lang itself is done. I imagine a port of Catalyst would fit the bill nicely. As far as i remember sri intended to be the next big version number of catalyst a p6 port and prepared some things for it, but as we all know sri is no longer the boss there. h If you look at the modules these frameworks use, you will see that some of them are always the same: DBI for DB access Cache::Cache for caching CGI (and CGI::Fast) well... TT, Mason for templates CGI::Session for persistence Most of them incorporate Dates, XML JSON Localization tools Images PDF ... I don't list the ORM tools as they are too numerous and none seems to stand out. I guess that all these frameworks tend to respond to needs that perl alone do not handle and doesn't offer : interoperability. Abstracting the module but keeping the final aim is a good way to see what todays web app needs. Old is the time when you could say : write a quick and dirty cgi to send an email. perl6 can be the kernel from which you built upon, Red hat, Fedora... like idea. this kernel is in itself within an other one that gives the global context I guess this make too much things to resolve. unless some very common needed features are to some extends recommanded as a 'should be' and not even a 'must be', the TMTOWTDI could lead to an unfortunate end. -- シリル・デュモン（Cyrille Dumont） [EMAIL PROTECTED] our work is the portrait of ourselves tel: 03-5690-0230 fax: 03-5690-7366 http://www.comquest.co.j
Re: Switch/Given and English, Was perl 6 grammar
Richard Hainsworth wrote: I don't know why, this given... when sounds so 'English' without really being that English. The construct sounds better in English than ... case ...> because: a) Switch is more commonly used in English as a noun, eg., Use the switch to turn on the light. But because English can use nouns for verbs and adjectives as well, eg., 'Switch on the light' or 'he is a switched-on type of guy', it seems ok to use it in for control purposes. Except ... the verb is really 'switch on' not 'switch'. Also we have 'switch over', 'switch from', 'switch between' etc. where as 'switch' as a verb as in 'she just switched boyfriends' means exchanging one for another, not choosing between alternative cases. So really 'switch' as a verb is really more like 'toggle'. So when an English person (or at least one that cares about the use of language) sees 'switch' in a programming language, there is the feeling that something is missing, or not quite right. And there is absolutely no linguistic link between 'switch' and 'case'. If I am uncomfortable with 'switch', 'case' really sucks. In fact, whenever I work in language other than perl, and 'switch' is the preferred construct, I always have to check the syntax to work out what goes where. b) 'Given' is more commonly used in English as a verb form. 'He was given an award'. Also, it is in the correct form for use at the beginning of a sentence, eg., 'Given three choices, he chose the most profitable'. So we have something that looks and feels like it is a part of normal English speech. The 'when' part is also a natural tag in English indicating one of several alternatives. 'Given' can be used as noun (the power of English! as a language) as in 'we have a number of givens, but the issue is still unresolved'. This is much rarer than the use of 'given' in verb uses. c) You might ask, why bother? Just choose words, and since switch is the most common one, just use it. Well, computers dont care whether you use words or symbols, so long as semantics can be uniquely extracted from syntax, that is, the computer knows uniquely what you are trying to say to it. But the reality is that humans dont work that way. From the time of FORTRAN and COBOL, the aim has been to choose words over symbols so that they have semantic meaning for the programmer. It makes it easier for programmers to write descriptions of algorithms and operations, and to understand the logic of the descriptions they are writing. This reduces development and debugging time. Perl has been so successful, and my programming language of choice, because where words have been chosen, they have very similar semantics to normal English. That helps me in my programming. I've never said that switch ... case was better than given ... when or that switch ... case was even a good construct. I have said that given ... when sounds weird as a construct (not mentionning the use of past participle and on top of that of an irregular verb). I understand the meaning and I can get over it but is proliferation of English idioms, words a good idea? There're bunch of words that could describe the same idea in a sligtly different manner. Perhaps writting a la smallTalk could be the solution. getting rid off all shortcuts and change them into explicit description entities and write english sentences, not programs. This could be nice but I will first have to learn English. Anyway, I will write my own 'Lingua::Given::Francais' with avec ... lorsque^^: (well, if I can - ^^; xx 1000 ) -- シリル・デュモン（Cyrille Dumont） [EMAIL PROTECTED] our work is the portrait of ourselves tel: 03-5690-0230 fax: 03-5690-7366 http://www.comquest.co.jp
Re: Standards bearers (was "Re: xml and perl 6")
Larry Wall wrote: Now, it might well be that a Perl standards body could specify a mininum suggested set of modules for any distribution to enhance interoperability, but we haven't got to that point yet, I don't think. This would be great though!! Even if it is afterward, it is still a lot better than nothing! perl6 offers a lot of new nice features in the grammar itself, but the lack of standards over than those of programming 'best practices' could be a problem. When I started to learn perl5, I have read (and am still reading because I am far to be a good programmer^^;!), a lot of books, online tutorials but none of them were doing it the same way! And I am still trying to get it! (What I liked though it is that I have learnt of lot more than other languages!) I guess perl6 is a solution to this problem thanks to the grammar itself. This is great, I think. But the above concerns regarding standards modules are a real issue too it should not be underestimated. Anyway, that's the reasoning behind supplying as little as possible with the P6 kernel. We don't want anyone mistaking it for a distribution in the first place, nor do we want us language lawyers to evolve into any kind of "official distribution board". Central planning doesn't scale over the long term. We should restrict our "federal" activities to those that help all the "states" get along with each other, at least well enough to avoid a civil war. Of course, as the U.S. proved at the beginning, when you fear a strong federal government it's possible to invent too weak a federal government. There's a balance in there somewhere that we're still trying to figure out... Larry -- シリル・デュモン（Cyrille Dumont） [EMAIL PROTECTED] our work is the portrait of ourselves tel: 03-5690-0230 fax: 03-5690-7366 http://www.comquest.co.jp
Re: ***SPAM*** Re: perl 6 grammar
Miroslav Silovic wrote:
>cdumont wrote:
>
>
>>In japanese it could even be :
>>
>>wa {
>> '' no baai ni { ... }
>>}
>>
>>Getting rid off the thema or I guess here taking $_ as the default.
>>
>>is this possible :
>>
>>given $operator {
>>'' {}
>>'' {}
>>}
>>
>>?
>>
>>
>>
>>
>If Larry doesn't mind me elbowing into the conversation... The
>unmentioned detail here is that given and when are decoupled; they're
>not two keywords in the same construct. In other words, given can be
>used without when and when can be used inside any block.
>
>C only binds $_ and executes a block, it's kind of a single-shot
>C. So you can do this:
>
>given $long_expression_that_is_difficult_to_type_more_than_once {
>.trim;
>s:g///;
>.prettify;
>.indent;
>say $_;
>}
>
>And C simply matches the current $_ with its argument. So you can,
>for example, use it inside C or C:
>
>@encoded = map @list:{
>when 'black' { 1 }
>when 'white' { 2 }
>when /#(.*)/ { $<1> }
>}
>
>Miro
>
>
>
>
Thank you for the precision!
--
シリル・デュモン（Cyrille Dumont）
[EMAIL PROTECTED]
our work is the portrait of ourselves
tel: 03-5690-0230 fax: 03-5690-7366
http://www.comquest.co.j
Re: perl 6 grammar
Jonathan Lang wrote:
Another thing to note about given ... when: you don't have to use them
together. All that "given" does is to set $_ to the variable
provided; this can be used in a manner similar to "with" statements in
other languages. And "when" doesn't have to be inside a "given"
block, either: it can be used in any block that sets $_. For example:
for @list {
when *..^0 { say "$_ is negative" }
when 0 {say "$_ is zero" }
when 0^..* { say "$_ is positive" }
default { say "$_ is something else" }
}
or (I think):
method test ($value) {
setup();
when $value { doit() } #[smart-match the calling object $_ against $value.]
}
(Question: assuming that the above is valid, would breaking out of the
when block be the same as returning from the method? Or would it
qualify as an abnormal termination of the method?)
I was exactly thinking at the 'with' keyword for given.
Even if it is not exactly the same thing.
the construct for ... when sounds more natural to me
even if here it is with an array, could be :
for $operator {
'' {}
'' {}
default {}
}
but as Mr. Wall said,
2 different things, 2 idioms.
--
シリル・デュモン（Cyrille Dumont）
[EMAIL PROTECTED]
our work is the portrait of ourselves
tel: 03-5690-0230 fax: 03-5690-7366
http://www.comquest.co.j
Re: perl 6 and web open source projects
Darren Duncan wrote: At 2:51 PM +0900 12/4/07, cdumont wrote: Sorry. Where can I find a mailing list that is about Perl 6 in general then? Thank you. I would recommend that [EMAIL PROTECTED] is the best place to talk about these things, out of the official Perl 6 lists that I know of. -- Darren Duncan Thank you (^^;) Just ignore my messages about this topic, all. I will copy and paste it for this mailing list. -- シリル・デュモン（Cyrille Dumont） [EMAIL PROTECTED] our work is the portrait of ourselves tel: 03-5690-0230 fax: 03-5690-7366 http://www.comquest.co.j
Re: perl 6 and web open source projects
Trey Harris wrote: The very notions of "enterprise" use and "open source" use and "web" use are so amorphous that it is hard to imagine core language features that would foster or discourage them. A language is an ecosystem, and it's hard to argue that Perl has done poorly in any of the three; the fact that other languages may currently have more forward momentum reflects, as much as anything else, that Perl reached saturation in these areas many years ago. As for that point : in these areas many years ago. If other languages are now favoured for web development over Perl5 that is supposed to have reached saturation years ago, it means that it wasn't the optimum or even closed to be it. While perl6 is being implemented it is perhaps a good idea to evoluate perl 6 in regards to perl 5 at the language level but also cultural and environment level. I wanted to point out that offering an ecosystem, water, was perhaps good enough when perl went thru. But now, roads, high-way and plane are very common things in new languages. They do implement more than just a basic ecosystem. This offers coherence, standard and assurance that programm A will run in context Y and Z without having to rebuilt the road. For what I have seen, many people in this mailing list thinks that the ecosystem is good enough. But as somebody says in this mailing list, when you go buy a car you want everything in it. Not going in a, b,c ,d shops to get it to work. That's why open source projects favor php or ruby because the assurance the program will run in context is higher than in perl and it seems like it will in perl 6. So perhaps this shouldn't have to be discussed in a 'language' mailing list but I guess a language is built upon a certain context whether you want to hear about it or not. But don't get me wrong! I don't want to blame anything at all! I wanted to point out that CPAN was the sucess of perl. But C6PAN might be it failure. Like an other person said, having a web module, that will be part of the core documentation without even having to be in the core of perl 6 would be a very good solution. This will offer standard, assurance and allow wide spread use of perl 6 over predominant actual languages. In order to do so, the language has to take into account what are the most common actual needs and reflect them to some extends. French used to have many verbs and tricky grammar rules. It tends to disappear and in the same time English words, computer words are just getting in our everyday life more and more. Perhaps we won't be using them in 2 years but and so what? If we need them now. Don't you think this has to do with perl 6 language? now,now,now,it's all about now. as said Jeff Buckley... But this might not be the place and I will stop here. Thank you anyway for your kind reply. -- シリル・デュモン（Cyrille Dumont） [EMAIL PROTECTED] our work is the portrait of ourselves tel: 03-5690-0230 fax: 03-5690-7366 http://www.comquest.co.j
Re: perl 6 and web open source projects
Trey Harris wrote: In a message dated Tue, 4 Dec 2007, cdumont writes: oh, it might not be relevant in many ways but : http://iamseb.com/seb/2007/12/perl-on-rails-why-the-bbc-fails-at-the-internet/ http://www.bbc.co.uk/blogs/radiolabs/2007/11/perl_on_rails.shtml There's one thing I would like perl6 to shine in, is web and open source. I know it's not the purpose of the language and that the above articles are placed in a particular context but I guess this can explain to some extends why both perl don't have a widespread use in entreprise and in open source project (I have looked for them but they are little and some of them like movable type moves to php at each upgrade) May I divert from where this discussion would clearly go if your comment were directly responded to (into a massive flame-fest, that is) just to point out that this is not the purpose of the p6-l@ list? This list is to discuss the Perl 6 core language. The very notions of "enterprise" use and "open source" use and "web" use are so amorphous that it is hard to imagine core language features that would foster or discourage them. A language is an ecosystem, and it's hard to argue that Perl has done poorly in any of the three; the fact that other languages may currently have more forward momentum reflects, as much as anything else, that Perl reached saturation in these areas many years ago. If you want to make specific recommendations with regards to the language Perl 6, go ahead. But a free-for-all on Perl's successes and failures in particular arenas is not what this list is for. Trey Sorry. Where can I find a mailing list that is about Perl 6 in general then? Thank you. -- シリル・デュモン（Cyrille Dumont） [EMAIL PROTECTED] our work is the portrait of ourselves tel: 03-5690-0230 fax: 03-5690-7366 http://www.comquest.co.j
perl 6 and web open source projects
oh, it might not be relevant in many ways but : http://iamseb.com/seb/2007/12/perl-on-rails-why-the-bbc-fails-at-the-internet/ http://www.bbc.co.uk/blogs/radiolabs/2007/11/perl_on_rails.shtml There's one thing I would like perl6 to shine in, is web and open source. I know it's not the purpose of the language and that the above articles are placed in a particular context but I guess this can explain to some extends why both perl don't have a widespread use in entreprise and in open source project (I have looked for them but they are little and some of them like movable type moves to php at each upgrade) cdumont wrote: Patrick R. Michaud wrote: On Mon, Dec 03, 2007 at 12:20:02PM +, Smylers wrote: cdumont writes: I don't really think using the column in a ternary means that you cannot use it else where. We started off with that, and it was changed specifically because it was causing a problem; I can't remember exactly what, but it's in this list's archives somewhere. Remember that whatever expression you want to use the colon for is going to be valid between the ? and : parts of the ? ... : operator, and so you need to avoid the colon being confused for the : which marks the end of this part of the ? ... : operator. ...and it's not just the colon, but the ? also has the potential to be confusing here, because there's a prefix: operator that is used to coerce into boolean context. Which indirectly gets around to an even stronger reason for using C over C -- Perl 6 aims for a consistency in the use of the ? and ! characters to mean "boolean true" and "boolean not true". This is true not only for the operators, but also in regular expressions and other places. So, having something like $foo = $cond ?? ...if_true... !! ...if_not_true... ; achieves several important goals: - it frees up the ? and : characters for other purposes - it reinforces the convention of ? as "if true" and ! as "if false" - it is more visually distinctive, so that the ternary tokens don't get lost in the middle of other operands and expressions - it simplifies parsing (both compiler and human) and improves error reporting In my case, I've found the switch to ?? !! to be fairly natural, and that I don't use it often enough to worry about the extra characters. OK that explains the logic behind the conclusion. Thank you! I don't use it that much either but it was for the sake of coherence with other languages but Mr. Wall got the point in his response! -- シリル・デュモン（Cyrille Dumont） [EMAIL PROTECTED] our work is the portrait of ourselves tel: 03-5690-0230 fax: 03-5690-7366 http://www.comquest.co.j
Re: perl 6 grammar
Larry Wall wrote: >On Mon, Dec 03, 2007 at 07:30:53PM +0900, cdumont wrote: > > >>Moritz Lenz wrote: >> >> >> >>>cdumont wrote: >>> >>> >>> >>>>1- $str1 ~ $str2 >>>> >>>> >>>> >>>The '+' suggests numerical addition (and requires disambiguation in the >>>case of $str + $number - should $str be interpreted as a number, or >>>$number as a string?). >>> >>>The . is already taken by method calls (used far more often), and is >>>easy to overlook when concatenating strings. >>> >>> >>> >>Yeah, that's what I thought about the use of the dot for hashes and objects >>but hash or object : >> >>$obj.method(); >>or >>%hash.value(); >> >>which is visually different from : >> >>$str.$str2 >> >>as the concatenation keeps the sigil. >> >>I am not a huge fan of the + operator either but >>well, why add a third type when the dot could be just fine ? >> >> > >Because it wouldn't be just fine. Even in Perl 5 we have $obj->$method, >so if you're going to allow indirect methods and use . for method calls, >$a.$b has to be an indirect method call, not a concatenation. > > Oh! True! But ~... it's not has easy to type as '.' and not really visually nice (even if outstanding) >In general, one of the design principles of Perl 6 is that we never >overload operators to do very different things, because even if we can >think of a way to finesse it right now, it has a negative impact on >both extensibility and readability. It impacts extensibility because >you leave yourself no "wiggle room" in the grammar for future changes. >It impacts readability because you have to stop to consider the context >to decide which operation is going to happen. > >This is why Perl 5's x is now split into x and xx, for instance. Though >Perl 5 got some things right, by this principle. We never made the >mistake of confusing addition with concatenation. Not only is >concatenation not numeric, it's not even commutative! > > > >>2 ways are already more than one. >> >> > >If you're doing 3 very different things, then doing it 2 ways is >suboptimal. Things that are different should look different. > >Also, keeping operators in 1::1 correspondence with operations gives the >optimizer the most chance to figure things out at compile time without >having to know types at run time. (An oversimplicifcation, I know, >especially given how Perl 6 does multiple dispatch on operators at >run time.) > >Nevertheless, most of the overloading of operators historically has >been to avoid using up the ASCII sequences, and now that we allow >users to define Unicode operators, that artificial pressure has mostly >been removed. > >That being said, there's still contention for the short ASCII >sequences, and you shouldn't assume that any Perl 6 operator is >what it is for a single reason. Generally, most of these operators >have four or five reasons for being what they are, and some of those >reasons relate to what has already been taken by other more important >operators. Plus there is consistency with the rest of the language, >where ~ generally indicates some kind of string operation. > > > I guess there's a need to write some long programs in order to see. >>>>2- $life = (!$monster) ?? 'safe' !! 'dead'; >>>> >>>> >>>> >>>is it true??? really??? then you're safe. if not (! is not), you're >>>dead. PWND. >>> >>>Again I think that a visually outstanding operator simplifies reading. >>>It's really easy to overlook a single ':', as it's used in p5. >>> >>> >>> >>> >>You are right, that is outstanding but again, so many languages use >>a standard ? : >> >> > >Languages copy all sorts of suboptimal features from other languages. >After all, that's how Perl 1 got ?: from C. That doesn't make it >right or wrong, merely convenient to learn. Learnability has always >been a secondary goal in Perl 5, compared to expressiveness, which is >a primary goal. > >When a language is first starting out, it *must* copy a lot of bad >constructs from other languages, or it will not easily be accepted (see >Icon for a sad example of this). With the wide acceptance of Perl 5, >we have the opportunity to use that as a cultural basis for change. >It
Re: perl 6 grammar
Patrick R. Michaud wrote: On Mon, Dec 03, 2007 at 12:20:02PM +, Smylers wrote: cdumont writes: I don't really think using the column in a ternary means that you cannot use it else where. We started off with that, and it was changed specifically because it was causing a problem; I can't remember exactly what, but it's in this list's archives somewhere. Remember that whatever expression you want to use the colon for is going to be valid between the ? and : parts of the ? ... : operator, and so you need to avoid the colon being confused for the : which marks the end of this part of the ? ... : operator. ...and it's not just the colon, but the ? also has the potential to be confusing here, because there's a prefix: operator that is used to coerce into boolean context. Which indirectly gets around to an even stronger reason for using C over C -- Perl 6 aims for a consistency in the use of the ? and ! characters to mean "boolean true" and "boolean not true". This is true not only for the operators, but also in regular expressions and other places. So, having something like $foo = $cond ?? ...if_true... !! ...if_not_true... ; achieves several important goals: - it frees up the ? and : characters for other purposes - it reinforces the convention of ? as "if true" and ! as "if false" - it is more visually distinctive, so that the ternary tokens don't get lost in the middle of other operands and expressions - it simplifies parsing (both compiler and human) and improves error reporting In my case, I've found the switch to ?? !! to be fairly natural, and that I don't use it often enough to worry about the extra characters. OK that explains the logic behind the conclusion. Thank you! I don't use it that much either but it was for the sake of coherence with other languages but Mr. Wall got the point in his response! -- シリル・デュモン（Cyrille Dumont） [EMAIL PROTECTED] our work is the portrait of ourselves tel: 03-5690-0230 fax: 03-5690-7366 http://www.comquest.co.j
Re: perl 6 grammar
Smylers wrote: cdumont writes: Smylers wrote: cdumont writes: The given ... when doesn't seem to bring that much from switch ... case given ... Surely it brings all of it? Plus much more as well. Much of the power is in the smart-matching, which enables many different sorts of comparisions, each naturally matching the appropriate thing. A big advantage given has over C's switch construct is not having to include break in the usual case (and get mysterious-yet-silent bugs if you accidentally forget it). I understand that given ... when is even more powerful than a simple switch case but why just don't say it this way : this is a switch case dopped with hyper process Maybe the documentation will say it that way! Well, hope so... if we could talk about the doc too... and keep the old switch ... case keywords. But "keeping" the "old" ones would require having them already -- which Perl doesn't. What would be the point in simultaneously introducing a flexible syntax which meets all switching needs and a less-powerful syntax (which is completely different, thereby making it more work than necessary if you outgrow its requirements and need to change to using the more flexible alternative; and which is error-prone)? I am sorry, I meant : keep the old school switch ... case keywords that we inherited from other languages. I don't think the syntax should be the same exactly. I just want to avoid having to learn or expose people that are not native English speakers to too many keywords. I don't know why, this given... when sounds so 'English' without really being that English. I'm afraid you've lost me -- are you saying that given does sound English or that it doesn't? And why is it relevant either way? See above. And hashes require '=> ' but it could be nice to switch to ':' Indeed it could be. But, unfortunately, the colon seemed to be top of many people's most-wanted lists, with many different (and mutex) suggestions for what it should do. (Remember, only a couple of paragraphs ago you were wanting to keep it for the ? ... : operator!) Possibly somebody could design a language in which the colon is the only symbol used ... I don't really think using the column in a ternary means that you cannot use it else where. We started off with that, and it was changed specifically because it was causing a problem; I can't remember exactly what, but it's in this list's archives somewhere. Remember that whatever expression you want to use the colon for is going to be valid between the ? and : parts of the ? ... : operator, and so you need to avoid the colon being confused for the : which marks the end of this part of the ? ... : operator. Also remember that we want Perl 6 to be able to complain about syntax errors -- that is, we want that when somebody makes a typo, there's a good chance of perl complaining about the source being invalid, rather than it being valid Perl 6 (but which silently does something else). I can understand the idea. As for the functions, i didn't see that much for hashes and arrays which was a big disappointment. What were you hoping for? Many things which were functions in Perl 5 are now also available as methods in Perl 6. If you post here with what you're disappointed to be missing, it may be that somebody can reply pointing out where the equivalent functionality is! I am pretty much sure that I can rebuilt all the functions I will need for intersections and the like. But instead of reinventing the wheel or having to DL a module, it could be nice to have it as a built in. They are also other string related functions that are required when dealing with web but I guess this is not in the scope of perl anyway. Smylers -- シリル・デュモン（Cyrille Dumont） [EMAIL PROTECTED] our work is the portrait of ourselves tel: 03-5690-0230 fax: 03-5690-7366 http://www.comquest.co.j
Re: perl 6 grammar
Smylers wrote:
cdumont writes:
there are some changes in the grammar which benefits aren't that
obvious :
Hi there. For some of these the benefit is indirect: it isn't that it
makes the feature in question easier to use; instead it enables _other_
features.
1- $str1 ~ $str2
I do not really understand the new concatenation style when most of
the time it's '+' or '.'
It isn't great, but I'm sure we can live with it. It frees up dot for
other things. Anyway, because of interpolation Perl doesn't use
concatenation as much as many other langauges (and even less so in Perl
6 with method calls being interpolatable and braces for conveniently
interpolating any code at all).
It also has the advantage that tilde is consistently used in several
places in Perl 6 to indicate strings.
2- $life = (!$monster) ?? 'safe' !! 'dead';
I don't see how putting 2 questions marks and 2 exclamations marks
make things shorter and easier to understand.
Clearly it doesn't -- but then I don't think anybody is claiming that
that's the reason for the change!
Shortness isn't always a virtue; by using doubled characters they stand
out more, which makes it easier to spot when this operator is being used
-- something that's more important with this operator than most, since
it is split between two positions.
And it frees up some symbols for use in other operators.
I think I can live with the ?? !! thing but ~...
3- given $operator {
when '' {}
}
The given ... when doesn't seem to bring that much from switch ...
case given ...
Surely it brings all of it? Plus much more as well. Much of the power
is in the smart-matching, which enables many different sorts of
comparisions, each naturally matching the appropriate thing. A big
advantage given has over C's switch construct is not having to include
break in the usual case (and get mysterious-yet-silent bugs if you
accidentally forget it).
I understand that given ... when is even more powerful than a simple
switch case
but why just don't say it this way : this is a switch case dopped with
hyper process and
keep the old switch ... case keywords.
I don't know why, this given... when sounds so 'English' without really
being that
English.
And hashes require '=>' but it could be nice to switch to ':'
Indeed it could be. But, unfortunately, the colon seemed to be top of
many people's most-wanted lists, with many different (and mutex)
suggestions for what it should do. (Remember, only a couple of
paragraphs ago you were wanting to keep it for the ? ... : operator!)
Possibly somebody could design a language in which the colon is the only
symbol used ...
I don't really think using the column in a ternary means that you cannot
use it
else where.
because then :(or perhaps we can use whatever separator we want?)
{
elems : {
deleting : {
ids : [1,2,3],
names : ['concatenation','ternary operator','switch']
},
replace : {
with : ['.','?:','switch...case']
}
};
And I know this may not sound that much but it could be sent to
javascript or actionscript or any ecmascript based languages.
The key bit of the above is your parentical comment about using whatever
separator you want -- which is exactly what Perl 6 provides the
flexibility to do. In Perl 6 it will be possible to do:
use Grammar::JSON;
and then within that file you can have the above syntax for complex
data-structures.
Or at least, it will if somebody writes the Grammar::JSON module -- but
the whole point of Perl 6's pluggable grammars is that it specifically
supports people who want to do this sort of thing: it recognizes that
not everybody is going to agree on the ideal syntax, so instead it
merely provides a 'default' syntax (which Larry judges to be the best
all-round) then provides a way of changing anything about it.
Hope that helps.
That's sweet !
But I wouldn't want to be most of the time on C6PAN downloading
grammars written in perl6 for perl6.
...
But being able to expand the perl6 grammar is a nice feature that
will be interesting as a learning process for me !
As for the functions, i didn't see that much for hashes and arrays which
was
a big disappointment.
Anyway, I think that perl6 has really nice features and I hope people are
going to use it a lot and that the community will be huge!!
The above points are the only things that kind of let me dubious.
Smylers
--
シリル・デュモン（Cyrille Dumont）
[EMAIL PROTECTED]
our work is the portrait of ourselves
tel: 03-5690-0230 fax: 03-5690-7366
http://www.comquest.co.j
Re: perl 6 grammar
Moritz Lenz wrote:
cdumont wrote:
1- $str1 ~ $str2
The '+' suggests numerical addition (and requires disambiguation in the
case of $str + $number - should $str be interpreted as a number, or
$number as a string?).
The . is already taken by method calls (used far more often), and is
easy to overlook when concatenating strings.
Yeah, that's what I thought about the use of the dot for hashes and objects
but hash or object :
$obj.method();
or
%hash.value();
which is visually different from :
$str.$str2
as the concatenation keeps the sigil.
I am not a huge fan of the + operator either but
well, why add a third type when the dot could be just fine ?
2 ways are already more than one.
2- $life = (!$monster) ?? 'safe' !! 'dead';
is it true??? really??? then you're safe. if not (! is not), you're
dead. PWND.
Again I think that a visually outstanding operator simplifies reading.
It's really easy to overlook a single ':', as it's used in p5.
You are right, that is outstanding but again, so many languages use
a standard ? :
To make it outstand a little bit more :
$life = (!$monster) ?? 'safe' |(^0^;)| 'dead';
But might take some time to get acoustumed to it...(just kidding)
But if we want to choose the visibility key then
$*IN
is not what I will call something especially visual even if
it's not that awful (well, depending on the keyboard this can be a reall
pain though)
3- given $operator {
when '' {}
}
...
The given ... when doesn't seem to bring that much from switch ... case
given ... if would make a little bit more sense.
I don't know the rationale about that, but perhaps it's to distinguish
given-when (which uses smartmatching) from other languages that just do
string or number comparison.
I am not native so I do not really know either but I don't feel comfortable
with profusions of different keywords in languages...
why not a :
pour $operator {
lorsque '' {}
}
And hashes require '=>' but it could be nice to switch to ':'
because then :(or perhaps we can use whatever separator we want?)
There is a :key(value) pair notation already.
And I know this may not sound that much but it could be sent to
javascript or actionscript or any ecmascript based languages.
I don't think it's a good idea to write files that can be interpreted
either as Perl 6 or as javascript. Perhaps a nice idea for an
obfuscation, though.
No, the aim is not really to write files like ECMAScript but
a very simple example is querying the db
and send the object to javascript or actionscript with a remote call
or the other way round.
The closer the basic structure is, the less manipulation will be needed.
JSON (which should be renamed ESON) is growing these days
and making interactions between languages easier is not that bad.
I have written the example so that to show the internal structure
but could be nice to just do :
my $imageGalleries = new ImgLoader($path);
print "Content-type:text/json¥n¥n";
print Dumper($imageGalleries);
Then whatever the third part, they will be able to handle the object.
it is just a kind of standard serialization to keep persistence.
Last time i used perl to connect to a DB, get the result then send it
into the php serialization format to a php program placed in an other
server.(the framework was in php so...)
Now, just dumping the result and using the json_decode function could work
and for many other languages too.
But that's not a vital point but a nice feature to have.
Anyway, I hope perl6 is going to get out soon!
I didn't really got all the oop keywords but that shouldn't be that bad.
(any reference of functions include in perl6?)
S29:
http://perlcabal.org/syn/S29.html
Thank you!
Cheers,
Moritz
--
シリル・デュモン（Cyrille Dumont）
[EMAIL PROTECTED]
our work is the portrait of ourselves
tel: 03-5690-0230 fax: 03-5690-7366
http://www.comquest.co.j
perl 6 grammar
I found some of the perl 6 new features really neat:
- creating your own type
- type casting
- junctions
- multidispatch
- :r:w:a shortcuts
- hyper operators
- some kind of oop keywords
But there are some changes in the grammar which
benefits aren't that obvious :
1- $str1 ~ $str2
2- $life = (!$monster) ?? 'safe' !! 'dead';
3- given $operator {
when '' {}
}
I do not really understand the new concatenation
style when most of the time it's '+' or '.'
I don't see how putting 2 questions marks and 2 exclamations marks
make things shorter and easier to understand.
The given ... when doesn't seem to bring that much from switch ... case
given ... if would make a little bit more sense.
And hashes require '=>' but it could be nice to switch to ':'
because then :(or perhaps we can use whatever separator we want?)
{
elems : {
deleting : {
ids : [1,2,3],
names : ['concatenation','ternary operator','switch']
},
replace : {
with : ['.','?:','switch...case']
}
};
And I know this may not sound that much but it could be sent to
javascript or actionscript or any ecmascript based languages.
This discussion has certainly be done a long time ago
but give it a try.
(any reference of functions include in perl6?)
Re: xml and perl 6
>>A programming language is made by humans and subject to the same evolutions >>and bugs and in the end is alive and will die. >>A programming language should evoluate, try to respond quickly to the >>actual environment in order to survive or expand. >> >> > >Have you *seen* how much time p5p spends on keeping little-used modules that >someone successfully argued were absoutely vital to the future of Perl now >and forever up to date? > >If you want to talk about responding quickly to the environment, look at the >CPAN. > > Yeah, I know that cpan is responsive, I spend my time installing modules from cpan and it helps me a lot. even if perl goals and php goals aren't the same, php is very responsive too and don't hesitate to incorporate quickly PEAR modules if they are goods. Relying on modules has several drawbacks: - too much namespace, kills the namespace: use HiRes::Time::And::I:Cannot::remember::the::damn::namespace - C based modules cannot always be installed according to your environment - use the perl version of the module when you can and therefore slow down the app. - need this one module that has dependencies all over the place all dependencies are not necessary so you rewrite some of the modules to get rid off the dependencies where you can. in the end, I need to reinvente the wheel. - No coherence, that is for me the biggest drawback. (php is absolutely not coherent helas, but the doc!) I guess that this is the main problem. You need something that is not in the core, which in my case is about 95% of the time. So you look for modules in CPAN. After searching for the right namespace (sometime you think you have THE module but a better one is just hide in a place you couldn't think of...) you dive into the documentation and therefore in the API, UI of the module. Here comes the troubles... 5 modules, 5 API, 5 UI,5 docs, 5 universes... I am very grateful for all the people that contributes to CPAN and there is absolutely no need for them to follow any conventions but in the end? my $img = new AssetMediaFactory($path); my $asset=$img->loadAsset(); In that case we are lucky, the module use the same convention but you can have: my $img = new AMF($path); my $asset=$img->load_asset(); //or my $asset=$img->ldass(); And I am not talking about the implementation in the background using hahes, inside-out, modules that stimulate oop behaviors... The way they handle errors,etc... Some of them, rewriting functions that exist in other modules but don't want to get a dependency... And if you need to use the module in your framework and if you want to stay coherent with your framework, you wrap everything. Obviously, you have choosen the 100% perl module because you want to be sure you will be able to use the same module almost everywhere. all modules have their own particular universe, even if it is a well thought one, you have to immerse yourself into it and learning a mini-language everytime. The doc is obviously free of real conventions so you have to search for the info thru all the paragraphs to be sure not to loose something even if you don't need it. SO? Well, implementing modules in perl, getting rid off weird namespaces (not all but with just 26 letters, you can handle a human language so I guess a little thousand functions shouldn't be that a problem), making it fast, available, coherent with perl itself, perl documentation will save many troubles. Perl 6 could do without implementing the XML at a core level. But why not create an interface, directions but not implementation. Unfortunately, I deal with xml too (very helas!), json, raw data,images, sessions, server connections, Databases, pdfs, spreadsheets, url encoding... is implementing all of this in the core a good idea ? think not... But I guess you got the picture. I still think that a poll on the net could be a good idea. Because when somebody comes here and say : I would like to know if this is going to be implemented, what is the answer ? 'You need it. I don't' and then : 'I need it but you don't but I need it' ... A long time has passed since the apocalypses and exegeses. -- シリル・デュモン（Cyrille Dumont） [EMAIL PROTECTED] our work is the portrait of ourselves tel: 03-5690-0230 fax: 03-5690-7366 http://www.comquest.co.j
Re: xml and perl 6
I guess what should be in the core or not is not something that should not be debated here. In fact, perl 6 is supposed to be the *community language* so instead of saying 'I' use this one but don't use this one, so I don't see why it should be implemented into perl, the *community* should decide and unless I made a mistake nobody here can pretend representing the entire community. Internet is here, a huge online poll amongst a minimum number of programmers is a better way to go. perl can handle different fields, so the polls should be divided in order to get the better in each fields... That's true that it's not possible to be sure of how will look like our programming style, concepts in 10 or even 3 or 4 years. OOP is being implemented all over the place, and if it was the worst solution ever but that we just do not know better ? Regex is being reimplemented, does it mean that the first implementation sucked ? By listening to you all, we shouldn't even think to implement file access... A programming language is made by humans and subject to the same evolutions and bugs and in the end is alive and will die. A programming language should evoluate, try to respond quickly to the actual environment in order to survive or expand. It is good to make assumptions of what migth the future be for hours and hours and years and years. It might be better just to try and live.
Re: Web Module (Was: Perl6 new features)
Getting back to the Web Module, the following could help a lot if there were in the core or as a 'core' downloadable bundle : - DBI - ORM system - Caching system - Sessions (server side cookies) - XML parser - JSON parser I guess that it will be fair enough for actual web apps. templating system that could be hooked or using flex points, classes related to CRUD,scaffolding,input filtering, unit testing could be a plus but could sound more like a framework than a programming language^^; I've certainly forgotten many things but that's what came up at the moment.
Re: Perl6 new features
You should discuss that on p5p, not here. Only Perl 6 is on topic here. Sure, but I've started from perl doc 5.8 in order to say that it could be nice to have the features I'm talking about in perl6 so it's not out of the scope I guess. it seems to me that you already have this : in line of command you can use "perldoc -f split" to get the split() doc, where there are examples and return value and parameters are discussed at length, if you prefer a "modern" format, http://perldoc.perl.org/functions/split.html should content you, and you can use Pod::POM::Web to get a small HTTP server where all Perl doc (core and modules) can be browsed and searched, so what exactly are you speaking about ? As for the documentation, I've already watched this link and depending on the functions, informations are more or left complete. In the case of split there are quite few examples but it's not the case for a lot of documentations. http://perldoc.perl.org/functions/chop.html http://perldoc.perl.org/functions/lc.html You might say that it doesn't need more but Adding user comments within the doc could allow to get much more usefull examples and 'tips' from other programmers. not a full blown oop cpan module but just a useful adding, transforming, real word use of the function. http://perldoc.perl.org/functions/pack.html This is an other function well documented. But if in split, the result of the example is included below the code with a sentence such as 'produces...' here, it is a comment below the line, or 'gives...' There's no real common pattern to get in a glimpse the function use. A kind of standardisation could help. (what are the arguments names, i've just found : EXPR, VALUE, Y,X,VARIABLE,NUMBER,PLAINTEXT...) there is a standard but it's not very as evident as it could be. function parameters,flags function return : .success:... .failure:... Example : ... Output : ... Well i'm talking about the 5.8 but remember it's in order to know if there can be ways of improvement for perl6 doc. Moritz Lenz wrote: A: because it disrupts the natural way of thinking. Q: Why is top posting frowned upon? cdumont wrote: Perl 6 is not yet finished, so the the list of core modules is not yet specified. I know that it is somehow not the subject, but I think the actual 5.8 doc should be changed to some extents. You should discuss that on p5p, not here. Only Perl 6 is on topic here. Is there a place where we can add suggestions ? apart from the first one in... 2003 ? 4 years ago ? You can write them here on p6l. -- シリル・デュモン（Cyrille Dumont） [EMAIL PROTECTED] our work is the portrait of ourselves tel: 03-5690-0230 fax: 03-5690-7366 http://www.comquest.co.j
Re: Perl6 new features
Thank you for your kind reply ! Perl 6 is not yet finished, so the the list of core modules is not yet specified. I know that it is somehow not the subject, but I think the actual 5.8 doc should be changed to some extents. It could be nice if we could browse each core functions, having the function parameters, flags (not that much used right?), and the return value of the function, followed by exampleS AND so that it could be a lot richer, allow people to "comment"... I know this is not the point but it could be nice to do so for perl6 ! (I was thinking to create a kind of site like that for the actual perl, but my programming competences are,well... ) Perl 6 does. See for example ext/Set/ in the pugs repository. Glad to hear that ! You could help by contributing some suggestions to what the new "Web" module should be able to do, and how so. Web is hopefully "CGI done right", and still in its early planning stage. Web module is a good name. Is there a place where we can add suggestions ? apart from the first one in... 2003 ? 4 years ago ? Moritz Lenz wrote: cdumont wrote: I know that perl doesn't only focus on web apps and my question might seem irrelevant but I've been searching the web in order to find the new features of perl6 regarding new functions, core module lists (not perl grammar itself) but couldn't find any thing... Perl 6 is not yet finished, so the the list of core modules is not yet specified. I would like to develop web apps with perl too but having to download modules from CPAN every time makes me feel these apps will never be able to evoluate in different environments. (environments you don't have control of) That's a general problem with libraries, not only Perl ones. And you can't solve this by putting everything into core - it just blows up the distribution. I am a bit amazing to see that perl doesn't include a bunch a set theory functions too. Perl 6 does. See for example ext/Set/ in the pugs repository. And so does Perl 5: http://search.cpan.org/~samv/Set-Object-1.21/lib/Set/Object.pm I am not blaming perl but only hopes that perl6 will allow to make things easy for the programmer. That's one of the most important design goals ;-) as for the web, maintaining state thru server side cookies and DBI are the very minimum I would recommend. more hash and array functions a minimum too. if there are such things in perl6, I'll be very happy to work with this language ! You could help by contributing some suggestions to what the new "Web" module should be able to do, and how so. Web is hopefully "CGI done right", and still in its early planning stage. Cheers, Moritz -- シリル・デュモン（Cyrille Dumont） [EMAIL PROTECTED] our work is the portrait of ourselves tel: 03-5690-0230 fax: 03-5690-7366 http://www.comquest.co.j
Perl6 new features
Hi everyone, I am working with perl 5.8 at the moment after developping web apps in PHP. I know that perl doesn't only focus on web apps and my question might seem irrelevant but I've been searching the web in order to find the new features of perl6 regarding new functions, core module lists (not perl grammar itself) but couldn't find any thing... I would like to develop web apps with perl too but having to download modules from CPAN every time makes me feel these apps will never be able to evoluate in different environments. (environments you don't have control of) I am a bit amazing to see that perl doesn't include a bunch a set theory functions too. Instead, need to reinvent the wheel making things easy possible and hard things unconvenient. I am not blaming perl but only hopes that perl6 will allow to make things easy for the programmer. as for the web, maintaining state thru server side cookies and DBI are the very minimum I would recommend. more hash and array functions a minimum too. if there are such things in perl6, I'll be very happy to work with this language ! I may not know enough about perl and my 'complain' might be absolutely unfounded. I know this is an open source language and that people are busy and if the answer is "DIY !" I'll pass my way^^; Anyway, this is an outside view from 2007 hoping to help perl6 becoming popular amongst people.
