Re: RFD: Built-in testing

[Fagyal Csongor]

Hi,

I pretty much like this idea. Very perl6ish :)

- I don't think it's important whether it is called :ok, :OK or :test or 
:wellhowdidthatworkout. I assume people who will be testing their 
modules/code/etc. will be using more advanced modules for testing 
anyway. This is for testing the implementation against the specs, and 
they *will* know how it works :)


- I don't think we should be concerned whether to implement :ok is 
difficult. Implementations in early stage are totally broken anyway :), 
they won't even *parse* the tests well - they will have have their own, 
limited tests. Later they can chose to do some magic to make :ok work... 
and finally implement it.


- I like "ok" better than "test", as the former kind of implies a 
boolean "was that true?" to me. YMMV, though.


- Fagzal

Re: pluralization idea that keeps bugging me

[Fagyal Csongor]

Hi,

Warnocked!

Indeed :)
I posted an idea about pluralisation could be handled in a way that 
would not be English-centric (Subject: interpolation 
contextualisation). There were no responses to the idea. Was it so 
bad? Did no one see it? Was it too un-perlish? Was the title too 
horrible?


The basic idea would be to add hooks into interpolation to allow for 
context suppliers and context sensors. The context sensors change 
words depending on data supplied through context suppliers.


Note that even in English, if you change a noun from singular to 
plural, you need to change the verb from singular form to plural form.
First of all, I think a module like this should be either perfect or not 
exist at all: you won't use it after it makes the first mistake, or when 
you cannot use it everywhere.
Now, to have a perfect module you need some pretty smart people to 
create the base lib (dealing with natural languages is not a piece of 
cake). Then you need a bunch of other people who understand what's going 
on to to create and test the different language versions. I fear that at 
the end you end up with a huge codebase, created by various people, 
parts of which get out-of-sync or become unmaintained, and which 
generally consumes a lot of memory (think about e.g. dictionaries for 
irregular words - take a look at Lingua::EN::Inflect, for example) when 
used, and also slows down execution. All this to save one 
not-very-often-used "if... else" block. If we really want to help people 
type less, why not just rename "else" to "e" ? :)


It also seems to me that I will need a module like this when my computer 
does not only *ask* where I want to go today, but also *cares*. ;)


So IMHO while it's a nice idea, it's just an overkill. (And it's 
definitely not about Perl6 as a language.)


- Fagzal

Re: pluralization idea that keeps bugging me

[Fagyal Csongor]

Amir E. Aharoni wrote:

On 26/01/2008, Larry Wall <[EMAIL PROTECTED]> wrote:
  

After a recent exchange on PerlMonks about join, I've been thinking
about the problem of pluralization in interpolated strings, where we
get things like:

say "Received $m message{ 1==$m ?? '' !! 's' }."

...

Any other cute ideas?



No matter what you do it will remain too English-centric. It might
work for Catalan, too. But it will remain totally useless for Arabic
or Chinese.

In any case, i don't understand why should this be in the core language at all.

I second that.

A few more thoughts:

1. For example in Hungarian, you don't need this at all: the noun stays 
singular after the numeral.


2. AFAIK in some languages it's not "1 ore more", but "1, 2 or more".

3. It's often not "1 or more" what you need, but "none, 1 ore more". "No 
new messages - You have 1 new message - You have 3 new messages." Or 
more likely "Now new messages. - You have 1 
new message. ..." etc.


4. I work a lot with multilingual websites. I have learned long ago that 
it's never "{{you_have}} [% messages %] {{messages}}." You have to be 
*very* lucky just to make this work in two languages. Instead, it's 
"{{number_of_new_messages}}: [% messages %]." That pretty much works 
everywhere.



So not in the core, probably. There are too many exceptions. A module 
would be cool, though :) String::Plural::English, or whatnot.




- Fagzal

Re: proposal: 404 method

[Fagyal Csongor]

András,

I think you have just discovered AUTOLOAD :-)

OTOH I don't know how the AUTOLOAD mechanism will work in Perl6 compared 
to Perl5, or if it has been imlemented in Pugs (yet), but as far as I 
remember, in Apocalypse 12 somewhere it says it will work the same(?) as 
in Perl5, and what you have described works in Perl5 (if I understood 
you correctly, which might not be the case).


- Fagzal


Hi,

Is there a way, to catch, if I call a method, that doesn't exists, to 
run a default one? I'm thinking about an "error handler" method. If 
not, I would like to propose this:


class MyClass {
method example ($self: $var) {
say "HELLO";
}
method default ($self: $method_name, %parameters)
is method_not_found {
say "$method_name called";
}
}

$mc = new MyClass;
$mc.example("var")
$mc.helloworld("var", "var");

--

and it outputs:

HELLO
helloworld called

The above is maybe not the best (and not the most valid) syntax for my 
proposal, but I think you can get the idea. It would be very useful 
the hide parameters into the method name, like this:


 save_the_world();
 save_the_captain();

And the default method will match the method name with 
/^save_the_(.*)$/, and saves $1.


I hope, you will like it. As I know, it's not possible currently.

Bye,
  Andras

Re: new mailing list: perl6-general?

[Fagyal Csongor]

Hi,


Hi,

I think, that David's version is matches with my opinion. I don't 
think, that "beginners" would be a better name for it, but maybe more 
practical, as it's a more evident name.


Hmmm, I think "beginner" is a little negative. What about professional 
Perl5 programmers, who wish to learn Perl6? Wouldn't like the name :-))


How about 'perl6-usage',  'perl6-programming' or... hmmm, simply 'perl6'?

- Fagzal

Re: new mailing list: perl6-general?

[Fagyal Csongor]

Hi,

Just wanted to say the same. All my questions starting as "How to..." 
and "Is this..." are just to trivial to ask here :)


OTOH as there is no "global" Perl5 list (AFAIK, at least), these things 
should go to the "regional" mail-lists - later on. However, at this 
phase of develpment of Perl6/Pugs/Parrot/Andtherest, we would just 
overload those who are not (yet) interested in Perl6 with a continuous 
fear of getting Warnocked ;)


Andras++

- Fagzal


Hi,

I would have some general Perl6 programming questions. Where should I 
ask them? It's not about language design, not about 
compiling/compilers and even not related to the internals.


As more and more people will start hacking Perl6, I think, that it 
would be useful to having a list for this.


In this particular case, I would like to ask about creating a 
langugage construct (maybe there's a desgin pattern for it, maybe not) 
for a web templating system can be expanded by the user.


Bye,
  Andras

Re: What the heck is... wrong with Parrot development?

[Fagyal Csongor]

Larry,


On Mon, Jun 06, 2005 at 04:31:01PM +0200, anonymous coward wrote:
: It's a funny old world...
: wrote Dan Sugalski on June 04, 2005 in his Squawks of the Parrot blog.
: Go and see: .
: 
: Hence the subject.
: 
: What the heck is wrong with Parrot development?


I can't comment on aspects I am in all likelihood blind to, but I'll
be glad to point out that one of the most *irritating* problems
is people who snipe from the sidelines without having earned the
right to do so by contributing.  Dan has earned the right to carp,
and deserves our respect for refusing to vent (much) in public, but
anonymous cowards are generally just interested in making trouble
without being held accountable.  Feel free to prove otherwise.
 

With all respect, I think this is a very important thing which needs 
attention, and I hope that you will help us to clarify the situation. I 
am pretty sure Dan did not leave because he had a bad day - we know he 
is a much more serious person. I also think that the community does not 
ask you to tell us what is happening - your mind is worth more than that 
to us :-) However, it is vital to know if there were issues that should 
worry us. I hope someone will come forth and talk about these underlying 
problems most of us do not know about - and then your role, if you 
accepted it, could be to tell us if that brave person is authentic or not.


Of course it would be best if this person were Dan himself, but I (hope 
that I) understand his motives, so if he choses not to tell, let it be 
that way, he has indeed earned the right do do so. I know noone asked 
*my* opinion, and obviously I have no right to make any waves  here, but 
what I can say is if there were personal problems that led to this 
parting - I mean the "anonymous cowards" you mentioned -, while that is 
*very-very* bad and sad, it still sounds better to me than, say, knowing 
that Parrot development might fall into the hands of those who will 
scr*w it up. Apart from the tremendous amount of work and enthusiasm 
that went into creating Perl6/Pugs/Parrot, business decisions will be 
(if not are being) made on the (predicted) success of Perl6.


I have many things to worry about - it goes with working in IT. Please 
someone let me know if there is one more unpredictable thing in the 
future or not :-)


- Fagzal

Re: ./method

[Fagyal Csongor]

Abhijit Mahabal wrote:
(Note that "./" and "../" are prefix operators, and unlike ".?", ".*",
".+" and ".=", cannot be used infix. In fact, it requires that "?", "*",
"+" and "=" be thought of as meta-operators to ".", and from now on, to
"./" and "../" as well, so you get "./+method". This isn't as complex as
it looks right now.)
Your opinions please! (I ask those who already responded off-list, to
repeat their opinion here)

Since new syntax is being suggested for these things, here is my 
suggestion, very late in the discussion, but here it is anyway.

$_ is the topic; the "only" problem is that we have two topics here: 
an immediate and a "main" topic. What if a method call binds the 
invocant to *both* $_ and the "bigger topic" $__?

method foo($x){
# invocant accessible by both $__ and $_
for (1..3) {
# invocant accessible by $__ only
.bar(); # called on $_
$__.bat(); # called on the invocant
$?CLASS.bas();
}
}
I like this because things still look a little like a topic. This is 
not better than $o/$O, except that $__ looks more like $_ (but maybe 
it looks too much like $_, and that alone could invalidate this 
proposal).
Yep. I'd hate it to move the cursor every time on __ to see if it is _ 
or __. I have bad eyes and a small monitor :-)

This view won't be popular, but I'd prefer all these "built-ins" look 
like $_SOMETHING, like
$_, $_SELF, $_CLASS and so on...  even $_ to be an alias to $_TOPIC .

- Fagzal

Re: ./method

[Fagyal Csongor]

I also like this notation.
However, as a side note, let me voice the opinion that the "bad 
reputation" of Perl partially comes from the fact that it often looks 
like line noise. I think everybody know this. Now there has been a lot 
of discussion on finding different meanings for any two-character 
combinations of ^/[EMAIL PROTECTED]&~{}\ (I am sorry to say it that way). As a 
Perl programmer I like this, but I am afraid that other programmers of 
different languages ("...who will burn in Hell..." :-)), or newcommers 
to Perl6 will have trouble even to pick up the basics. But again, this 
is just a side note.

In this particular case, I like ./method because I don't like 
$?SELF.method, which looks like my terminal is in UTF-8 and there is an 
ISO-8859-2 character between $ and SELF :-))

- Cs.
A few days ago, when typing ./pugs,... You can guess the rest :)
I suggest
   ./method
to mean $?SELF.method, and
   ../method
   

 

Your opinions please! (I ask those who already responded off-list, to
repeat their opinion here)
   

Wonderful!

Re: Nested captures

[Fagyal Csongor]

Autrijus Tang wrote:
On Thu, May 12, 2005 at 12:37:06AM +0200, Fagyal Csongor wrote:
 

Damian Conway wrote:
   

  print @array[1st..($n)th];
 

Sounds cool, but what about $n = 0; ?
   

Then it would be 0..-1, an empty range.
 

Yep, but I mean in general isn't it confusing that the 0th element is 
actually the -1st (in Perl5 sense)? Does this mean that the -1st (Perl6) 
element would be the -2nd (Perl5)? Or are (-n)th elements invalid?

- Fagzal

Re: Nested captures

[Fagyal Csongor]

Damian Conway wrote:
print @array[1st..($n)th];
Sounds cool, but what about $n = 0; ?
- Fagzal

Re: Nested captures

[Fagyal Csongor]

H,
On Wed, May 11, 2005 at 08:30:42AM -0700, Larry Wall wrote:
 

On Wed, May 11, 2005 at 05:48:59PM +1000, Damian Conway wrote:
: But that's only the opinion of one(@Larry), not of $Larry.
Let's go 0-based and make $0 =:= $/[0] so that $/[] is all the parens.
Our old $0 (P5's $&) could be $<> instead, short for $ or some
such.
   

Both 0-based $0 etc and $<> are now implemented in Pugs.
 

Does anybody check if he actually implements what he say? :))) It just 
doesn't seem possible... :)

Autrijus, I assume you started Pugs by creating Time::Machine first...
BTW, anybody interested in creating and FastCGI interface for Pugs?
- Fagzal

Re: Perl6 and support for Refactoring IDE's

[Fagyal Csongor]

Matisse,
Just one note before we take this off-list:
Maybe this isn't the right place to keep discussing this, so I'll take 
pointers to other places. I'm very worried about the continued 
viability of Perl for major projects and am trying connect with other 
people and see what can be done about it.
I share some of your fears, and would be very much interested in talking 
about them with you (and others). Actually I gave a small lightening 
speech on this topic at last year's Perl gathering at Budapest, which I 
will hopefully make into an article some day...

IMHO Perl needs some more marketing 
:)

- Fagzal

Re: Perl6 and support for Refactoring IDE's

[Fagyal Csongor]

Matisse,
Will Perl 6 help us have tools that are as good or better than the 
ones available for Java, C#, etc?

I've been using Perl since 1994 and for the past several years have 
used it to build a number of complex mod_perl applications. I love Perl.

The following  may be considered heresy, but I believe that these days 
the quality of the whole development environment is just as important, 
maybe *more* important than the language itself. I mean that the 
availability of *easily integrated* tools including IDE, automated 
testing tools, refactoring, deployment tools, etc. are a HUGE factor 
in determining what language gets used for a large project
Heresy or not, I think you are (mostly) right. Actually I would say your 
are right *unfortunately*.

Available tools are a huge factor, yes - not in a way as which language 
to select for a project, but which one to *deselect*. And currently Perl 
(I mean Perl5) is not doing very well compared to others.

I've become scared that if Perl is to continue to be viable for large, 
complex, multi-developer projects that the tools need to serious 
catch-up with what is available for Java, for example. Things like:

  - Refactoring Support (see http://www.refactoring.com/)
  - CVS and/or Subversion integration
  - Support for integrating regression tests and auto-building
  - Automated syntax and dependency checking
IMHO subversioning does not have too much to do with the language 
itself. Subversioning operates on files. An IDE might integrate some 
interface for this task, but that is a different question.
Syntax checking in general is very hard to do in Perl5/6 because of the 
great amount of line noise there (consider yourself in the middle of 
writing a regexp :)) The perl6 compiler must be able to do syntax 
checking, though :-), and the design of Perl6, as I understand, 
definetely gives you more possibilities compared to Perl5.

For the others, some more knowledgeable folks will probably provide some 
answers and ideas. However, I think that the language design and 
implementation does not have too much to do with IDE availability.

I've been using Eclipse, with the EPIC plugin 
(http://e-p-i-c.sourceforge.net/) and so far I like it. It uses 
Devel::Refactor to support "extract subroutine", but a lot more is 
needed to match what you can do with Java these days.

What are others' thoughts on this?
Have you considered using the "DONATE" button on 
http://e-p-i-c.sourceforge.net/ ? :)))

- Fagzal