John M. Dlugosz said [off-list]:
> Darren Duncan darren-at-darrenduncan.net |Perl 6| wrote:
>> I also know that
>> given its current design, === and !=== just happen to have the same
>> semantics as logical xnor and xor when given 2 Bool inputs, and so
>> they serve th
works correctly
regardless of whether its argument came from $! or some other source,
without having to declare 'is copy' because of the possibility it is
from $!.
The big problem here is that almost any argument for any subroutine
could potentially come from $!, and it would be rediculous for them
all to be 'is copy' just to handle the possibility.
Nor is it reasonable for a caller to have to copy $! to another
variable before passing it to a subroutine just because that sub
*may* have its own try block ... a caller shouldn't have to know
about the implementation of what it called.
I welcome feedback on this issue and a positive, elegant resolution.
-- Darren Duncan
ariables, and
has nothing to do with external data repositores such as SQL
databases. Though I anticipate that one could extend or override
built-ins so that they interact with remote databases instead of
internal variables, such as with the concept of sub-classing or role
reusing or tying.
Thank you. -- Darren Duncan
At 2:54 AM + 12/15/05, Luke Palmer wrote:
On 12/15/05, Darren Duncan <[EMAIL PROTECTED]> wrote:
I propose, perhaps redundantly, that Perl 6 include a complete set of
native
Okay, I'm with you here. Just please stop saying "native" and "core".
Everyone.
smack too much of telling Perl how to do the job.
I don't want to have to use maps or greps or whatever, to express the
various relational operations.
-- Darren Duncan
ying so.
My suggestions should not make Perl slower or more difficult to use.
They should in fact make it easier to use. And not significantly
more verbose.
Feedback?
FYI, I feel more strongly about this issue than about the other
relational things I mentioned, since the undef thing is more low
level and very pervasive, not to mention quite simple to fix.
-- Darren Duncan
ne($y)
$x == 3; # like random_one($x) == 3
The odds of two undefined values in such primitive data types being
equal is 1/Inf, which is zero.
So no 2 undefs are equal, and no undef is equal to a defined value.
You can't say what an undef equals because you don't know what value it
At 10:07 PM -0800 12/16/05, chromatic wrote:
On Friday 16 December 2005 18:15, Darren Duncan wrote:
> 0. An undefined value should never magically change into a defined
value, at least by default.
This is fairly well at odds with the principle that users shouldn't have to
bear the b
ng the
bugs introduced because such checks aren't performed in the first place. It
also allows for very strong guarantees; i.e., "I know this variable cannot
be undefined because I never assign undef to it, and the compiler would tell
me if I accessed it without assigning to it."
This is what 'use strict' should evolve toward, in my mind.
If you see 'never-assigned' and 'assigned-but-unset' to be distinct
in practical use, then maybe we need to add a method/property to all
containers that is used like .defined(), such as .unassigned() ...
but I can't say its needed.
-- Darren Duncan
At 9:30 AM + 12/17/05, Luke Palmer wrote:
On 12/17/05, Darren Duncan <[EMAIL PROTECTED]> wrote:
> Undef, by definition, is different from and non-equal to everything
else, both any defined value, and other undefs.
You said "by definition", but where is this
rograms. But like with
other strictures, this would be turned off by default in one-liners.
If the DWIM behaviour is wanted in larger programs, one can say 'no
strict undefs;' or such.
There may be remaining holes in my suggestions, but hopefully I dealt
with the worst ones from the preceeding first draft.
-- Darren Duncan
longer have to say:
eval "require $module_name;";
die if $!;
... as I do now.
I like to save string evals for when I'm actually using arbitrary
runtime generated Perl code which is in a variable.
-- Darren Duncan
First of all, I concede that features like autovivification and
undefs defaulting to the domain-qualified 'none' are fine as what
Perl does by default, so I retract any request to change this; I am
fine for these things to remain as they are and were.
-- Darren Duncan
P.S. FYI, pe
Following the discussions from 2 weeks ago, are there any plans to
update the synopsis soon regarding the $! variable? Synopsis 2 still
says that it is conjectural to whether $! is always environmental.
Thanks. -- Darren Duncan
it to say there's still the huffman
advantage of {}.
As well as the advantage of fewer changes of Perl 5 to Perl 6 porters.
-- Darren Duncan
At 3:40 PM +0100 12/22/05, Michele Dondi wrote:
On Thu, 22 Dec 2005, Darren Duncan wrote:
On a separate but related matter, I'm in the position of wanting to
do something unusual, which is create a data file format whose
content is executable perl code that defines a data structure, a
bly the point of using unboxed types is to get bleeding edge
maximum performance, and abstraction would take away from this then,
maybe. Or maybe not. But if anything bleeds through, it should be
the hardware, and not other programming languages.
-- Darren Duncan
now.
-- Darren Duncan
At 10:55 PM -0500 1/28/06, jesse wrote:
On Sat, Jan 28, 2006 at 07:52:55PM -0800, Darren Duncan wrote:
Assuming no trouble, I propose that 6.4.1 is the minimum dependency
for Pugs 6.28.0, if not 6.2.11 as well, the latter probably due any
day now.
What's the benefit of bumping th
is function is what individual classes can override.
Part way through writing this, I had a brief chat on #perl6 with
stevan (and apparently the meta-model is still quite in flux) and he
said my question was related to Larry's "class but undef" idea, and
that Larry should talk m
At 3:02 PM +0800 2/6/06, Audrey Tang wrote:
On 2/6/06, Darren Duncan <[EMAIL PROTECTED]> wrote:
Speaking briefly, I would like it if Perl 6 provided a way for a
class (or role, or meta-class, etc) to declare that all variables
declared to be of that type are automatically/implicitly se
ve in other languages and environments when in
Perl 6.
Unless we have this feature, I would have to resort to either storing
all symbols in hashes, or hex-escaping them all to ensure useable
characters without name collisions, and that makes the resulting code
obfuscated and hard to understand; I don't want to obfuscate.
Thank you. -- Darren Duncan
I'll have to check that a test for the feature
exists, and add one if not.
-- Darren Duncan
.language show the duplicates.
This message can also test if the problem is persisting. -- Darren
Duncan
at we need is a more universal currency. I suggest gold.
So every relevant symbol name could start with
'Au' instead of '$', and an advantage of this is
that it is still easy to type on any keyboard.
-- Darren Duncan
s are improvements. -- Darren Duncan
a generally useful and
simple-ish data type to include in Perl 6 itself, while "Rosetta" is
a third-party toolkit for application building.
-- Darren Duncan
At 8:28 AM -0400 4/21/06, Will Coleda wrote:
Fresh SVN checkout of pugs (Revision: 10048)
Try it again. When I updated last night, the current version was
r10054, and it compiled on my 10.4.6 system just fine. -- Darren
Duncan
n associated value.
If such a new type is created, it could potentially be named
MutableSet, though that would break the pattern of built-in types
having one-word names, but I haven't thought of any alternatives so
far.
Thank you. -- Darren Duncan
At 7:38 PM -0700 4/27/06, Larry Wall wrote:
On Thu, Apr 27, 2006 at 01:10:05PM -0700, Darren Duncan wrote:
: 1. There doesn't seem to be an immutable bit-string type, so unless
: I read something wrong, I propose adding one.
:
: Since all built-in types have one-word names, I suggest
s possibility on some arbitrary basis like with your list
makes as much sense as taking several things larger than a bit and
saying that some are atomic while others aren't.
-- Darren Duncan
7;z'=>5); # fails
Or:
$t = tuple( set( 'x'=>Int,'y'=>Int ): 'x'=>2,'y'=>4 );
$t = tuple( 'x'=>2,'y'=>4 );
If we have an actual relation-land Tuple type, then Mapping can be
kept a lot simpler and/or the way it is now.
I'm inclined to rule out the Signature and Capture types to be used
here, since while they have some similar properties to what I'm
looking for (a Relation header could be a Signature and its body a
set of Captures), they seem function specific. But maybe you think
differently?
So, any answers to my questions and/or feedback on my ideas is appreciated.
Thank you in advance.
-- Darren Duncan
on types such as Sets.
If Perl 6 is to be the choice language of the singularity, it needs
to be easy and fast to do any common type of work with it, and
relational algebra is an extremely common kind of work being done.
-- Darren Duncan
Actually, I'll add a few more things to my reply, which should be helpful ...
At 5:11 PM -0700 5/4/06, Darren Duncan wrote:
At 10:51 AM +1200 5/5/06, Sam Vilain wrote:
>Moreover, the Relation type has these
operators that the Set type doesn't have: rename(), project(),
restr
best.
For now I'll just follow the simple path with a single Relation class
in Pugs' ext/Relation/ directory for demonstration purposes and
evaluate changes later.
-- Darren Duncan
s
reasonable "do" (appropriately restricted versions of) them; if
people have disagreements, its mainly with that sub-suggestion that I
want to know about them.
Thank you. -- Darren Duncan
At 3:06 PM +0200 5/6/06, mAsterdam wrote:
Prompted by Darren Duncan's proposal on Relation type objects
I looked at http://dev.perl.org/perl6/doc/design/syn/S06.html
and wondered how Interval type objects would fit in.
I couldn't imagine how. Now that isn't a surprise
(
looking for.
-- Darren Duncan
anges or collections. Temporal or
spacial data in common use today is just too complicated and
non-generic, I think.
(Whereas, the existing built-ins, and relations, are very generic and simple.)
-- Darren Duncan
x; has Real $y; };
subset Interval of Range where { all( .items ).does(Real) };
-- Darren Duncan
At 6:06 PM -0700 5/6/06, Darren Duncan wrote:
You can do it simply, kind of like this:
class Point { has Real $x; has Real $y; };
subset Interval of Range where { all( .items ).does(Real) };
Er, you should read 'Real' as 'Num' (I originally meant Rational,
which no
sides of the hyper-operator?
So I would appreciate if the S03 examples could be explained as to
why they would work, or alternately please replace 'Bag' with 'Seq'.
Thank you. -- Darren Duncan
Er, I meant to say "subtracted" where I said "added". -- Darren Duncan
At 4:11 PM +1200 5/23/06, Sam Vilain wrote:
Darren Duncan wrote:
$bag1 >>-<< 1; # Bag(2,7,[1,Seq(8,2)],7)
$bag2 >>-<< (1,1,1,1); # probably the same
> $bag3 >>-<< (1,1,2,1); # ?
Bag's won't .does(Array) or .does(Coll
ething more interesting on the horizon, like perhaps an RDF storage?
-- Darren Duncan
l of Synopsis
12.
I'm fairly sure the "self" syntax is invalid.
Moreover, S12 explicitly says that Perl 6 has no barewords, save
package names in specific circumstances.
-- Darren Duncan
At 1:45 PM +1000 5/29/06, Stuart Cook wrote:
On 5/29/06, Darren Duncan <[EMAIL PROTECTED]> wrote:
There are many places where the bareword "self" is used, whereas I
believe the current syntax is "$?SELF" for the same thing, and has
been for awhile.
Actually, I s
ooking at you.)
Particularly, anything complicated and/or in an open-ended domain
should be separate on CPAN. Modules for talking to databases (DBI),
web servers (CGI, LWP), processing complex things like dates and
times (DateTime), and various other external things should remain
separate.
-- Darren Duncan
cases of multiple processes or threads, but they can
easily be added onto what I stated, which is also useful when there
is just a single process with a single thread.
-- Darren Duncan
ntee successful completion before it
returns control, the invoker should know that vs when completion is
guaranteed.
In other words, an invoker of an op should know whether the op is
ACID compliant in all parts of its operation or not.
-- Darren Duncan
eemed to me that the enum seemed to be
operating like a C enum, where every value corresponds to a native
integer, so perhaps "buf" is more appropriate. Or alternately, we
should see "Int" and "Str" here.
-- Darren Duncan
me};
Will this work to make a Set that can only have non-empty strings as members?
9. If you declare a parameter of a type that does Foo, and you pass
an argument that is a different type that does Foo, but neither of
them is of type Foo, will the compiler accept the binding (though it
may fail at runtime)?
Thanks. -- Darren Duncan
t
above be accomplished prior to that, so that Pugs 6.28.0 and later
are slimmed down and don't contain the shared components. The Pugs
only distro will probably feature what is in src/ now and what is
needed to support that. Audrey suggested separation before OSCON,
even.
Of course,
At 6:25 PM -0700 7/8/06, Darren Duncan wrote:
At 8:32 PM -0400 7/8/06, Joe Gottman wrote:
I have one minor comment about join. You should specify its behavior when
it is passed an empty list. Does it return undef or the empty string?
I think it makes the most sense for it to return an empty
of a string-join. -- Darren
Duncan
At 6:53 PM +0300 7/10/06, Gaal Yahas wrote:
On Sat, Jul 08, 2006 at 12:47:17AM -0700, Darren Duncan wrote:
As briefly discussed on #perl6 ...
As briefly replied there before being jethandled...
As further discussed there ...
Perhaps we need a baby-Perl Test::Simple for new
yeah!
If a virgin car-pool arrangement works out, I will be travelling to
OSCON (for just the no-cost hallway track) on Sunday the 23rd (so
maybe catch the end of a sunday event) and back on Friday the 28th.
I mainly expect to do my hackathoning Monday to Thursday, with
whoever's there. -- Darren Duncan
C
channel for that, but most of us are in #perl6 anyway so I would
think that is easier.
-- Darren Duncan
else should be
used instead, something that isn't invoked when working with hash
keys.
I may have forgotten to raise something else, but there's that for now.
-- Darren Duncan
the immutability, and all objects of the same
class would be the same in that respect. Incidentally, your Currency
example would likely be an immutable type. -- Darren Duncan
recommend having negated versions of all these various types of
equality tests. Eg, !== for ===, nev for eqv, etc. They would be
used very frequently, I believe (and I have even tried to do so), and
of course we get the nice parity.
-- Darren Duncan
I think that Jonathan meant for his reply to my message to go to the
list, so I am including it in its entirety, in my reply.
At 11:23 PM -0700 7/13/06, Jonathan Lang wrote:
Darren Duncan wrote:
Jonathan Lang wrote:
So the purpose of === is to provide a means of comparison that doesn&#
sary. The above-stated rule would still stand for any resources
managed by Perl itself.)
-- Darren Duncan
At 12:30 AM -0700 7/14/06, Darren Duncan wrote:
If $a === $b means what I think it does, then I believe that a
not-premature implementation optimization of === would be that it
always $a := $b if it was returning true, so that any future === of
$a and $b or aliases thereof could short-circuit
At 9:22 AM -0700 7/14/06, Dave Whipp wrote:
Darren Duncan wrote:
Assuming that all elements of $a and $b are
themselves immutable to all levels of
recursion, === then does a full deep copy like
eqv. If at any level we get a mutable object,
then at that point it turns into =:= (a trivial
matter whether you have $x and $y or $y and $x, the result is the
same. So you can use whichever order you want without it needing to
be coded for. -- Darren Duncan
At 12:55 PM -0700 7/14/06, Larry Wall wrote:
On Thu, Jul 13, 2006 at 10:56:59PM -0700, Darren Duncan wrote (edited):
: Now, I didn't see them yet anywhere in Synopsis 3, but I strongly
: recommend having negated versions of all these various types of
: equality tests. Eg, !=== for ===, !eq
it is just like ||, which takes any kind of values as
input, but that the latter returns the first actual value of the
first 2 arguments, while the former doesn't. The || comparison
suggests that maybe ?| belongs with the tight-or operator set rather
than bitwise. It might help if some of this was clarified. Part of
the confusion though is that ?| isn't in the operator precedence
table.
-- Darren Duncan
$z.aliases -> $z_alias {
$z_alias := $y;
}
# now $x and $y and $z all point to 'bar'
Unless something like this could be available for use, it would be
impractical to implement run time folding just using := since we
could end up in a tug of war situation if folding comparisons between
pairs drawn from a pool of all equal elements were not done in
exactly the right sequence.
-- Darren Duncan
result elements and produces derived ones.
-- Darren Duncan
taking a single parameter of type Dog.
Typo: Shouldn't that last line better say either "having a single
parameter" or "taking a single argument"? -- Darren Duncan
o be the
best compromise.
So, stepping aside from any "it ain't broke" arguments in the favor
of Str, is there anything about the name Text that makes it a worse
or better candidate in regards to specificity or ambiguity in your
mind?
Or alternately, are there any other names which might work better
than Str for specifying character data?
-- Darren Duncan
At 5:25 PM -0700 8/8/06, Darren Duncan wrote:
I'm wondering if it would not be inappropriate to change the name
Str to something more descriptive of its content within the
historical or current wider context.
For example, would the name Text be any worse? In my mind, that is
less ambi
le once created. There would exist
operators to convert between a Blob and various Str representations
for transmission of the data through a text-only medium, such as
hexadecimal or octal etc.
Truly, a Blob type should be a very natural addition, and a final
missing link in some respects.
Thank you in advance.
-- Darren Duncan
ated like Num or Str
etc in that === always compares them by value. -- Darren Duncan
I never thought to ask for.
And of course, the actual implementation is a lot better, with all
the various command-line options|args being mapped to normal Perl 6
args in an easy to understand and powerful way.
The default USAGE() sub was a great idea too.
I am SO going to use this.
-- Darren Duncan
it in the open with the same separators as
what is used to separate the authority from the version etc.
-- Darren Duncan
rsions they run
under.
-- Darren Duncan
At 10:35 AM -0600 8/13/06, David Green wrote:
On 8/8/06, Darren Duncan wrote:
I thought your reasons made sense, and would be happy with a "Text"
type, although I don't especially object to "Str" -- as you say,
it's probably good enough given ordinary progra
oint in time
when it executed.
It is important for some applications to distinguish whether the
result of an equivalence test will be valid eternally or not, and
hence we have multiple analagous types and multiple equality tests,
where pairwise they distinguish eternally vs snapshot. We can say
exactly what we mean, and it is unambiguous, which is a GOOD thing.
-- Darren Duncan
At 11:42 AM +0300 8/16/06, Markus Laire wrote:
On 8/16/06, Darren Duncan <[EMAIL PROTECTED]> wrote:
The difference between === and eqv is that, if you have 2 symbols, $a
and $b, and $a === $b returns true, then that result is guaranteed to
be eternal if you don't assign to ei
At 11:16 PM -0600 8/16/06, David Green wrote:
On 8/15/06, Darren Duncan wrote:
At 2:51 PM -0600 8/15/06, David Green wrote:
[...]
You are right, but we have both Seq and Array types, so depending
which one you use, you want either the === or eqv operators to do
what you want. There is no
lared in
a file not named "Mammal". Even then, I don't know if this implicit 'use'
action would be a good idea, as it may be a source of bugs. -- Darren Duncan
;t subclasses.
4. We need to be able to programmatically define accessors and
constructors for new classes/classless-objects too, unless those come
for free when we declare attributes public-ish.
--
In closing for now, I imagine that a lot of this stuff is connected
to the meta-model, though doing it well will have clean support in
the language syntax as well.
Feedback is appreciated.
Thank you. -- Darren Duncan
On Wed, 30 Aug 2006, Nigel Hamilton wrote:
> HI Darren,
> Generally I really like the idea of fixing the relational/OO
> mismatch problem by swallowing the relational model whole. :-)
> But I wonder if we are ready to say goodbye to the tyranny of disk
> seek? How wil
hat the
relational analogy of an in-memory Hash is built-in to Perl, and any
extensions that make it tied to something external like a disk be
language extensions / CPAN modules; all Perl 6 iteself has to do is
make it easy to attach such extensions, and I think it more or less
does so, save edge cases to hash out.
-- Darren Duncan
est don't look like valid UTF-8.
So CGI.pm for Perl 6 can resemble the Perl 5 version, but in no way
should we retain backwards designs just because that's they way they
were before. So keep all input information and standardize on
Unicode.
Thank you in advance.
-- Darren Duncan
with my current database-centric modules (where I'm more certain they
can have a big impact). However, I'm sure the web modules can
influence improvements to CGI.pm in Perl 6, and I will do so at an
appropriate time.
-- Darren Duncan
server-side view of web client input and output.
In fact, it may borrow a few pages of design from LWP if applicable?
-- Darren Duncan
much more understandable as to what it does.
It should also help me to implement some aspects of Set::Relation, maybe.
Thank you for this update.
-- Darren Duncan
u can see, there is a repeated inconsistency here as to the name
of this meta-object method. While it is possible that the actual
meta-object API hasn't been decided on yet, the stand-in Synopsis
examples should at least be consistent. -- Darren Duncan
At 5:00 PM +0100 9/13/06, David Cantrell wrote:
On Tue, Sep 12, 2006 at 03:08:03PM -0700, Darren Duncan wrote:
> The word "CGI" generally speaks to an old, weak, and relatively
inefficient technology ... modern proper stuff does not spin off a
separate process for each serve
e, the Request/Response containers would
not have any ties to outside environment, though in specific cases
where input and output are too large to easily fit in RAM at once,
there can be enhancements.
-- Darren Duncan
t clear to me what the general rules for
delimited identifiers are as contrasted with literal strings, and in
particular, whether any leading sigil is supposed to go inside or
outside of the delimiters.
-- Darren Duncan
At 4:26 PM -0700 9/15/06, Larry Wall wrote:
On Fri, Sep 15, 2006 at 03:27:40PM -0700, Darren Duncan wrote:
: As I recall, we're allowed to put absolutely any characters we want
: in an identifier if it is a delimited identifier rather than a
: bareword identifier.
I have no clue what you
At 7:38 PM +0200 9/16/06, A. Pagaltzis wrote:
* Darren Duncan <[EMAIL PROTECTED]> [2006-09-09 20:40]:
4. Make UTF-8 the default HTTP response character encoding,
and the default declared charset for text/* MIME types, and
explicitly declare that this is what the charset is. The only
generally or specific to an implementation, a Tuple's
class name doesn't matter, but just what its attribute names and
types are what matter.
Thank you for any feedback and help. A proper Perl-saavy
Set::Relation implementation is much closer to reality if I can get
these issues solved and implemented in practice.
-- Darren Duncan
tually
happening, and as well, it strongly resembles the english statement
for what is happening.
If we want to keep .grep too, it should be an alias, like != is an
alias to !==, but I think letting people use "where" instead would be
a very good thing.
-- Darren Duncan
At 3:36 PM -0700 9/18/06, Trey Harris wrote:
In a message dated Mon, 18 Sep 2006, Darren Duncan writes:
I suggest that it might be appropriate to rename the .grep list
operator to .where, so we can say, for example:
@filtered = @originals.where:{ .foo eq $bar };
Note that this can be
we ought to change it to "filter".
I agree. So "filter" is now my preference for a new name, and if
"grep" is kept, then that can be an alias for it; "filter" should be
the canonical name for most documentation, though. -- Darren Duncan
1 - 100 of 632 matches
Mail list logo
