kurila 1.3 released

kurila 1.3 released


Perl Kurila 1.3 tries to reduce some ambiguities in Perl
code, and to
simplify the perl internals. Some uncommon and error prone
options
have been removed.

Highlights:
+ Dereference of a string (aka. soft or symbolic references)
will
  always give an error, even when not "use strict
'refs'"
+ The <> operator no longer supports glob patterns,
use glob() for that
+ Method resolution changed to default C3
+ "use strict 'subs'" is default on
+ Typed declarations (like C<my Animal $dog>) are no
longer possible

Known bugs:
+ Documentation
+ Limited platform support

http://dev.tty.nl/static/kurila/kurila-1.3_0/
pod/kurila13delta.html
has a more complete list of the changes.



kurila 1.3 is released together with an additional 102 CPAN
modules,
available together at:
http://dev.tty.nl/static/kurila/kurila-bundle-1.3.tar.gz


kurila 1.3 without the CPAN modules is available at:
h
ttp://dev.tty.nl/static/kurila/kurila-1.3_0.tar.gz
And should become available on CPAN.
Or use git to get the latest version:
cg-clone git://dev.tty.nl/perl#kurila



Perl Kurila is a dialect of Perl. With Perl 5 as ancestor it
has a
solid base, but without the backwards compatibility
requirement of Perl 5, it is free to evolve into new
directions.

A longer explanation of kurila is available at
http://dev.tty.nl/static/kurila/kurila-1.3_0/po
d/kurilaintro.html



Standing on the shoulders of a red giant to face the
future.


-- 
Gerard Goossen
TTY Internet Solutions

On  0, Gerard Goossen <gerardtty.nl> wrote:
> kurila 1.3 released
> 
> + Typed declarations (like C<my Animal $dog>) are
no longer possible

Just FYI, my typesafety.pm module used that.  I know I could
also
support C<< my $x :type(foo) >>, but that's too
junky for pervasive
use in a program.  Was this removed because it was easy to
remove?
Or is that little feature actually prone to causing grief
and adding
complexity to the core?

Do you have plans to move to a pure 'vtable accessors' style
implementation
for SVs, AVs, HVs, etc, where operations are done on them in
an OO-ish
sort of way rather than using a bunch of macros?  In other
words, are you
aiming for any higher hanging fruit (more elusive and
difficult but
significant of cleanups)?

-scott

On Tue, Oct 09, 2007 at 01:47:32PM -0700, Scott Walters
wrote:
> On  0, Gerard Goossen <gerardtty.nl> wrote:
> > kurila 1.3 released
> > 
> > + Typed declarations (like C<my Animal
$dog>) are no longer possible
> 
> Just FYI, my typesafety.pm module used that.  I know I
could also
> support C<< my $x :type(foo) >>, but that's
too junky for pervasive
> use in a program.  Was this removed because it was easy
to remove?
> Or is that little feature actually prone to causing
grief and adding
> complexity to the core?

There was some "optimalization" when doing method
calls on a typed
declared variable (I can never rember how exactly it works),
but I thought it
wasn't worth the complexity, so I removed it. 

> Do you have plans to move to a pure 'vtable accessors'
style implementation
> for SVs, AVs, HVs, etc, where operations are done on
them in an OO-ish
> sort of way rather than using a bunch of macros?  In
other words, are you
> aiming for any higher hanging fruit (more elusive and
difficult but
> significant of cleanups)?

On of the aims is reducing the complexity of SV* (in all its
forms), and
make them more into distinct "types". I'm not sure
where exactly to go
from there, maybe vtable-style OO, maybe something else.

Another aims is to "free up" some uncommon or
error-prone syntax, to
allow for new sytnax. I haven't thought much about new
syntax instead of the
typed declaration, (except to make the sigils optional, or
maybe adding back the typed
declarations, but then with full automatic type checking
(preferably
mostly compile time).

-- 
Gerard Goossen
TTY Internet Solutions

Gerard Goossen wrote:
> kurila 1.3 released
> 
> 
> Perl Kurila 1.3 tries to reduce some ambiguities in
Perl code, and to
> simplify the perl internals. Some uncommon and error
prone options
> have been removed.
> 
> Highlights:
> + Dereference of a string (aka. soft or symbolic
references) will
>   always give an error, even when not "use strict
'refs'"

Without symbolic refs how does one make a named closure? 
All those fancy
accessor generation modules out there rely on soft
references like so.

	sub make_accessor {
		my($class, $name) = _;

		my $code = sub {
			my $self = shift;
			if( _ ) {
				$self->$name(_):
			}
			return $self->$name();
		};

		no strict 'refs';
		*{$class . '::' . $name} = $code;
	}


PS  I'm sorry that this post isn't one bitching about Perl 6
or 5.004
compatibility or project resources or Python 3000.  It's a
question about
kurila.  Sorry to go off topic. :P


-- 
I have a date with some giant cartoon robots and booze.

2007/10/16, Michael G Schwern <schwernpobox.com>:
> Without symbolic refs how does one make a named
closure?  All those fancy
> accessor generation modules out there rely on soft
references like so.
>
>         sub make_accessor {
>                 no strict 'refs';
>                 *{$class . '::' . $name} = $code;
>         }
>
> PS  I'm sorry that this post isn't one bitching about
Perl 6 or 5.004
> compatibility or project resources or Python 3000. 
It's a question about
> kurila.  Sorry to go off topic. :P

As I can see, the Kurila provides Symbol::fetch_glob
function so it
can be replaced with:

>         sub make_accessor {
>                 no strict 'refs';
>                 *{Symbol::fetch_glob($class . '::' .
$name)} = $code;
>         }

I like it very much and I think it could go to official
Perl5. I
started using following code snipped in my modules:

# Compatibility with Kurila
BEGIN { *Symbol::fetch_glob = sub ($) { no strict 'refs';
*{$_[0]} }
unless defined &Symbol::fetch_glob; }

so I can be compatible with Perl5 and Kurila 

--
 .''`.    Piotr Roszatycki
: :' :    mailto:Piotr.Roszatyckigmail.com
`. `'     mailto:dexterdebian.org
  `-

Piotr Roszatycki wrote:
> As I can see, the Kurila provides Symbol::fetch_glob
function so it
> can be replaced with:
> 
>>         sub make_accessor {
>>                 no strict 'refs';
>>                 *{Symbol::fetch_glob($class . '::'
. $name)} = $code;
>>         }
> 
> I like it very much and I think it could go to official
Perl5. I
> started using following code snipped in my modules:

Ahh, there's already a much cleaner way to do that.  The
Alias module which
has been around for years.

  use Alias qw(alias);

  my $code = sub { print _ };
  alias foo => $code;

  foo("stuff");


-- 
Hating the web since 1994.

2007/10/16, Michael G Schwern <schwernpobox.com>:
> Piotr Roszatycki wrote:
> >>         sub make_accessor {
> >>                 *{Symbol::fetch_glob($class .
'::' . $name)} = $code;
> >>         }
> >
> Ahh, there's already a much cleaner way to do that. 
The Alias module which
> has been around for years.
>
>   use Alias qw(alias);
>
>   my $code = sub { print _ };
>   alias foo => $code;

Kurila doesn't allow to disable strict refs and the only way
is to use
Symbol::fetch_glob(). It is not for clarity and simplicity
of the
modules' source code. I think it just simplify the parser.

-- 
 .''`.    Piotr Roszatycki
: :' :    mailto:Piotr.Roszatyckigmail.com
`. `'     mailto:dexterdebian.org
  `-

Piotr Roszatycki wrote:
> 2007/10/16, Michael G Schwern <schwernpobox.com>:
>> Piotr Roszatycki wrote:
>>>>         sub make_accessor {
>>>>                 *{Symbol::fetch_glob($class
. '::' . $name)} = $code;
>>>>         }
>> Ahh, there's already a much cleaner way to do that.
 The Alias module which
>> has been around for years.
>>
>>   use Alias qw(alias);
>>
>>   my $code = sub { print _ };
>>   alias foo => $code;
> 
> Kurila doesn't allow to disable strict refs and the
only way is to use
> Symbol::fetch_glob(). It is not for clarity and
simplicity of the
> modules' source code. I think it just simplify the
parser.

Sorry, I didn't entirely follow that.  Are you saying the
purpose of kurila is
not to make the code simpler, but to make the parser
simpler?

Even if that is so, as long as you're introducing new
functions why not
introduce one that provides a really elegant solution to the
most common legit
use of symbolic refs?


-- 
...they shared one last kiss that left a bitter yet sweet
taste in her
mouth--kind of like throwing up after eating a junior mint.
        -- Dishonorable Mention, 2005 Bulwer-Lytton Fiction
Contest
           by Tami Farmer

Part of the aim of removing soft references was to reduce
the
complexity of the core. This wasn't for the parser but to
simplify the dereference opcodes. And to simplify perl code,
by making
a dereference always a dereference and not sometimes a
symbol lookup.

There is nothing against using Alias, but Alias is more
specific: only
suitable to make aliases. Symbol::fetch_glob is the
replacement for
doing a symbol lookup by disabling 'strict refs' and
dereferencing a
string².You can't do only do a lookup using Alias.
Symbol::fetch_glob
is much more generic, and Alias would be implemented using
Symbol::fetch_glob.


Symbol::fetch_glob can be easily used for automaticly
translating 
things, like

*{$class . '::' . $name} = $codep

is translated by the Perl5toKurila converter to¹:

*{Symbol::fetch_glob($class . '::' . $name)} = $codep

This does make code which does symbol table lookups more
complex
(longer), but it makes it obvious that a symbol lookup is
happening. And it simplifies other code, by making a
dereference always a
hard dereference and not sometimes a symbol table lookup.

Alias isn't include with the cpan modules available for
kurila because
it does not appear to be used, by any of the other modules
includes,
they all appear to do own glob assignment. But there is
nothing in
kurila against Alias.

¹ The main requirement to be compatible with kurila is that
this
translation happens correctly. The converter analyses the
opcode tree
to see if the thing being dereference is a string, using the
concat
operator (.) or stringify (") would make sure it will
be seen a symbol
lookup and a Symbol::fetch_glob is inserted.

² There is already Symbol::qualify_to_ref which does almost
the same
(only difference is that it allows an optional second
argument as
qualify namespace instead of default caller namespace). But
I found
its name too confusing, so I decided to call is fetch_glob.

On Tue, Oct 16, 2007 at 03:46:09PM -0400, Michael G Schwern
wrote:
> Piotr Roszatycki wrote:
> > 2007/10/16, Michael G Schwern <schwernpobox.com>:
> >> Piotr Roszatycki wrote:
> >>>>         sub make_accessor {
> >>>>                
*{Symbol::fetch_glob($class . '::' . $name)} = $code;
> >>>>         }
> >> Ahh, there's already a much cleaner way to do
that.  The Alias module which
> >> has been around for years.
> >>
> >>   use Alias qw(alias);
> >>
> >>   my $code = sub { print _ };
> >>   alias foo => $code;
> > 
> > Kurila doesn't allow to disable strict refs and
the only way is to use
> > Symbol::fetch_glob(). It is not for clarity and
simplicity of the
> > modules' source code. I think it just simplify the
parser.
> 
> Sorry, I didn't entirely follow that.  Are you saying
the purpose of kurila is
> not to make the code simpler, but to make the parser
simpler?
> 
> Even if that is so, as long as you're introducing new
functions why not
> introduce one that provides a really elegant solution
to the most common legit
> use of symbolic refs?
> 
> 
> -- 
> ...they shared one last kiss that left a bitter yet
sweet taste in her
> mouth--kind of like throwing up after eating a junior
mint.
>         -- Dishonorable Mention, 2005 Bulwer-Lytton
Fiction Contest
>            by Tami Farmer

-- 
Gerard Goossen
TTY Internet Solutions

Gerard Goossen wrote:
> Part of the aim of removing soft references was to
reduce the
> complexity of the core. This wasn't for the parser but
to
> simplify the dereference opcodes. And to simplify perl
code, by making
> a dereference always a dereference and not sometimes a
symbol lookup.
> 
> There is nothing against using Alias, but Alias is more
specific: only
> suitable to make aliases. Symbol::fetch_glob is the
replacement for
> doing a symbol lookup by disabling 'strict refs' and
dereferencing a
> string².You can't do only do a lookup using Alias.
Symbol::fetch_glob
> is much more generic, and Alias would be implemented
using
> Symbol::fetch_glob.

I understand that it's all still possible.

And if the purpose of Kurlia is just to play with the Perl
guts and ignore the
usability consequences on the language, then ignore the rest
of this.

Perfectly valid goal for an experiment, if that's your
goal.


> Symbol::fetch_glob can be easily used for automaticly
translating 
> things, like
> 
> *{$class . '::' . $name} = $codep
> 
> is translated by the Perl5toKurila converter to¹:
> 
> *{Symbol::fetch_glob($class . '::' . $name)} = $codep
>
> This does make code which does symbol table lookups
more complex
> (longer), but it makes it obvious that a symbol lookup
is
> happening.

It is not important to the user that a symbol lookup is
happening.  The symbol
lookup should not be emphasized, it should be hidden.  Just
like I don't want
to know that $foo = 42 is actually doing an SVIV assignment.
 I don't care.  I
just want to assign a number to a scalar.

Programmer Goal:  Give a reference a name.

Note there's nothing about globs or symbol tables in that
goal.  A glob is
(currently) just one of the fairly arbitrary actions
necessary to achieve that
goal.  If a user were to think about the actions they should
take it might go
something like this...

Action 1:  Come up with a name.
Action 2:  Get a reference of some kind.
Action 3:  Assign the reference to the name.

The actions are all fairly obvious from the goal, and the
code is equally
straight-forward.

$name = $class . '::' . $method;	# Action 1
my $ref = sub { ... };			# Action 2
alias $name, $ref;			# Action 3

Point is, if you're going to remove a feature supporting an
ugly, yet common,
idiom... why not add in something that makes that idiom
easier rather than
something which makes it harder?  Sure, have
Symbol::fetch_glob() to support
the really odd times when you do really want a glob, and put
in alias() for
the times when all you want is to name a reference.

Make the easy things easy (alias) and the hard things
possible (fetch_glob).

Hell, this can be argued as a 5.12 feature.


> Alias isn't include with the cpan modules available for
kurila because
> it does not appear to be used, by any of the other
modules includes,
> they all appear to do own glob assignment.

I don't think anyone but me remembers it. 


-- 
'All anyone gets in a mirror is themselves,' she said. 'But
what you
gets in a good gumbo is everything.'
	-- "Witches Abroad" by Terry Prachett