Perl6 Builtin Types?
Where is the most definitive list of known Perl6 (not Parrot) builtin types? The following have been specified/implied by the A/Es: scalar bit (== bool? == boolean?) num int str bigint bignum bitarray (maybe) ref rx (or regex,rule?) code classname Object array hash But also stated is that perl6 will have enough type information to easily interact with other languages, which implies to me that types must exist which, at minimum, mirror the C types (maybe by the same names, maybe not, maybe both)... int (char, long, short, whatever) int8 int16 int32 int64 uint uint8 uint16 uint32 uint64 float double (long double, etc?) cstr (null-terminated, non-Unicode-aware?) which wouldn't be used in typical programming, but would be needed to define signatures for things pulled in from other libraries? And perhaps bin oct hex should be builtin types subclassed from uint, but with overloaded (de)serialization such that: my int $i = 0x0a; print $i; # prints '10' my int $i = '0x0a'; print $i; # prints '0' my hex $i = 0x0a; print $i; # prints '0a' my hex $i = '0x0a'; print $i; # prints '0a' my hex $i = '0a'; print $i; # prints '0a' for helping with the variety of shell tools that Perl is so good at producing. What's the closest to a definitive list, so far? MikeL
Re: perl6 operator precedence table
On 20 Oct 2002, Smylers wrote: : However it means that the binary ops become: : : $a || $b # logical or : $a .| $b # bitwise or : $a && $b # logical and : $a .& $b # bitwise and : $a ! $b # logical xor : $a .! $b # bitwise xor : : That makes logical xor look a little inconsistent (it doesn't line up : for a start). : : Doubling the exclamation mark would make logical xor fit in better : (though that'd leave three of them in equivalence). On top of which, Damian has expressed an interest in ! for a superpositional xor. So the logical is probably !!. Plus it's actutally easier to see the missing bits when there's two of them. : > I also like the idea that ~ is entirely freed up for some other : > nefarious use. : : Yeah; how'd that happen? Seems like not too long ago we were short of : punctuation symbols, and now you've got a spare one lying around. Pity there's no extra brackets lying around without going to Unicode... Larry
Re: Perl6 Builtin Types?
On Wed, 23 Oct 2002, Michael Lazzaro wrote:
: Where is the most definitive list of known Perl6 (not Parrot) builtin
: types?
:
: The following have been specified/implied by the A/Es:
:
: scalar
: bit (== bool? == boolean?)
We could always call them "umu", which is Japanese for yes/no. :-)
: num
: int
: str
Yes.
: bigint
: bignum
I think these just manifest as Num and Int, since the object types
will promote as necessary to big representations internally.
: bitarray(maybe)
No, that's just
my bit @array;
also known as
my @array returns bit;
also known as
my @array of bit;
also known as
my @array is Array of bit;
Note that "is" is the only way to specify the type of the variable
as opposed to what the variable contains.
"returns" is synonymous with "of", mostly so we can use "returns" on
subroutines, because "of" sounds weird:
my int sub foo () {...}
my sub foo () of int { ... }
my sub foo () returns int { ... }
More in A6...
: ref
Yes.
: rx (or regex,rule?)
That's Rule, I expect.
: code
Probably Code.
: classname
Probablly Class, which stringifies to a class name.
: Object
Yes, as new UNIVERSAL.
: array
: hash
Array and Hash. We reserve lowercase for "atomic" types.
: But also stated is that perl6 will have enough type information to
: easily interact with other languages, which implies to me that types
: must exist which, at minimum, mirror the C types (maybe by the same
: names, maybe not, maybe both)...
:
: int (char, long, short, whatever)
: int8
: int16
: int32
: int64
: uint
: uint8
: uint16
: uint32
: uint64
: float
: double (long double, etc?)
: cstr(null-terminated, non-Unicode-aware?)
Sure, why not? Might have to be long_double though. cstr might be assumed
if it's known you're passing a str to C. And num is probably double in
disguise.
: which wouldn't be used in typical programming, but would be needed
: to define signatures for things pulled in from other libraries?
:
: And perhaps
:
: bin
: oct
: hex
:
: should be builtin types subclassed from uint, but with overloaded
: (de)serialization such that:
:
: my int $i = 0x0a; print $i; # prints '10'
: my int $i = '0x0a'; print $i; # prints '0'
:
: my hex $i = 0x0a; print $i; # prints '0a'
: my hex $i = '0x0a'; print $i; # prints '0a'
: my hex $i = '0a'; print $i; # prints '0a'
:
: for helping with the variety of shell tools that Perl is so good at
: producing.
Hmm, maybe. Seems more like an interface shift than a type shift,
though. It's like "use the int type but wrap a hex interface
around it." This says to me that we need a method of specifying
that a given interface overrides methods from other base classes.
But this interface actually has an implementation somewhere. Hmm.
: What's the closest to a definitive list, so far?
Yours. :-)
But I'll try to remember to put a list into A6.
Larry
Re: Perl6 Builtin Types?
On Wed, Oct 23, 2002 at 11:40:40AM -0700, Larry Wall wrote:
> "returns" is synonymous with "of", mostly so we can use "returns" on
> subroutines, because "of" sounds weird:
>
> my int sub foo () {...}
> my sub foo () of int { ... }
> my sub foo () returns int { ... }
I read this and I think
sub ... () of Borg { }
but I can't work out what ... should be for the best joke. Nevermind. I'll
just blatantly plug the spoofathon. (The Borg are better than perl
because...?)
Nicholas Clark
--
INTERCAL better than perl? http://www.perl.org/advocacy/spoofathon/
Re: perl6 operator precedence table
> Date: Wed, 23 Oct 2002 11:14:33 -0700 (PDT) > From: Larry Wall <[EMAIL PROTECTED]> > On top of which, Damian has expressed an interest in ! for a > superpositional xor. Which would behave how, exactly? Luke
[OT] Power of Lisp macros?
Hi, Perl is my favorite language, and I'm eagerly following Perl 6 development. So I would like to ask this question here. Sorry if I'm being inconvenient... Do you think that Lisp macros make the language more powerful than others (eg Perl)? I mean, do they really give a competitive advantage, or are they being overrated (see below)? I've been reading Paul Graham's articles (www.paulgraham.com), they are very interesting. Here's a paragraph from "Beating the Averages": But I think I can give a kind of argument that might be convincing. The source code of the Viaweb editor was probably about 20-25% macros. Macros are harder to write than ordinary Lisp functions, and it's considered to be bad style to use them when they're not necessary. So every macro in that code is there because it has to be. What that means is that at least 20-25% of the code in this program is doing things that you can't easily do in any other language. However skeptical the Blub programmer might be about my claims for the mysterious powers of Lisp, this ought to make him curious. We weren't writing this code for our own amusement. We were a tiny startup, programming as hard as we could in order to put technical barriers between us and our competitors. What do you think? I have very little Lisp experience... Thanks, -- Adriano
Re: perl6 operator precedence table
> > On top of which, Damian has expressed an interest in ! for a > > superpositional xor. > > Which would behave how, exactly? ! the way people expect, I fear. -Miko
Re: [OT] Power of Lisp macros?
> Date: Wed, 23 Oct 2002 18:43:08 -0300 > From: Adriano Nagelschmidt Rodrigues <[EMAIL PROTECTED]> > > Hi, > > Perl is my favorite language, and I'm eagerly following Perl 6 > development. So I would like to ask this question here. Sorry if I'm > being inconvenient... > > Do you think that Lisp macros make the language more powerful than > others (eg Perl)? I mean, do they really give a competitive > advantage, or are they being overrated (see below)? If you define "powerful" as "can do more things," then of course not. Lisp is implemented in C, and C's macros are certainly not essential to its functionality. But think of what macros in general provide: * Multi-platform compatability * Easier maintenance Perl has no problem with the former. It's multi-platform by nature. But is has as much of a problem with the latter as any other language, except Lisp. That is one of the continuing strong points of Lisp: it can change very, very quickly. However, they are intending to make it possible to write things like C with subs, which will imply most of the power of macros... though I imagine it won't be possible to have the level of introspection lisp macros have (infinite). But, that design team is very clever, so you never know. This kind of thing should reveal itself in the next Apocalypse. Then we can see Larry's "vision," and make appropriate adjustments in terms of that. Right now, it's very fuzzy. Oh, and you aren't being inconvenient. These kinds of questions are what the list is for: ask away! Luke
Re: perl6 operator precedence table
On top of which, Damian has expressed an interest in ! for a
superpositional xor.
Which would behave how, exactly?
Well, that's still a matter for conjecture.
N-ary xor isn't particularly useful, because binary xor naturally generalizes
to: "an odd number of these N operands are true". (Hint: think about the
truth table for logical C<$a !! $b !! $c>).
An alternate interpretation of generalized xor is that it means
"exactly one of these N operands is true". That's what I envisage
superpositional C doing:
Function Operator
any |
all &
one !
So you could write:
if $x1 ! $x2 ! $x3 == 0 {
print "Cubic equation has a unique root\n";
}
or:
$nonrepeated = any(@value) == one(@value);
or:
$second_biggest = any(@value) < one(@value);
None of these makes C/C as essential as C or C, but:
(a) someone smarter than me will almost certainly
find a killer app for C,
(b) the symmetry of:
Logical: && || !!
Bitwise: .& .| .!
Superpositional: & | !
is important...mnemonically, DWIMically, and aesthetically.
Damian
RE: Perl6 Builtin Types?
Nicholas Clark:
# I read this and I think
#
# sub ... () of Borg { }
sub ven () of Nine { ... }
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
Wire telegraph is a kind of a very, very long cat. You pull his tail in
New York and his head is meowing in Los Angeles. And radio operates
exactly the same way. The only difference is that there is no cat.
--Albert Einstein (explaining radio)
RE: perl6 operator precedence table
Larry Wall:
# : > I also like the idea that ~ is entirely freed up for some other
# : > nefarious use.
# :
# : Yeah; how'd that happen? Seems like not too long ago we
# were short of
# : punctuation symbols, and now you've got a spare one lying around.
#
# Pity there's no extra brackets lying around without going to
# Unicode...
Can the new nefarious use be concat? Pretty please?
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
Wire telegraph is a kind of a very, very long cat. You pull his tail in
New York and his head is meowing in Los Angeles. And radio operates
exactly the same way. The only difference is that there is no cat.
--Albert Einstein (explaining radio)
Re: perl6 operator precedence table
Brent Dax wrote: Can the new nefarious use be concat? Pretty please? There was a brief period 18 months ago when tilde *was* the designated Perl 6 concatenation operator. I certainly wouldn't mind seeing it return to that role, now that it's not needed elsewhere. And, of course, that would actually be: $x ~ $y string concatentation $x ~= $y string append ~$x stringification I guess the only concern is the potential for nasty surprises between: $str =~ s/a/b/; substitute a for b in $str and: $str ~= s/a/b/; substitute a for b in $_ and append result to $str But I guess that's no worse than: $x-=10; and $x=-10; which doesn't seem to be a problem for people in Perl 5. Damian
Re: perl6 operator precedence table
Adam D. Lopresto wrote: Really what I've been wishing for was an operator (or whatever) to let me do an s// without changing the variable. I would hope/expect that that's what the subroutine form of C would do. That is, it takes a string, a pattern, and a replacement string, and returns a new string with substitution performed (without affecting the original string): print 'He said "$( s($statement,/\.$/,"") )", but we didn't believe him.'; Damian
Re: perl6 operator precedence table
Damian Conway wrote: Adam D. Lopresto wrote: Really what I've been wishing for was an operator (or whatever) to let me do an s// without changing the variable. I would hope/expect that that's what the subroutine form of C would do. That is, it takes a string, a pattern, and a replacement string, and returns a new string with substitution performed (without affecting the original string): print 'He said "$( s($statement,/\.$/,"") )", but we didn't believe him.'; That seems a bit obfuscated; is there any chance the subroutine form could be called C or C?
Re: perl6 operator precedence table
Damian wrote: > (b) the symmetry of: > Logical:&& || !! > Bitwise:.& .| .! > Superpositional: & | ! > is important...mnemonically, DWIMically, and aesthetically. When I read that this morning I worried - as I do when I read most things from Damian (but that's a different story). I think it came down to what I think was a violation of the Principle of Least Surprise, in the form of good Huffman coding of operators. The proposed superpositional operators (& | !) are shorter than the proposed logical operators (&& || !!). Normally the shorter operator (or, in English, word) is the more common one. Is superposition really more common than boolean combination? I sort of toyed with the idea that maybe it should be the logical operators which are the short ones (& | !) and the rarer superposition ones that require you to press another key (&& || !!). This had the added bonus of leaving logical-not the way we all love, and it probably had some nostalgia element for both B (*) programmers still out there with respect to & and |. But now I see some examples and I'm not so sure. The size of the doubled-up operators seem to visually separate the arguments to the logical operations better. This is especially so if the precedence for these operators fall the way people have been saying. Which looks better? if ($a == 1|2|3 || $b eq "x"|"y"|"z") or if ($a == 1||2||3 | $b eq "x"||"y"||"z") ? Opinions welcomed, but tell us all what typeface you're using. Besides, maybe superposition is going to turn out to be a very common thing in Perl after all. I can guess Damian's response to that. I think I've already decided that I prefer it the way it is (for recent values of "is"). I just need some kind soul to pat me on the head and tell me it's OK. (Please excuse the Monash staff member, it's been a difficult week.) (*) The precursor to C, not the highly formal OO language. -- Debbie Pickett http://www.csse.monash.edu.au/~debbiep [EMAIL PROTECTED] My parents went to a world without bilateral symmetry and all they brought back was this lousy F-shirt.
