Re: Dynamic scoping (take 2)
I'm sorry, but I gotta get back on the
no-global grail trail for at least one
more post.
> The granularity [of currying] can be
> controlled on a sub-by-sub or on a
> class-by-class basis.
If one could do something like this:
{
my $src = 'oldname1';
my $dest = 'newname1';
use FileUtils.default($src, $dest);
# FileUtils subs now use $src and/or
# $dest if $src and/or $dest args are
# not supplied at run-time:
&foo;
&foo('oldname2','newname2');
}
# FileUtils subs revert to normal
sub foo (;$src, $dest) {
&FileUtils::rename($src, $dest);
}
where FileUtils is a module (ie one can
curry classes OR modules), and where the
use XXX.default has something akin to the
effect of currying FileUtils sub calls
/if the relevant args do not exist/ till
the end of the enclosing lexical scope
for the current execution thread, and
where all of this can be done without a
significant hit to performance, then you
appear to have completely eliminated the
practical need for creating globals and
replaced it with a succinct and intuitive
way to express what's going on (even if
my example above isn't the clearest way
to explain it).
--
ralph
Re: cvs commit: parrot/docs jit.pod
On Tue, Nov 26, 2002 at 09:55:00AM -, Leopold Toetsch wrote: > +B > + > +The Ith integer or floating processor register, mapped in this section. > + > +Note: The register with the physical number zero can not be mapped. > + > +=begin unimp > + Why can't it be mapped? Fundamental implementation constraints (using zero to flag something else?) This will impact performance, although whether it's not actually measurable, slight, or moderate, I don't know. ["patches welcome"?] Nicholas Clark
Re: Roll Call
On 11/08/2002 12:09 PM, Michael Lazzaro wrote: If you wish to take part in the discussions (or even just lurk), please reply to this message. If you have any particular goals that you feel this list should be addressing, please let us know. I'll probably lurk here, on and off, via NNTP. So far, it looks like a very nice list -- high signal, low noize, and it's possible to keep it all straight in your head. -=- James Mastros
Re: cvs commit: parrot/docs jit.pod
Nicholas Clark wrote:
On Tue, Nov 26, 2002 at 09:55:00AM -, Leopold Toetsch wrote:
+B
+
+The Ith integer or floating processor register, mapped in this section.
+
+Note: The register with the physical number zero can not be mapped.
+
+=begin unimp
+
Why can't it be mapped? Fundamental implementation constraints (using
zero to flag something else?)
Yep. The test for a mapped register:
if (MAP[1]) is the problem: this translate to
jit_info->optimizer->map_branch[jit_info->op_i + 1]
where map_branch is the {int,float}val_map at the end of jit_emit.h i.e.
the register list.
... This will impact performance, although
whether it's not actually measurable, slight, or moderate, I don't know.
Either we fix this, or the registers have to be renumbered, so that reg
#0 is not used. The emit_code for registers could take care of this.
Currently no architecture has this problem, register #0 is used as
scratch register.
i386 uses register numbers 1 higher then actual, though EAX nether gets
mapped.
["patches welcome"?]
Always, but as currently no architecture is concerned ...
Nicholas Clark
leo
Re: cvs commit: parrot/docs jit.pod
On Tue, Nov 26, 2002 at 01:51:47PM +0100, Leopold Toetsch wrote: > Either we fix this, or the registers have to be renumbered, so that reg > #0 is not used. The emit_code for registers could take care of this. That's a crafty trick. nothing wrong with that :-) > Currently no architecture has this problem, register #0 is used as > scratch register. > > i386 uses register numbers 1 higher then actual, though EAX nether gets > mapped. > > > > ["patches welcome"?] > > > Always, but as currently no architecture is concerned ... Valid point. But I was envisaging for ARM that r12 or r14 ought to be the scratch register. The way the ABI works, with r12 trashed on function call entry, but r0 used to return values from functions means that r12 is available within an op, while mapping r0 to a parrot register for the first JITted op after an external call could save 1 register move. Nicholas Clark
Re: Glossary?
On 11/17/2002 1:11 AM, Dave Storrs wrote: Arrays know how to manage their own size; they will grow and shrink as needed when you add or remove elements. You never need to worry about whether an array has enough space to hold the number of elements you are about to insert. Reference to fixed-size lists, where this isn't true? (***) Examples of arrays (usage): @foo = (1, 2,3); # create/init an array Clear, consistant formatting: "(1, 2, 3);" -- I know, just a typo. @foo[2]; # fetch last element Should also give the value in comment, or better, write as text/test. @foo[-1]; # fetch last element Sm. undef @foo; # destroy array, free associated memory, #and decrement reference count on each #value Should we note here that this also has the value of undef? I would, but with a reference, not an explination. Also, I'd reorder this: 1) Creating arrays 2) Accessing parts of arrays 3) name/container/values distinction 4) Detailed defintion of arrays But we're getting into documentation, not defintion. The defintion should be short and simple, and have lots of references. (The things you're refering to mostly won't exist yet, but that's OK.) (**) There needs to be a point here explaining the difference between "list of literals" and "literal list" (and the same for arrays), but I find that I don't understand it well enough myself to explain it. If at all possible, I think it would be a very good thing if we could get away from the array/list distinction, at least with those terms. (Finding better terms is a p6d issue, getting rid of it is a p6l issue.) In purticuar, /there is no such thing as a list in scalar context/. There is mearly an application of the scalar comma operator, and spacing that makes it look like a list. The context propigation rules say that there is no way for a list in scalar context to happen. The documentation shouldn't say things like a list returns it's last element whereas an array returns it's size, because it simply ain't so, and causes confusion. (I'd write an RFC suggesting that the scalar comma op dies, but it's too late, and I'm sure somebody already did. Anyway, that's a p6l thing too.) -=- James Mastros
Re: Numeric literals, take 1
On 11/14/2002 1:58 PM, Angel Faus wrote:
=section ** Pseudo-Numbers
=section *** NaN
The value C ("Not a Number") may be returned by some
functions or operations to signal that the result of a
calculation (for example, division by zero) cannot be
represented by a numeric value.
...
=section *** Inf
The terms C and C<-Inf> represent positive and
negative infinity; you may sometimes use these to create
infinite lists.
For the C values, perl will operate them following
the standard conventions. For example:
Guys, can we please not argue over just how arithmetic and such works
for NaN and Inf, and defer to IEEE specs (IEEE-754, AKA IEEE floating
point)? It'll save much argument, and that's how it'll almost certianly
be implemented anyway. Give examples and references, but don't define
nonstandard "standard" perl6 semantics when a good standard exists.
(I'm looking for a good reference on the IEEE semantics right now, but
I'm not having much luck for some reason.)
(We need a few additional rules, actualy: NaN is false, and -Inf and
+Inf are both true. If either are forced into an int, and error occours
(? on that last point.) This whole paragraph might properly be pushed
off to the discussion of Num in Bool context later.)
-=- James Mastros
Re: Numeric literals, take 1
On 11/26/2002 8:02 AM, James Mastros wrote: Guys, can we please not argue over just how arithmetic and such works for NaN and Inf, and defer to IEEE specs (IEEE-754, AKA IEEE floating point)? It'll save much argument, and that's how it'll almost certianly be implemented anyway. Give examples and references, but don't define nonstandard "standard" perl6 semantics when a good standard exists. (I'm looking for a good reference on the IEEE semantics right now, but I'm not having much luck for some reason.) (Yes, I'm replying to myself.) The best reference I can find right now is http://research.microsoft.com/~hollasch/cgindex/coding/ieeefloat.html. If anybody has a better one, I'd /love/ to see it. (IEEE-754 itself is non-free.) (here -N is a negitive number, +N is a negive number, and N is any number (but not NaN or Inf).) N / Inf => 0 Inf / Inf => NaN # Multipication between infintes follows normal sign rules, and is infinite in result. Inf * Inf => Inf -N/0 => -Inf 0/0 => NaN +N/0 => +Inf Inf - Inf => NaN Inf * 0 => NaN All arithmetic ops with any arg NaN results in NaN. NaN==NaN is NaN, which is false. NaN!=NaN is also NaN, which is false. -=- James Mastros
RE: Status Summary; next steps [x-bayes][x-adr]
From: Bryan C. Warnock [mailto:[EMAIL PROTECTED]] > > If you don't already know whether it exists, or how it will > roughly work (lexically), you shouldn't be discussing it on > p6d. Kicked back to p6l. [...] > and again... what's the scope of p6d p6d exists to document the language. A task which consists of going over the A&E's and Larry's posts to p6l, etc. and flushing them out into deliverables: o Perl6/Parrot regression tests o Language Specification derived from tests o Core Perl Documentation / User Manual Flushing them out consists of: o disambiguation o isolating potential problems o writing tests and documentation I have difficulty separating the pd6 disambiguation discussions from language design... as I expect do others. Language design discussion belongs on p6l. And I for one, would like to see a big red flag delimiting speculation, when it occurs on p6d. Though there's the p6d argument that a limited amount of speculation is called for, in that we should use the p6d cabal to work our language design issues into a coherent refined proposal before dumping them into the fray that is p6l. > , and how does it differ from p6l? p6d differs from p6l, in that p6d has a specific goal: "document the language". Whereas p6l is a rather more ambiguous forum for people to influence Larry's design and explain it one another. That said, it is also hoped that p6d will also have a beneficial effect on p6l. Where p6l undergoes an iterative wave of questions and proposals re-examining issues covered in previous A&E's following each new release, p6d hopes to annotate its documentation to include the various trade-offs involving alternative syntax, semantics, implementation impacts, ideological ax grinding, etc. so that p6l can refer people to the old arguments instead of wasting ever more time on them. -- Garrett Goebel IS Development Specialist ScriptPro Direct: 913.403.5261 5828 Reeds Road Main: 913.384.1008 Mission, KS 66202 Fax: 913.384.2180 www.scriptpro.com [EMAIL PROTECTED]
RE: Glossary? [x-adr]
James Mastros wrote:
> On 11/17/2002 1:11 AM, Dave Storrs wrote:
> > Arrays know how to manage their own size; they will grow
> > and shrink as needed when you add or remove elements. You
> > never need to worry about whether an array has enough space
> > to hold the number of elements you are about to insert.
>
> Reference to fixed-size lists, where this isn't true?
Do we have such a thing? In Perl5:
use constant foo => [1,2,3];
print foo()->[0]++;
print " @{foo()}";
results in:
1 2 2 3
Does Perl6 have fixed size lists? Do we have fixed size lists with fixed
elements? I.e., literal arrays?
> In purticuar, /there is no such thing as a list in scalar
> context/. There is mearly an application of the scalar comma
> operator, and spacing that makes it look like a list. The
> context propigation rules say that there is no way for a
> list in scalar context to happen.
Here I believe you are wrong.
Larry Wall, A2, RFC 175:
>
> the explicit list composer:
>
> [1,2,3]
>
> is syntactic sugar for something like:
>
> scalar(list(1,2,3));
> The documentation shouldn't
> say things like a list returns it's last element whereas an
> array returns it's size, because it simply ain't so, and
> causes confusion. (I'd write an RFC suggesting that the
> scalar comma op dies, but it's too late, and I'm sure
> somebody already did. Anyway, that's a p6l thing too.)
This was covered in Apoc2. An explict list in scalar context returns a list
reference. An array in scalar context returns an array reference. Or as
Larry (A2, RFC 009) wrote:
>
> it has to be possible to assign array references to array
> variables without accidentally invoking list context and
> copying the list instead of the reference to the list. We
> could invent another assignment operator to distinguish
> the two cases, but at the moment it looks as though bare
> variables and slices will behave as lvalues just as they
> do in Perl 5, while lists in parentheses will change to
> a binding of the right-hand arguments more closely
> resembling the way Perl 6 will bind formal arguments to
> actual arguments for function calls. That is to say,
>
> @foo = (1,2,3);
>
> will supply an unbounded list context to the right side, but
>
> (@foo, @bar) = (@bar, @foo)
>
> will supply a context to the right side that requests two
> scalar values that are array references.
--
Garrett Goebel
IS Development Specialist
ScriptPro Direct: 913.403.5261
5828 Reeds Road Main: 913.384.1008
Mission, KS 66202 Fax: 913.384.2180
www.scriptpro.com [EMAIL PROTECTED]
RE: Status Summary; next steps [x-bayes][x-adr]
On Mon, 2002-11-25 at 14:25, Michael Lazzaro wrote: > (2) The behavior of an explicit bool type, _if_ one exists, > that stores "truth", not "value". Such that C = (0 but true)> stores true, not 0, and does so in "the > most efficient way". There is no explicit bool type. Larry Wall wrote: > > Please don't think of C as a boolean type. There is > no boolean type in Perl, only a boolean context. Or looking > at it from the other direction, *every* type is a boolean > type. http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&selm=Pine.LNX.4.44.021031 1952540.18773-10%40london.wall.org -- Garrett Goebel IS Development Specialist ScriptPro Direct: 913.403.5261 5828 Reeds Road Main: 913.384.1008 Mission, KS 66202 Fax: 913.384.2180 www.scriptpro.com [EMAIL PROTECTED]
RE: Numeric literals, take 1 [x-bayes][x-adr]
James Mastros wrote: > > Guys, can we please not argue over just how arithmetic > and such works for NaN and Inf, and defer to IEEE specs > (IEEE-754, AKA IEEE floating point)? It'll save much > argument, and that's how it'll almost certianly be > implemented anyway. NaN requires a pragma. As such, shouldn't documenting it be deferred till later? And then, you might want to take a look at: o IEEE 754 Support in C99 document http://grouper.ieee.org/groups/754/meeting-materials/2001-07-18-c99.pdf o IEEE 754 web page http://grouper.ieee.org/groups/754/ > Give examples and references: In chronological order: Damian Conway: > Perl NaN's will not be IEEE 754 compliant. Damian: > NaN is dead. [...] > Except perhaps under a C pragma of some kind, in > which case it would be a proper IEEE Norweigian Blue NaN. Larry: > > : IIRC, native data types, which are all lowercase (e.g., > : int, bit, long, etc.) cannot be undef. However, their > : class equivalents (e.g., Int, Bit, Long, etc) can be undef. > > That is correct. It probably throws an exception if you > try to assign an undefined value to a lowercase type. > (Though an IEEE num might well set itself to NaN instead.) So there you have it. NaN is outside the core... or at least a pragma away... Or pickup a thread: http://www.mail-archive.com/perl6-language@perl.org/msg08521.html http://www.mail-archive.com/perl6-language@perl.org/msg08359.html http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&threadm=Pine.LNX.4.44.021 0311948500.18773-10%40london.wall.org&rnum=1&prev=/groups%3Fnum%3D20%26h l%3Den%26lr%3D%26ie%3DISO-8859-1%26q%3D%2B%2522IEEE%2522%2Bgroup%253Aperl.pe rl6.language%2Bauthor%253ALarry%2Bauthor%253AWall -- Garrett Goebel IS Development Specialist ScriptPro Direct: 913.403.5261 5828 Reeds Road Main: 913.384.1008 Mission, KS 66202 Fax: 913.384.2180 www.scriptpro.com [EMAIL PROTECTED]
Re: Numeric Literals (Summary 4)
On Mon, Nov 25, 2002 at 09:01:36AM -0800, Michael Lazzaro wrote: > (Umm... what's a better name than "coloned form"? That term sounds > really... um... bad.) How about: - explicit radix - dotted notation - DSD (Dot Separated Digits) --Dks
Re: cvs commit: parrot/docs jit.pod
Nicholas Clark wrote: But I was envisaging for ARM that r12 or r14 ought to be the scratch register. The way the ABI works, with r12 trashed on function call entry, but r0 used to return values from functions means that r12 is available within an op, while mapping r0 to a parrot register for the first JITted op after an external call could save 1 register move. Don't do that ;-) 1) jit/i386 already has JITted native vtable calls with return values. So mapping a register, which returns values from functions is not a good idea because: 2) Next optimizations will avoid register load/store, when a register is preserved, register allocation will be more long ranged (i.e. past external calls too). For this, we need some notion for preserved registers, e.g. #define PRESERVED_REGS 3 (first 3 regs are callee saved). The one reg/reg move is by far more inexpensive then a reload from memory. Here is a snippet of my proposal I sent to Daniel: In the meanwhile, I'll have some ideas for jit.c, which I could start coding: - move Parrot_jit_save/_load_registers to jit.c - check usage of all registers -> reg_usage[4][NUM_REGISTERS] ... - check usage in non JITted sections too - optimize register allocation: * when register usage of next section doesn't collide, keep usage - optimize load and store * store always before non jitted section (exceptions) * load only differing registers BTW, is it an improvement to allocate a register, when the use count==1? Changes beyond this: allocate P (and S) registers too: the JITed vtable calls could benefit from this. If there are too many registers to allocate (damned i386) I would weight the allocation like e.g. 10:2:1 for I:P:S, so if a P parrot register is heavily used, it would get a processor register. First is done. Second is in work currently. Last is done (for RHS use_count == 1). Nicholas Clark leo
Re: Status Summary; next steps
On Monday, November 25, 2002, at 11:23 PM, Joseph F. Ryan wrote: (1) String Interpolation. This was pretty well spelled out by A2, so there shouldn't be much to do except write it up, unless we want to make any additional requests. There's some issues that need to be finalized wrt Unicode, escaped chars, etc. I'm pretty familiar with all of the new string interpolation semantics, so I'll write this section up, unless someone else wants to do it (or is already doing it). Awesome, thanks. MikeL
Re: Numeric literals, take 1
On Tuesday, November 26, 2002, at 05:02 AM, James Mastros wrote:
Guys, can we please not argue over just how arithmetic and such works
for NaN and Inf, and defer to IEEE specs (IEEE-754, AKA IEEE floating
Yes and no. perl6-internals has been discussing this, so I think we
can pause and not worry about it quite yet. Floats will almost
certainly be IEEE, but in addition to floating point ("num", aka C
"double"), most of the same issues exist for sized integers, both
signed and unsigned. Worse, the behaviors are platform-dependent.
For example, what happens when you add two 8-bit numbers, and the
result is no longer an 8-bit number, e.g. 'overflow'? (We may indeed
have access to a type called 'int8', since Parrot will likely have it.)
my int8 $i = 254;
my int8 $j = 254;
$i += $j; # ???
Does it overflow (via an exception?), silently truncate, or ?. (Parrot
may offer us both options.) We can choose to call the result "platform
dependent", or define it explicitly. But let's wait and see what the
Parrot people think, since they're closer to the action.
MikeL
Re: Numeric literals, take 1
On Tuesday, November 26, 2002, at 07:21 AM, Garrett Goebel wrote: NaN requires a pragma. As such, shouldn't documenting it be deferred till later? Yes, but not _too_ much later. If C isn't the default behavior, we have to document what _is_ the default behavior. :-) And if you need a pragma to enable C, which in turn makes fundamental changes in how many Perl6 numeric types behave, we ought to document _both_ behaviors in the "Numerics" section. Even if it's a standard pragma, it still may be a "basic feature" of Perl6 that needs documenting, and we should associate it with the other numeric behaviors. (We can't quite go in Camel-book order, w.r.t. pragma and other toggles.) But it's true, perl6-internals is talking about these issues right now. So if we wait a bit, we can have a much more informed discussion. MikeL
Re: Glossary? [x-adr]
On Tue, Nov 26, 2002 at 08:38:55AM -0600, Garrett Goebel wrote:
: James Mastros wrote:
: > On 11/17/2002 1:11 AM, Dave Storrs wrote:
: > > Arrays know how to manage their own size; they will grow
: > > and shrink as needed when you add or remove elements. You
: > > never need to worry about whether an array has enough space
: > > to hold the number of elements you are about to insert.
: >
: > Reference to fixed-size lists, where this isn't true?
:
: Do we have such a thing? In Perl5:
:
: use constant foo => [1,2,3];
: print foo()->[0]++;
: print " @{foo()}";
:
: results in:
:
: 1 2 2 3
:
:
: Does Perl6 have fixed size lists? Do we have fixed size lists with fixed
: elements? I.e., literal arrays?
You can declare an array to be constant, in which case it behaves as
a literal array of literals.
: > In purticuar, /there is no such thing as a list in scalar
: > context/. There is mearly an application of the scalar comma
: > operator, and spacing that makes it look like a list. The
: > context propigation rules say that there is no way for a
: > list in scalar context to happen.
:
:
: Here I believe you are wrong.
:
: Larry Wall, A2, RFC 175:
: >
: > the explicit list composer:
: >
: > [1,2,3]
: >
: > is syntactic sugar for something like:
: >
: > scalar(list(1,2,3));
:
:
: > The documentation shouldn't
: > say things like a list returns it's last element whereas an
: > array returns it's size, because it simply ain't so, and
: > causes confusion. (I'd write an RFC suggesting that the
: > scalar comma op dies, but it's too late, and I'm sure
: > somebody already did. Anyway, that's a p6l thing too.)
:
: This was covered in Apoc2. An explict list in scalar context returns a list
: reference. An array in scalar context returns an array reference. Or as
:
: Larry (A2, RFC 009) wrote:
: >
: > it has to be possible to assign array references to array
: > variables without accidentally invoking list context and
: > copying the list instead of the reference to the list. We
: > could invent another assignment operator to distinguish
: > the two cases, but at the moment it looks as though bare
: > variables and slices will behave as lvalues just as they
: > do in Perl 5, while lists in parentheses will change to
: > a binding of the right-hand arguments more closely
: > resembling the way Perl 6 will bind formal arguments to
: > actual arguments for function calls. That is to say,
: >
: > @foo = (1,2,3);
: >
: > will supply an unbounded list context to the right side, but
: >
: > (@foo, @bar) = (@bar, @foo)
: >
: > will supply a context to the right side that requests two
: > scalar values that are array references.
Except that we did end up going with the second operator to do binding.
But it's still the case that a comma list in scalar context assumes
[...] around it.
Larry
Re: Numeric Literals (Summary 5)
On Mon, Nov 25, 2002 at 10:06:13AM -0800, Michael Lazzaro wrote:
: With clarifications, and additional syntactic edge cases.
:
: The last remaining known "numeric literals" issue is whether we want to
: allow '.' in explicit radix, e.g. 10#1.234, or whether we want to
: disallow it as being Way Too Creepy. This version assumes that '.' is
: allowed, but exponential notation is _not_, due to ambiguities with 'E'.
:
:
: --- Numeric Literals ---
:
: decimal notation:
: 0123 # int 123 (not octal!)
Probably illegal in early Perl 6. Can perhaps allow it later.
: -123 # int -123 (but - is operator, not part of num)
Works because of constant folding.
:0.1.1 # WRONG, can have only one decimal point
Is a v-string.
:.1 # WRONG; looks like method call on $_
:-.1 # WRONG, looks like method call on $_
Both legal, as in Perl 5. There are no numeric method calls, and
if there are you can always do them by indirection:
$meth = "1";
$foo.$meth()
: - explicit radix form may have radix point, '.',
: but cannot use exponential notation ('e')
Note that this is not a great hardship, since constant folding should
fix up things like
20#1.1 * 1e5
20#1.1 * 20**13
Larry
Re: perl6 tests
On Fri, Nov 22, 2002 at 05:49:58PM +, Piers Cawley wrote: > Dave Storrs <[EMAIL PROTECTED]> writes: > > > Ideally, there could even be a per-list switch and a global switch > > that says "(don't) show unique ids when interpolating lists/arrays". > > By default, it gets set to "show", but it can be turned off if you > > want. > > What would that gain you? Apart from a global variable the world would > be better off without? Remember, if you want to print it out without > the 'id' information you can just do C; It would mean that, by setting a command line switch or passing a command-line argument, I could change the behaviour of my code without having to change the code. --Dks
Re: Dynamic scoping (take 2)
On Mon, Nov 25, 2002 at 02:27:36PM -0800, Randal L. Schwartz wrote: : > "Simon" == Simon Cozens <[EMAIL PROTECTED]> writes: : : Simon> What were the good reasons for not allowing localized lexicals in Perl 5? : : Nobody could explain it in 50 words or less. : : "What the hell is 'local my $foo = 35'?" That particular form is useless, since the scope of the temporization is the same as the scope of the lexical. But there's no reason not to be able to temporize a file-scoped lexical, for instance, so that it behaves as a global to all the subs in the current file, but is invisible outside the file. Well, hey, that's close to 50 words. :-) Larry
Re: Status Summary; next steps [x-bayes][x-adr]
On Tue, Nov 26, 2002 at 08:52:52AM -0600, Garrett Goebel wrote: : On Mon, 2002-11-25 at 14:25, Michael Lazzaro wrote: : > (2) The behavior of an explicit bool type, _if_ one exists, : > that stores "truth", not "value". Such that C = (0 but true)> stores true, not 0, and does so in "the : > most efficient way". : : There is no explicit bool type. : : Larry Wall wrote: : > : > Please don't think of C as a boolean type. There is : > no boolean type in Perl, only a boolean context. Or looking : > at it from the other direction, *every* type is a boolean : > type. : : http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&selm=Pine.LNX.4.44.021031 : 1952540.18773-10%40london.wall.org Um. I modified that statement later in the same thread: http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&threadm=Pine.LNX.4.44.0210311952540.18773-10%40london.wall.org&rnum=1&prev=/groups%3Fhl%3Den%26lr%3D%26ie%3DUTF-8%26selm%3DPine.LNX.4.44.0210311952540.18773-10%2540london.wall.org I don't think there *has* to be a bool type. Certainly we could get by with: my bit $x = ?(0 but true); Though it would look a little odd to write: my bit $x = true(0 but true); Note that the "true" property is not the same as the "true" function. This tells me that properties may need their own namespace distinct from either subs or classes. (We've talked about defining properties as subs or classes, but either way is problematic. If we have a C class we can't parse a C unary operator correctly.) Hmm, we may have the same problem with all classes, if the unary operator is supposed to be a type cast. We can't have "int" meaning both my $class = int; my $integer = int $number; unless we either require parens on typecasts, or parse class names as typecasts for which no argument could be found. The latter approach is more appealing than requiring parens, but we might have difficulty telling new Int 3 from new Int: 3 Hmm. Larry
Re: Status Summary; next steps
On Mon, Nov 25, 2002 at 07:46:57PM -0500, Bryan C. Warnock wrote: : Should an explicit bool type be part of the language? If so, how should : it work? C storing only a truth property but : no value makes little sense in the context of the larger language. So : does handling truth as something other than a property. Don't think of truth as a property--it's a predicate that can pay attention to the property if it's defined. But if there's no property, truth is defined by the C method on the class of the object. Again, a property is just a singleton method override. : > (3) Context. How to determine it, how to force it. Hypothesis: There : > is a one-to-one relationship between Type and Context, such that there : > is a context that matches every type, and a type that matches every : > context (except void). : : Again... Well, it is a good question. We don't have a type for every context in Perl 5, particularly for boolean and list context. They just get mapped onto existing scalar and array types. : > (4) Typecasting. How int <--> num, num <--> str, str <--> bool, etc. : > Generic typecasting rules: how to define user classes that can typecast : > to/from str, int, bool, etc. This gets into Perl6 OO, but we may need : > to request some preliminary decisions before then, because the : > implications are substantial. : : and again... Typecasting may be a bad word. We're not trying fib to ourselves about the type of an object. That's done with: $object.PRETEND_CLASS::method() What we're really talking about is coercions or conversions. Coercions are multimethods if you count the return type as part of the signature. But we certainly can specify that the syntax will involve the type name functioning as a subroutine name. int() makes an int, num() makes a num, etc. Provided we can solve the syntactic ambiguity I mentioned in my other message. : > Let's open these for discussion. Questions/proposals/issues, anyone? : : and again... what's the scope of p6d, and how does it differ from p6l? As far as I'm concerned, p6d and p6l just have different deliverables. p6l is looking at the elephant from above, while p6d is looking at the elephant from below. But it's the same elephant. (Unless it's a camel.) Whatever the animal, figuring out the underside of it is, by definition, not going to be a clean process. Larry
Re: Status Summary; next steps
On Monday, November 25, 2002, at 04:46 PM, Bryan C. Warnock wrote: On Mon, 2002-11-25 at 14:25, Michael Lazzaro wrote: (2) The behavior of an explicit bool type, _if_ one exists, that stores "truth", not "value". Such that C stores true, not 0, and does so in "the most efficient way". If you don't already know whether it exists, or how it will roughly work (lexically), you shouldn't be discussing it on p6d. Kicked back to p6l. and again... what's the scope of p6d, and how does it differ from p6l? The main difference is that p6-docs is intended to move very narrowly from topic to topic, in a roughly predetermined order, focusing on each one until the more dedicated members start to bleed from the ears and/or we're convinced we have *all* the answers we need from the design team to completely describe the required Perl6 behavior. (Right now, we're discussing primitive scalar types and values.) Then we write the answers down, get it approved, and move on to the next narrowly scoped topic. The discussion is moderated, and sometimes tedious, if you're not interested in what's currently being discussed. p6-lang is more of a free-for-all, where you can ask/propose stuff regardless of what the current topic is. The discussion is more broad, and distinctly _not_ structured. Neither p6l nor p6d have any inherent decision making capabilities; those have been abrogated (willingly) to the design team. I certainly expect the docs contributors to propose new ideas when/where appropriate, just like p6l does. That's one of the reasons for going through things in excruciating detail, so we can find any potential gotchas or places in which broader generalization may help. I would recommend posting to p6-documentation if you have an issue/proposal with something the documentation project is currently discussing, and p6-language if you have other random thoughts/questions that p6d haven't gotten to yet. It's pretty much the same people, after all. :-) MikeL
Re: Status Summary; next steps
On Tuesday, November 26, 2002, at 09:47 AM, Larry Wall wrote: : > (3) Context. How to determine it, how to force it. Hypothesis: There : > is a one-to-one relationship between Type and Context, such that there : > is a context that matches every type, and a type that matches every : > context (except void). Well, it is a good question. We don't have a type for every context in Perl 5, particularly for boolean and list context. They just get mapped onto existing scalar and array types. My own supposition is that it's useful to think of context and type as two sides of the same coin. Context is just the Type you're expecting. (Sounds like a bad country song.) Aside from C, is there a reason for that _not_ to be the case? : > (4) Typecasting. How int <--> num, num <--> str, str <--> bool, etc. : > Generic typecasting rules: how to define user classes that can typecast : > to/from str, int, bool, etc. This gets into Perl6 OO, but we may need : > to request some preliminary decisions before then, because the : > implications are substantial. What we're really talking about is coercions or conversions. Yes, sorry. I need to break myself of that word. "Coercions" be what I mean. MikeL
Re: C#/Parrot Status
Nicholas Clark wrote:
(do all the unsigned with masks)
Yep
And we ought to make a generic "safe" version of the code for signed
truncation that works for platforms that are any or all of the following
holds
I tried this one:
inline op conv_i1(inout INT) {
#if 1
INTVAL x = $1;
x <<= 24;
x >>= 24;
x &= ~0xff;
x |= $1 & 0xff;
$1 = x;
#else
$1 = (INTVAL)((char)($1));
#endif
goto NEXT();
}
The 24 is something like (INTVAL_SIZE * CHAR_BIT - 8). Should be faster
on pipelined processors then a test for negative and branch.
leo
Re: What dotgnu.ops does (Re: C#/Parrot Status)
Gopal V wrote:
inline op conv_u1_ovf(inout INT) {
- if($1 >= 0 && $1 <= 256 ) {
+ if($1 >= 0 && $1 <= 255 ) {
Thanks, applied
leo
Re: Status Summary; next steps [x-bayes][x-adr]
Larry Wall writes: > Note that the "true" property is not the same as the "true" function. > This tells me that properties may need their own namespace distinct > from either subs or classes. (We've talked about defining properties > as subs or classes, but either way is problematic. If we have a > C class we can't parse a C unary operator correctly.) Brent Dax summarized sometime ago: ## TERMOPERATORDOUBLE OPERATOR ## ## $ scalar sigil ## @ array sigil ## % hash sigil modulo ## & sub sigil junction and** logical and ## = assignment comparison ## \ get reference ## .. method call** method call** range constructor ## ? force to bool* ** trinary operator ## ## , list composer list composer ## ; statement end statement end ## : super-comma package ## separator, ## trinary operator ## how about ":" as a sigil for properties . my $x is :constant arcadi
Re: Status Summary; next steps
"Larry Wall" <[EMAIL PROTECTED]> wrote: > On Mon, Nov 25, 2002 at 07:46:57PM -0500, Bryan C. Warnock wrote: > : Should an explicit bool type be part of the language? If so, how should > : it work? C storing only a truth property but > : no value makes little sense in the context of the larger language. So > : does handling truth as something other than a property. > > Don't think of truth as a property--it's a predicate that can pay > attention to the property if it's defined. But if there's no property, > truth is defined by the C method on the class of the object. > Again, a property is just a singleton method override. So is it fair to say that Bool is an Interface? No concrete class, no boolean literals: but if you store a value in a variable of type Bool, then you will still have access to its c and c methods. If we define Boolean-ness in this way, then we can say that context is an interface. I think it is true to say that a type is a junction of interfaces -- so we could allow that context is a type. If (that's a 72 point "if") we accept the preceding, then it is natural (IMO) to employ the Null-Object pattern for the remaining special case: Void is an interface with no methods (or perhaps a junction of zero interfaces)! I think we need a strong technical definition of terms here: classes, interfaces, types, contexts and objects. Lets see: An object is a value, associated with implementations of the methods that access and/or manipulate that value. An interface is a grouping of method signatures. A class is an object, whose value is an implementation of one or more methods. A variable is a reference to an object. A Type is a set of constraints on a variable. It may define the signatures of methods that must be supported by object(s) stored in the variable; and it may impose additional constraints on the value stored. A Context defines how an object will be used. This may constrain the required methods of the object, or may provide information, which is not a mandatory constraint: for example, if the result is a list, then the context may give the "natural" length of the list to which the value will be assigned. If the result is to be assigned to a scalar variable, then the context may provide access to the object currently stored in that variable. I writing these definitions, I came to the conclusion that a context is more than a type. Others may disagree. Dave.
Re: Status Summary; next steps
On Tuesday, November 26, 2002, at 12:47 PM, Dave Whipp wrote: I writing these definitions, I came to the conclusion that a context is more than a type. Others may disagree. Hmm, I suppose it depends on how broadly we use the term "type"; I like your definition, if I understand it correctly. :-) (thinking aloud...) For example, suppose you have a context that says "I expect to see [a reference to a function that has an argument "bar" of type int, and an argument "foo" which is a reference to a MyBlah]". Even if there isn't an explicit type name associated with it, I'd consider everything inside the [...] to be the description of a certain expected "type". You _could_ name that type, but you don't have to -- the long-form description will do. Or, for your list example, suppose you say "I expect to see [a list with three elements]", to differentiate from "I expect to see [a list with four elements]". my($a,$b,$c)= &foo(); # two different contexts: my($a,$b,$c,$d) = &foo(); # two possible multimethod variants Both are different contexts, and both the [...] parts represent different unnamed "types"; the multimethod &foo could _theoretically_ be given a different variant for each. So I'd maybe say context and type are matched one-to-one IFF you can give a name to every possible context, and use that name wherever you want to represent that context. (Where "name" means "possibly multi-word signature-like description that you can give a shorter explicit name to if you want to.") I'm trying to think of a counterexample, in which you have a context that _cannot_ be represented as a "type" according to this very broad definition. I don't think it should be possible, is it? If it _is_ possible, does that represent a flaw/limitation of the perl6 "types"? again, thinking aloud. MikeL
Re: Status Summary; next steps
"Michael Lazzaro" <[EMAIL PROTECTED]> wrote > I'm trying to think of a counterexample, in which you have a context > that _cannot_ be represented as a "type" according to this very broad > definition. I don't think it should be possible, is it? If it _is_ > possible, does that represent a flaw/limitation of the perl6 "types"? Let us imagine that an object can tell us that it will be destroyed as a result of the assignment (we don't have ref-counts, but some variables are scoped lexically). Now imagine that the output object is expensive to create: but that the current object (which will be destroyed as a result of the assignment) can be cheaply modified. There might be some optimization potential here. Perhaps an example will clarify my thoughts my $big_heavy_object = Foo.new; $big_heavy_object = add($big_heavy_object, $bar); If the context provides access to the lvalue, then it may be possible to optimize. Effectively, we have the information to create an implicit C<+=> operator. The add method should be able to utilize the fact that it can recycle the old lvalue. If the old-lvalue is available in the context, then the context is more than a type. Dave.
RE: Status Summary; next steps [x-bayes][x-adr]
On Tue, 2002-11-26 at 09:17, Garrett Goebel wrote: > > p6d exists to document the language. A task which consists of going over the > A&E's and Larry's posts to p6l, etc. and flushing them out into > deliverables: > > o Perl6/Parrot regression tests > o Language Specification derived from tests > o Core Perl Documentation / User Manual > > Flushing them out consists of: > o disambiguation > o isolating potential problems > o writing tests and documentation > > I have difficulty separating the pd6 disambiguation discussions from > language design... as I expect do others. Language design discussion belongs > on p6l. And I for one, would like to see a big red flag delimiting It certainly isn't black and white, and that's understandable. It's a paint-by-numbers project, only no one's really put the numbers in yet. There may be a general consensus that this should be green and that should be blue, and it's p6d's job to work out what shade, or why that can't be the case. Other sections may be arbitrarily colored, and those are a little more fuzzy, but p6d can usually test and document that, too. p6d shouldn't be drawing the picture, though. Let Larry look at the p6l and draw the elephant. You guys just make sure it doesn't turn out white. > speculation, when it occurs on p6d. Though there's the p6d argument that a > limited amount of speculation is called for, in that we should use the p6d > cabal to work our language design issues into a coherent refined proposal > before dumping them into the fray that is p6l. > > > > , and how does it differ from p6l? > > p6d differs from p6l, in that p6d has a specific goal: "document the > language". Whereas p6l is a rather more ambiguous forum for people to > influence Larry's design and explain it one another. > > That said, it is also hoped that p6d will also have a beneficial effect on > p6l. Where p6l undergoes an iterative wave of questions and proposals > re-examining issues covered in previous A&E's following each new release, > p6d hopes to annotate its documentation to include the various trade-offs > involving alternative syntax, semantics, implementation impacts, ideological > ax grinding, etc. so that p6l can refer people to the old arguments instead > of wasting ever more time on them. Yeah, I wanted the same thing with PDD 0. :-) Hopefully this will turn out better. :-) -- Bryan C. Warnock bwarnock@(gtemail.net|raba.com)
Re: Status Summary; next steps
On Tue, 2002-11-26 at 13:36, Michael Lazzaro wrote: > The main difference is that p6-docs is intended to move very narrowly > from topic to topic, in a roughly predetermined order, focusing on each But not to move faster than the design of the language. > one until the more dedicated members start to bleed from the ears > and/or we're convinced we have *all* the answers we need from the > design team to completely describe the required Perl6 behavior. (Right Correct. To describe the required Perl6 behavior. Yes, that means you need to ask questions. Sometimes those questions may involve some hand-waving. Just please, *please* refrain from rampant p6l-ish speculation. > now, we're discussing primitive scalar types and values.) Then we > write the answers down, get it approved, and move on to the next > narrowly scoped topic. The discussion is moderated, and sometimes > tedious, if you're not interested in what's currently being discussed. No, I *am* interested in what's being discussed - the committing to stone (hopefully granite, but understandable if it's sandstone) of what's going to happen. What I'm not interested are the big brainstorming sessions - I simply don't have the time for them any more. (Nor will I in the foreseeable future. I can't even get back to the internals. )-: > > p6-lang is more of a free-for-all, where you can ask/propose stuff > regardless of what the current topic is. The discussion is more broad, > and distinctly _not_ structured. It's not a question of structure. I attend many meetings that are a highly structured waste of my time. :-) > > Neither p6l nor p6d have any inherent decision making capabilities; > those have been abrogated (willingly) to the design team. I certainly > expect the docs contributors to propose new ideas when/where > appropriate, just like p6l does. That's one of the reasons for going And that's where I take issue. If it's "just like p6l does", then do it on p6l. We ran into a similar scenario early on with the various p6-* lists, and more recently (and constantly) on p6i when broaching the subjects of Perl 6 versus Parrot. As you said, if the most active people are on both lists, then it shouldn't be a problem. The lists aren't supposed to be defined by their contributors, only by their contributions. > through things in excruciating detail, so we can find any potential > gotchas or places in which broader generalization may help. > > I would recommend posting to p6-documentation if you have an > issue/proposal with something the documentation project is currently > discussing, and p6-language if you have other random thoughts/questions > that p6d haven't gotten to yet. It's pretty much the same people, > after all. :-) Then why have two lists? Dammit, I need to quit asking rhetorical questions. Be kind to Piers. Be kind to the readers. Don't have separate but equal discussions in two different lists. Weed out the cruft, fill in the gaps. Interpolate, don't extrapolate. -- Bryan C. Warnock bwarnock@(gtemail.net|raba.com)
Re: Numeric literals, take 1
On Tue, 2002-11-26 at 11:55, Michael Lazzaro wrote: > Does it overflow (via an exception?), silently truncate, or ?. (Parrot > may offer us both options.) We can choose to call the result "platform > dependent", or define it explicitly. But let's wait and see what the > Parrot people think, since they're closer to the action. It might help the Parrot people if they knew what their target languages wanted. (Not that they can guarantee delivery of said requests, of course. :-) -- Bryan C. Warnock bwarnock@(gtemail.net|raba.com)
