Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Common Serialization Interface

3 views
Skip to first unread message

Brad Bowman

unread,
Sep 25, 2006, 8:21:36 PM9/25/06
to perl6-l...@perl.org

Both Data::Dumper and Storable provide hooks to customize serialization
($Data::Dumper::Freezer|Toaster, STORABLE_freeze|_thaw).
Other modules like YAML and Clone could also possibly reuse a
common state marshalling interface.

Is there some common element to this process which can be gathered
into a Serialize role with a default implementation?

Does the meta information or object construction process change
the needs for Perl 6?

Brad

--
It is written that the priest Shungaku said, "In just refusing to
retreat from something one gains the strength of two men." This is
interesting. -- Hagakure http://bereft.net/hagakure/

Mark Stosberg

unread,
Sep 25, 2006, 10:02:56 PM9/25/06
to perl6-l...@perl.org
Brad Bowman wrote:
>
> Both Data::Dumper and Storable provide hooks to customize serialization
> ($Data::Dumper::Freezer|Toaster, STORABLE_freeze|_thaw).
> Other modules like YAML and Clone could also possibly reuse a
> common state marshalling interface.
>
> Is there some common element to this process which can be gathered
> into a Serialize role with a default implementation?

There is already ".yaml" to serialize to yaml and ".perl" to serialize
to Perl (I'm not sure what the limits are round-tripping Perl this way).

They can be returned to Perl in a consistent way, too:

eval($yaml, :lang<yaml>);

Still, these options may not substitute for the kind of role-based
solution you have mind.

Mark

Larry Wall

unread,
Sep 25, 2006, 9:30:36 PM9/25/06
to perl6-l...@perl.org
On Mon, Sep 25, 2006 at 09:02:56PM -0500, Mark Stosberg wrote:
: Brad Bowman wrote:
: >
: > Both Data::Dumper and Storable provide hooks to customize serialization
: > ($Data::Dumper::Freezer|Toaster, STORABLE_freeze|_thaw).
: > Other modules like YAML and Clone could also possibly reuse a
: > common state marshalling interface.
: >
: > Is there some common element to this process which can be gathered
: > into a Serialize role with a default implementation?
:
: There is already ".yaml" to serialize to yaml and ".perl" to serialize
: to Perl (I'm not sure what the limits are round-tripping Perl this way).

One thing that makes an enormous practical difference is whether the
entire serialized string must be in memory or not. (I've been trying
to work with a 37M yaml file recently, sigh...)

: They can be returned to Perl in a consistent way, too:


:
: eval($yaml, :lang<yaml>);
:
: Still, these options may not substitute for the kind of role-based
: solution you have mind.

I'm not sure it's wise to overload eval this way. Seems like a
great way to defeat MMD. Plus I really want a file interface so I
don't have to slurp a 37M string, which in turn requires a 400M stack
allocation currently. Seems to want even more heap after that, and
then it really starts thrashing...

Larry

Aaron Sherman

unread,
Sep 27, 2006, 10:51:56 AM9/27/06
to perl6-l...@perl.org
Larry Wall wrote:
> On Mon, Sep 25, 2006 at 09:02:56PM -0500, Mark Stosberg wrote:
> :
> : eval($yaml, :lang<yaml>);
> :
> : Still, these options may not substitute for the kind of role-based
> : solution you have mind.
>
> I'm not sure it's wise to overload eval this way. Seems like a
> great way to defeat MMD. Plus I really want a file interface so I
> don't have to slurp a 37M string, which in turn requires a 400M stack
> allocation currently. Seems to want even more heap after that, and
> then it really starts thrashing...

Not everything has to be done via MMD, of course, and more to the point,
many things can play nice with MMD.

multi sub eval(Str $data, Str :$lang) {
given $lang ->{
when 'perl' { perl_eval($data) }
when 'yaml' { yaml_eval($data) }
when 'perl5' { perl5_eval($data) }
when 'pir' { pir_eval($data) }
when 'pbc' { pbc_eval($data) }
when defined { call } # Back to MMD!
default { perl_eval($data) }
}
}


BTW: for the above, it would be nice to be able to say:

when m:i/^perl$/ {...}

without all the "noise". That is, it would be nice to have something like:

when 'perl':i {...}

Dunno if that makes any sense or not.

Luke Palmer

unread,
Sep 27, 2006, 12:43:00 PM9/27/06
to Aaron Sherman, perl6-l...@perl.org
On 9/27/06, Aaron Sherman <a...@ajs.com> wrote:
> BTW: for the above, it would be nice to be able to say:
>
> when m:i/^perl$/ {...}
>
> without all the "noise". That is, it would be nice to have something like:
>
> when 'perl':i {...}

Well, there are a few ways to do that:

given lc $lang {...}

when { lc eq 'perl' } {...}

when insensitive('perl') {...}

Where the last one is a user-defined function which can be written:

sub insensitive($str) { /:i ^ $str $/ }

Such "pattern functions" can be useful in a variety of contexts. That
is, write functions which are designed explicitly to be used in the
conditions of when statements.

Luke

Larry Wall

unread,
Sep 27, 2006, 1:36:15 PM9/27/06
to perl6-l...@perl.org
On Wed, Sep 27, 2006 at 10:43:00AM -0600, Luke Palmer wrote:
: Well, there are a few ways to do that:

:
: given lc $lang {...}
:
: when { lc eq 'perl' } {...}
:
: when insensitive('perl') {...}

With the latest change to S05 that auto-anchors direct token calls,
you can now alo write:

when token { :i perl } {...}

By the way, your 0-ary "lc" needs to be written ".lc" these days.
In Chicago we outlawed most of the 0-or-1-ary functions since we now
have a 1-character means of specifying $_ as invocant.

: Where the last one is a user-defined function which can be written:


:
: sub insensitive($str) { /:i ^ $str $/ }
:
: Such "pattern functions" can be useful in a variety of contexts. That
: is, write functions which are designed explicitly to be used in the
: conditions of when statements.

I guess that can also now be written:

my &insensitive ::= token ($str) :i { $str };

or maybe even

my &insensitive ::= token :i { $^str };

Larry

0 new messages