: On Wed, 2005-02-16 at 08:54 -0800, David Wheeler wrote:
:
: > And what of .c#?
:
: It's an alias for .java.

I'm sorry, but neither of those is powerful enough to represent Perl
data structures.  ;-)

Larry

: On Wed, Feb 16, 2005 at 10:07:34PM -0800, chromatic wrote:
: : On Wed, 2005-02-16 at 08:54 -0800, David Wheeler wrote:
: :
: : > And what of .c#?
: :
: : It's an alias for .java.
:
: I'm sorry, but neither of those is powerful enough to represent Perl
: data structures.  ;-)

Actually, I'm thinking we should just go with a single method and
have it merely default to :lang<Perl>.  But .repr is rather ugly.
How 'bout .pretty instead?  If we made the language the first optional
argument you could have $x.pretty('Lisp'), $x.pretty('C#'), etc.

How long before someone writes $x.ugly('Python'), I wonder...

Larry

 > Actually, I'm thinking we should just go with a single method and
 > have it merely default to :lang<Perl>.  But .repr is rather ugly.
 > How 'bout .pretty instead?  If we made the language the first optional
 > argument you could have $x.pretty('Lisp'), $x.pretty('C#'), etc.

Hmmmmm, maybe we shouldn't introduce oxymorons into the language. ;-)

Actually, I'd have thought that the type coercion mechanism might be a
more appropriate way to go here. After all, the serialization of a data
structure is merely a coercion to a subtype of Str. Specifically, I
imagine a parameterized Source subtype:

     class Source[Language ::To] is Str {
         multi sub *coerce:as (Any $data, To ::Lang) {
             return Lang.serialize($data)
         }
     }

Then you could just write:

     my $good = $x as Source[Perl];
     my $bad  = $x as Source[C::Sharp];
     my $ugly = $x as Source[Lisp];

And adding a new serialization would simply mean adding a new Language
subclass with an appropriate .serialize() method:

     class YAML is Language {
         method serialize($data) {
             ...
         }
     }

     class XML is Language {
         method serialize($data) {
             ...
         }
     }

     # etc.

Damian

HaloO Damian,

What is the return type of &*coerce:as?

  1: the implicit ::?CLASS,
     but how is that constructed from Language subclasses?

  2: infered from &Language::serialize<Any> which delivers Str or Perl but Str
     or some such?

  3: Str, which doesn't need meta information and is the (final) intension anyway

I assume 1, but is that right?
2 and 3 contradict the general idea of &coerce:as which returns the
type of the rhs argument.

What is entered into the MMD tables for &*coerce:as
  a:            2-ary &*coerce:as<Any,Language>
  b: parametric 2-ary &*coerce:as<Any,Source[Language]>
  c: parametric 2-ary &*coerce:as<Source[Language],Any>
  d:            3-ary &*coerce:as<Source,Any,Language>

and would cases b and c be written as &*coerce:as<Source><Any,Language>.
I assume case b is right, or actually instanciations of that for
concrete values of ::To.

The type of e.g. $good is then Source[Perl], right?

Again, the return type of &YAML::serialize<$> is taken from the
lexical ::?CLASS which is of course YAML?

Regards,
--
TSa (Thomas Sandlaß)

Sorry, I was too lazy (well, I'd claim I was thinking at a much higher level,
but it amounts to the same ;-) and I made a mistake in the signature of the
coercion.

Here's a fully typed, and correctly parameterized, version:

       class Source[Language ::To] is Str {
           multi sub *coerce:as (Any $data, Source[To] ::Lang)
               returns Source[To]
           {
               return Lang.serialize($data)
           }
       }

       class YAML is Language {
           method serialize($data) returns Source[YAML] {
               ...
               return Source[YAML].new($source_code);
           }
       }

Or we could cheat in the coercion, and just do it all with strings:

       class Source[Language ::To] {
           multi sub *coerce:as (Any $data, Source[To] ::Lang)
               returns Str
           {
               return Lang.serialize($data)
           }
       }

       class YAML is Language {
           method serialize($data) returns Str {
               ...
               return $source_code;
           }
       }

As for the MMD table, that's an implementation issue, but presumably it'd have
to contain separate entries for each instantiation of the generic Source class:

       2-ary &*coerce:as<Any,Source[Perl]>
       2-ary &*coerce:as<Any,Source[Python]>
       2-ary &*coerce:as<Any,Source[Lisp]>
       2-ary &*coerce:as<Any,Source[C::Sharp]>
       # etc.

or (more likely, given the dynamic nature of Perl) a single entry that's a
"trampoline" that instantiates particular parameterizations of the generic
class as they're needed:

       2-ary &*coerce:as<Any,Source[*]>

Damian

I got no answer... does this mean this is utter nonsense?

Michele
--
SILVIO CLEPTOMANE
- Scritta su un muro,
   Via F. Sforza, Milano

Well, one point to look at the issue is that the keys of a hash alread are
a set. In some sense you get sets with an additional unavoidable feature
(the values).

Talking Perl6, which has a type system, it becomes suddenly possible to
have hashes of whatever type of values one may want. For example one may
implement a good approximation to a set with an hash of 1-bit integers; I
don't know if there will be a built in one-value-only data type, and I
wouldn't see for it any other use than this.

OTOH the set of subsets of a given set A can be put in bijective
correspondence with  {0,1}^A, in which case using 1-bit integers may have
some sense from this perspective.

Again, using arbitrary integers (also in Perl5) you automatically have
multisets, i.e. unordered lists.

In any case I, for one, would like "real" sets as builtin data types. I
understand that some features of them are already provided by other data
types and I find junctions to be of an extreme interest. It would be nice
thus, if all these data types could be "linked" is some elegant way. E.g.
there should be an immediate, and possibly automatic way to turn a set
(whatever it would) be into a junction or a hash (with certain
predefined values) where needed.

As a last observation, hashes, which are from the UI POV the counterpart
of mathematical functions, could be based on (the counterpart of
mathematical) sets, whereas they're being based on a somewhat "orthogonal"
concept, i.e. that of ordered pairs. Of course this approach is
interesting too, but it would be nice to have both...

Me too!

Michele
--

Yes. He was also an early environmentalist; hence the current
phrases "green" this and "green" that...
- David C. Ullrich in sci.math, thread "Who is Green?"

: On Sun, 13 Feb 2005, Jonathan Lang wrote:
:
: >>   If we want Sets in Perl, we should have proper Sets.
: >
: >I'll agree, depending on what you mean by "proper".  I'd be interested in
: >having some means to perform set operations in perl6: unions,
: >intersections, differences, membership checks, and subset/superset checks.
:
: Well, one point to look at the issue is that the keys of a hash alread are
: a set. In some sense you get sets with an additional unavoidable feature
: (the values).
:
: Talking Perl6, which has a type system, it becomes suddenly possible to
: have hashes of whatever type of values one may want. For example one may
: implement a good approximation to a set with an hash of 1-bit integers; I
: don't know if there will be a built in one-value-only data type, and I
: wouldn't see for it any other use than this.

I remember being rather happy when I discovered a use for the null datatype
in Ada.  It turned out to be useful as a peg for hanging various sorts of
declarations on when you wanted to do something at a particular point in
the elaboration but didn't actually want to declare something.  We could
have a similar situation here, where a Hash of nothing doesn't actually have
any values, just keys.  Of course, it'd be convenient if such hash values
returned 1 as a default value, but one could get along with just .exists.

But instead of defining a nothing type, we could just continue
down the road we started in A12 that says an enumerated value is
simply a subtype that happens to be constrained to a single value.
In which case you could just declare a Hash of bool::true or a Hash
of Days::Tuesday and the hash would always just return that value
(but only for existing keys, of course).

And then nothing is stopping you from defining nothing explicitly.

Larry

: On Mon, 14 Feb 2005, Michele Dondi wrote:
:
: >Speaking of which, while I think that methods on the implicit topicalizer
: >and the C<.=> assignement operator are indeed cool, I wonder if any
: >provision will be made for a convenient stand in for "whatever is on the
: >left side of an assignment operator", e.g.
:
: I got no answer... does this mean this is utter nonsense?

No, I just think the extra functionality would not be worth the mental
load of another pronoun.  One problem is that it would not be at all
clear *when* you are referring to the left side.  It's changing over
time, after all.  But even if that were settled, it seems there are
several other ways to do the same thing, any of which might be more
understandable, especially if you can bind any lvalue to a name of
your choice, and make it an ordinary noun.

But rather than that, I suspect we'll see more use of constructs
where the object to be mutated ends up being the topic, as in:

    some_complicated_lvalue() but= { .sortmyway(foo($_),bar($_)) }

which would presumably do the same as

    my $noun is rw := some_complicated_lvalue();
    $noun = $noun but { .sortmyway(foo($_),bar($_)) };

which presumably means something like

    my $noun is rw := some_complicated_lvalue();
    $noun = $noun.copy.=sortmyway(foo($noun),bar($noun));

Larry

I assume that $noun.copy means that we are making a copy of the object
and changing the copy.  That has memory and side-effect implications.

How would one do this as a mutation/in-place-edit, instead of a copy?

--Dks, who recognizes what "presumably means something like" means but
  is curious anyway

There are a couple of problems: first, a hash's keys are limited to
strings; a set ought to be able to handle a wider range of data types.
Second, the only set-related operation that hashes have implemented is the
membership check.  None of the other options I was looking for (see above)
work without _considerable_ effort.  Meanwhile, the proposal of a
disjunction-derived Set class seems to cover all of these options with
relative ease.  That said:

...then you've got the notion of Fuzzy Logic Sets, where the key would be
the prospective element and the value would be the degree of membership.
For fuzzy sets, hashes seem to be a better fit than junctions, which have
no obvious means of supplying the degree-of-membership info.  You're still
stuck with the "keys must be strings" problem, so it's not an ideal
solution; but it's better than nothing.  

=====
Jonathan "Dataweaver" Lang

__________________________________
Do you Yahoo!?
Meet the all-new My Yahoo! - Try it today!
http://my.yahoo.com

: ...then you've got the notion of Fuzzy Logic Sets, where the key would be
: the prospective element and the value would be the degree of membership.
: For fuzzy sets, hashes seem to be a better fit than junctions, which have
: no obvious means of supplying the degree-of-membership info.  You're still
: stuck with the "keys must be strings" problem, so it's not an ideal
: solution; but it's better than nothing.  

Hash keys are only strings by default.  Just as any array can have
a shape, so can any hash, and the shape of the hash is determined by
the subtypes of its dimensional indices.  (See S9 for more on this.)
But using values for degree of membership is an interesting idea.
On the other hand, if we ever have numeric datatypes with built-in
error bars, those could generalize to keys with an associated
certainty of some sort, and then you can leave the values out of it.
In which case a junction might have varying degrees of likelihood
varying between noneness and allness.  It's all too powerful for a
Pooh like me, though...  :-)

Larry

Last time I checked, there was going to be a way to declare a
different data type for the key (which could easily be Any).

--
Brent 'Dax' Royal-Gordon <br...@brentdax.com>
Perl and Parrot hacker

"I used to have a life, but I liked mail-reading so much better."

Well, if I had learnt something about Perl6 it is that it is no longer
necessarily so.

Michele
--
It's also amazing how much use Larry's getting out of his colon. (The
character, obviously).
- "The Perl 6 Summarizer".

OTOH all these discussions seem to imply that there is some demand (by me,
for one!) for a "set-like" builtin data-type as well as for the already
existing hashes and junctions and of course for interoperability between
any two of them, e.g. in terms of automatic conversions where needed, etc.
Or maybe for an "ancestor" data type of all three of them that can be
specialized to any? (I don't think this option is viable, but that final
remark is intriguing in this sense...)

Michele
--

It is not PC to use "PC" to mean "Windows box". :-)
- Brian McCauley in clpmisc, "Re: Using perl over network (NFS)"

Define "builtin".  It was pointed out recently how one could derive a
"Set" class from a Disjunction type, implementing the few things that Sets
can do that Disjunctions can't.  Put this in a module, and a simple "use
Set" at the start of your script is all that would be needed to have full
Set functionality.  

=====
Jonathan "Dataweaver" Lang

__________________________________
Do you Yahoo!?
Take Yahoo! Mail with you! Get it on your mobile phone.
http://mobile.yahoo.com/maildemo