Re: Working on punie + rindolf (the implementation) Reloaded

[Shlomi Fish]

On Monday 02 April 2007, Marc Lehmann wrote:
> On Sat, Mar 31, 2007 at 05:06:34AM +0300, Shlomi Fish <[EMAIL PROTECTED]> 
wrote:
> > Hi Marc!
> >
> > May I forward my reply to the list?
>
> Yes, you may. Sorry for replying probably too late, thanks for asking
> first!
>

OK. Replying to two different list (which I'm not subscribed to).

> > > Well, to me, that very much sounds like "we do not openly admit it, but
> > > we want to have Perl 5+1 working now, not whatever the Perl 6 people
> > > claim they will deliver 5 years ago".
> >
> > Heh. Well, I don't expect to be able to duplicate the Pugs functionality
> > in a short time. :-). However, if you look at:
> >
> > http://www.shlomifish.org/rindolf/
>
> I wasn't clear then. Many peopel do not want a completely
> different-in-spirit language called "Perl6", but many people atcually want
> a language very much in spirit as Perl 5, just with a few important changes
> done.

You're right. I used to be very opposed to Perl 6. Now understand that it has 
some nice improvements over Perl 5, but still find looking at its code to be 
quite a bit of a future shock. "Perl 6 is a nice language. Too bad it's not 
Perl." ;-)

>
> What important changes is a matter of taste and debate, but static typing
> is certainly not on the wishlist, especially if its just going to be a
> hack to help your optimiser doing stuff it should do without limiting your
> expressibility.
>

Yes, that's right.

> > You'll see that back at the time, I was bothered with making Rindolf a:
> >
> > 1. Backwards compatible with Perl 5.
>
> Original Perl 6 goal.
>

Hmmm... are you sure?

> > 2. Not entirely compatible with Perl 6.
>
> Well :)
>

Well hopefully you would be able to call Rindolf code from Perl 6 code and 
vice versa. Also see:

http://www.shlomifish.org/philosophy/ideas/#tucan

For a different approach for creating a cross-language interaction layer. I 
admit that I haven't started working on it yet.

> > 3. Much less of a future shock than Perl 6 is.
>
> Original Perl 6 goal.
>

:-)

> If you look at the history, you will see that Perl 6 died halfway in
> between, and then completely changed its character. It has very little to
> do with Perl 5 anymore, and is probably actively hurting Perl 5 (but it
> seems Perl 5 is regenerating slowly).
>

Well, I prefer a "Do and let do" and (less preferably) a "Complain and let 
complain" approach than a hurt calcalution. Some people found value in Perl 
6, and Audreyt actually created an implementation that sort-of-works. People 
are also having fun working on Parrot and other related projects. As you 
know, perl5 (the C-based implementation) has also not been completely 
neglected, and its hackers are doing fine.

This reminds me of the standard "isn't there a better way to spend the time 
working on Porting to MS Windows" myth. If there are people who are willing 
to do something FOSSy, then it is worth doing.

> > I neglected working on Rindolf because I realised I was not particularly
> > bothered by the features I suggested, or often found out these features
> > were doable in Perl 5. Since then, however, I often found places where I
> > could use some more advanced features. Not critically, since perl 5 was
> > good enough, but still.
> >
> > As much as I respect lwall (and a lot of respect is due), I believe his
> > use of Perl for practical applications is rather minimal and does not
> > make use of the full range of the Perl 5 hollow technologies (CGI,
> > Catalyst/CGI::App/etc., POE, TT/H::T/Petal/etc., etc.). As such, while he
> > has a good intuition on what's missing in the core language, he's still
> > probably not making the full use of Perl 5's expressive power, much less
> > Perl 6's.
>
> Wouldn't outright agree to that (because I cannot make up my mind about
> this interestign aspect so quickly), but I wish you success in Rindolf.

Thanks!

Like I said - no promises. Maybe I'll get to hacking on punie - maybe I won't. 
The day is short, and I have a lot of work to do.

>
> (Although it seems the most interesting promises made by parrot - fast
> typeless code for example - are not going to be delivered, too).

Hmmm I haven't been closely following Parrot.

>
> (I do not think sending this mail to p5p is a good idea, but it is ok with
> me if you want to make a reply to it and want that published).

As I said, I'm sending it to p6-language and p6-internals instead.

Regards,

Shlomi Fish

-
Shlomi Fish  [EMAIL PROTECTED]
Homepage:http://www.shlomifish.org/

If it's not in my E-mail it doesn't happen. And if my E-mail is saying
one thing, and everything else says something else - E-mail will conquer.
-- An Israeli Linuxer

Re: Greetings

[Shlomi Fish]

On Tue, 12 Mar 2002, Luke Palmer wrote:

> Hello everyone.
>
> I just subscribed to this list. My name's Luke and I'm a perl
> devotee. And I'm starting out with a bang. Here goes:
>
> I have just read through exegesis 3, and I found the bit about
> defining your own new operators (eg. operator:*#@&) to be a little
> strange. Not confusing, but esoteric and random. What functionality
> does this provide to the language other than "It's cool."
>

For once, PDL hijacks some Perl 5 operators in very abusive ways:

http://pdl.perl.org/

So, it could use some more operators added to the language. It is possible
that the Perl 6 operators set can compensate for it. However, defining new
operators is a very good feature which I already thought of as missing in
most languages I encountered.

Regards,

Shlomi Fish

> I think, if anything, it would make things more confusing. Suppose a
> module that implemented, say, a vector (disregarding that this isn't
> really needed) provided a new operator .prod for dot product. What
> would happen in the following case:
>
>   use Vector;
>   $v = new Vector;
>   $v.prod $j;
>
> Does that last statement mean $v.prod($j), or ($v) .prod ($j)? Not to
> mention, how is the user supposed to know that she can't say
> $v.prod($j)?
>
> What about the example in the exegesis: 'operator:*#@&'? Take the
> following code:
>
>   $f *#@&
>$g;
>
> What does this mean? Does this mean $f * $g with #@& as a comment, or
> does it mean $f *#@& $g? But anyway, those are just language semantics
> that could be worked out one way or another. The big confusion lies in
> documentation and memory (human memory, that is). When your reading
> through documentation for this Vector class, which would you rather
> see?
>
>   Vector provides an operator `.prod' for computing dot
>   products. It has the same precedence as the Perl binary *
>   operator. It also provides the xprod operator which has the same
>   precedence as Perl's binary + operator.
>
> --or--
>
>   Vector provides two methods, dot and cross, which compute the
>   dot product and the cross product, respectively, on their
>   arguments.
>
> The latter has significantly less to remember, using the
> ever-so-familiar method, rather than entering two new operators with
> precedences and all into your knowledge base.
>
> Also I think that these new operators would add a new level of
> obfuscation to the language when it's not intended to be
> obfuscated. When one encounters the *#@& operator, one must consult
> the documentation for that operator, while method names are forced (at
> least for people with any good taste) to make a small amount of sense.
>
> Not to mention the extra strain on the lexer, not that it matters
> much.
>
> But in general, I suggest that the whole roll-your-own operator thing
> be stripped from Perl 6. Not completely, however. I like the idea of
> overloading existing operators, which has long been a part of the
> language. I also kind of like the idea of defining infix
> operators. But I think that would come back to the whole complication
> with precedences again, which I don't find much elegance in.
>
> In summary, roll-your-own operators seem to be a contrived attempt at
> being revolutionary, without providing much practicality.
>
> Not to bash them or anything :-P
>
>Luke Palmer,
>[EMAIL PROTECTED]
>

-- 


--
Shlomi Fish[EMAIL PROTECTED]
Home Page: http://t2.technion.ac.il/~shlomif/
Home E-mail:   [EMAIL PROTECTED]

He who re-invents the wheel, understands much better how a wheel works.