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
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
$_.} };
Whereas, the "restrict" is like a grep; eg:
my @restriction = @original.grep:{ $_.{'a'} eq 'foo' };
Suffice it to say that, along those lines, there are 4 terms.
The actual syntax of RM "restrict" is more like "grep" than the other 3.
But that doesn't have to matter for us. We don't have to use the
same words as domain-specific languages to name an operation, but a
name that works well in english is very helpful.
-- Darren Duncan
his isn't causing another homonym problem, ...
How about "pass" as a new name; eg:
@filtered = @original.pass:{ };
I don't think that this in any way suggests modifying the original.
-- Darren Duncan
implement the Junction in the first place, we
can't use all/any/one/none etc in the definition.
-- Darren Duncan
At 8:13 PM +1200 9/26/06, Sam Vilain wrote:
Darren Duncan wrote:
> Within a system that already has an underlying
set-like type, the Junction in this case, a test
for uniqueness is (pardon any spelling):
all(@items).elements.size === @items.size
The all() will strip any duplicates,
27;m looking for).
An archive for many Perl mailing lists already exists at:
http://www.nntp.perl.org/group/
You should be able to use this to seed yours.
-- Darren Duncan
At 4:08 PM +0200 10/10/06, TSa wrote:
HaloO,
Darren Duncan wrote:
Within a system that already has an underlying set-like type, the
Junction in this case, a test for uniqueness is (pardon any
spelling):
all(@items).elements.size === @items.size
The all() will strip any duplicates, so if
class is immutable, and add_vertex() will create and
return a new Polygon object with those properties, and the original
is still the Rectangle.
-- Darren Duncan
rt first or last. I don't see the reduce
meta-operator as being applicable to this, since reducing using
less-than eg, will return a boolean result. Unlike, say, 'avg' or
'sum', 'min' and 'max' are conceptually generic to all ordinal types.
So, is this workable?
-- Darren Duncan
ally can .does(), and only those have <, >, <=, >=, <=>, min,
max, sort, etc, there is the question about how to handle types that
don't .does() Ordinal in some generic situations. Either they fail,
or there is some sort of fallback provided by Object, such as they
end up sorting on their memory addresses; but in the latter case, we
don't need an Ordinal role because every type will be doing it in
some fashion or other due to Object's defaults.
Tangentially related, I'd like to suggest that the negation
meta-operator be generalized from comparison operators to any binary
operator that returns a boolean value (or possibly even to any
operator that returns a boolean value, so that '!?$x' would mean
"coerce to boolean, then negate its value").
If I'm not mistaken, the negation meta-operator already does this.
-- Darren Duncan
ty.
4. Eliminate the alphabet soup and related ugliness.
5. Better huffman coding because most people will
want to sort their values by their native types;
people normally want to sort Str as Str and Num
as Num, and plain == etc will do that. I don't
see any use of weak types as reducing the
benefits either.
6. In my mind, bit shifting is a less commonly
coded activity, so making those ops a bit longer
shouldn't hurt anything.
-- Darren Duncan
it.
5. It would help simplify my implementation tasks if all the built-in
Perl 6 types had multis for their operators such that the operators
could all be invoked exclusively with named arguments, even if there
is just 1 argument. Though if you don't want to do this, then its
not a big deal, and I'll just subclass them with wrappers that do
provide such.
Thank you in advance for any consideration or feedback.
-- Darren Duncan
At 11:00 AM -0500 11/13/06, Mark J. Reed wrote:
On 11/13/06, Darren Duncan <[EMAIL PROTECTED]> wrote:
- There are no Undef or NaN etc values or variables.
A RDBMS language with no "null" would seem to be problematic..
although i guess you could just use 1-tuples where th
At 11:24 PM + 11/13/06, Smylers wrote:
Darren Duncan writes:
> 1. I'm not sure if it is possible yet, but like Haskell et al ..., it
should be possible to write a Perl 6 routine or program in a pure
functional notation or paradigm, such that the entire routine body is
tes. Once again, you can then
compare the value lists of 2 Hashes set without
sorting them. Still, regardless of what you do
here, making .keys return a Set should be done.
-- Darren Duncan
?
Repeat again with Bag->Seq.
In my mind, it would be far simpler to reserve such operators to the
Set only, and cast a Bag|Seq as a Set to use them on it, if that is
desired whereupon the results are all distinct.
But still, it is something that should be decided on, one way or the other.
-- Darren Duncan
);
# Bag(2,3,3) or Bag(3,3) ?
Bag(1,2,2,2,3,3) d_union Bag(1,2,2,4,4);
# Bag(2,3,3,4,4) or Bag(3,3,4,4) ?
Repeat again with Bag->Seq.
In my mind, it would be far simpler to reserve such operators to the
Set only, and cast a Bag|Seq as a Set to use them on it, if that is
desired whereupon the results are all distinct.
But still, it is something that should be decided on, one way or the other.
-- Darren Duncan
dered disjoint_union to mean exactly the same thing as
symmetric_difference, meaning an analogy to XOR. Still, Wikipedia
says they are different, and its
http://en.wikipedia.org/wiki/Symmetric_difference article describes
the meaning I had been attributing to both. So what I was really
asking was:
Bag(1,2,2,2,3,3) symmetric_difference Bag(1,2,2,4,4);
# Bag(2,3,3,4,4) or Bag(3,3,4,4) ?
-- Darren Duncan
f the value of that Num is a whole number.
So taking the semantics of Int vs Num that users see as examples for
how Set vs Bag semantics should work, as far as argument and result
types go, makes a lot of sense, and is easily to implement with Perl
6 multis.
-- Darren Duncan
would be
too.
-- Darren Duncan
mple stand-in for some arbitrary user-defined type. -- Darren
Duncan
accounts for many
aspects of the relevant problem space. -- Darren Duncan
o not understand the rationale to make any further changes as you
have described above.
Please clarify benefits of what you are debating to change, maybe
with use case examples.
-- Darren Duncan
he difference of semantics would be the
same as with the Hash; a %foo = %bar would copy all the elements,
while $foo = $bar would not.
-- Darren Duncan
/Int::Mod/Num::Div/Num::Mod instead), but I hope you get the
point of what I was saying.
-- Darren Duncan
dle *everything* with the
language.
Really, dealing with non-integer numbers properly deserves,
conceptually or actually, a separate component or several just for
them, as per unix philosophy of dedicated pieces doing what they do
well.
I hope this proposal makes sense.
-- Darren Duncan
"avoid bloat", but give it its own space.
I hope that helps.
-- Darren Duncan
At 9:57 PM -0700 1/4/07, Doug McNutt wrote:
At 18:23 -0800 1/4/07, Dave Whipp wrote:
Darren Duncan wrote:
For example, the extra space of putting them aside will let us
expand them to make them more thorough, such as dealing well with
exact vs inexact, fixed vs infinite length, fuzzy or
section mention Superset as it does Subset,
like the top quoted section already does with this update?
-- Darren Duncan
the reverse. This
is all assuming that the purpose of .does is to indicate when values
of one type can be substituted for values of another type.
Similarly, if there is no .does relationship between Int|Num and Str,
due to what .does is actually for, then there shouldn't be one
between Int and Num.
-- Darren Duncan
At 12:32 AM + 1/23/07, Smylers wrote:
Darren Duncan writes:
For round-trip consistency, a generic non-formatted num-to-char-string
operation should include a .0 as appropriate if it is converting from
a Num, whereas when converting from an Int it would not.
So this (in Perl 5
perl() produces some long-hand like "Int(1)"
or "Num(1)", then it won't matter whether it is "Num(1)" or
"Num(1.0)" etc.
-- Darren Duncan
cause
explicit chunking.
Eg, smooth:
map { $_, $_ * 10 }, 1..3
Vs chunky:
map { [$_, $_ * 10] }, 1..3
-- Darren Duncan
, people should be able to call floor() etc explicitly if
they want to make their Num->Int conversions explicit rather than
implicit. -- Darren Duncan
s, and is easy to learn
for both Perl 5 people and people coming from other languages.
Also importantly, it should prevent common types of errors.
If being more terse is important, you could further abbreviate .head
and .tail, but the main point is that a plain -N array index never
means count from the end.
-- Darren Duncan
e or less it.
Its possible that additional operators may be useful, but I haven't
thought them through yet. (Also, some relational operators don't
make sense just applied to individual tuples, and so they aren't
mentioned above.)
Any feedback is appreciated. Including both appropriate names for
the semantics of the operators I mentioned, and/or comparably very
concise syntax for doing the same with existing Perl 6 operators.
Thank you. -- Darren Duncan
;t even look the same visually.
But once again, the functions|operators can have different names.
At 6:22 PM + 2/27/07, Smylers wrote:
Darren Duncan writes:
> I believe that ... some common relational operations would be a lot
easier to express if Perl 6 had a few more operators that ma
said, I suspect
that either a wraparound or an overflow code is what you'd get, and
not a type upgrade. -- Darren Duncan
e numeric-casting == will do what you want either.
-- Darren Duncan
P.S. Sorry for not replying to this for so long, but I have been without
a computer for the last week ... and possibly for the next week too ...
right now, I'm on someone else's machine.
--
On Wed, 7 Mar 2007, Smylers wrote:
> On February 27th Darren Duncan writes:
&
So if a short-hand syntax
existed, it would be replacing more complicated code than that. -- Darren
Duncan
errors,
similar to referencing an undeclared symbol name.
Or maybe have separate versions for strict or non-strict behaviour, or a
pragma that toggles such, as is appropriate.
-- Darren Duncan
at that project will help to explain a lot
of what I'm trying to get at more than my own explanations, probably.
-- Darren Duncan
f
+the infix operator will be the variable's prototype object:
Typo: "instea dof" instead of "instead of".
I didn't notice any other unresolved typos in the last 2 weeks' worth
of synopsis updates.
-- Darren Duncan
k are not the
same thing?
-- Darren Duncan
$bar = $foo; # copy by reference
@$bar = @$foo; # copy by value
Actually, I think that would be a vast improvement, as we could then
use the @ prefix with any collection type as short-hand to say that =
is copy by value.
I also don't think the language would feel any less Perlish with
At 5:00 PM -0700 5/14/07, Darren Duncan wrote:
On the other hand, unless this steps on something, I could suggest
dropping the @ and % anyway, so we have $array and $hash, and then
we could instead use the @ and % sigils as a prefix to indicate in
that case that we want them to copy by value
ich stays immutable. We wouldn't want to lose that ability.)
Um, yes, so thank you all who assist in solving this problem.
-- Darren Duncan
---
[ 11:42pm ] dduncan : given that afaik it is best practice when
declaring parameter types or testing argument types that .does() is
used
ypes that could typically bind to each of the sigils (and
everything can bind to $).
Larry thought that perhaps S02 would be the place for it.
In conclusion, I retract my previous suggestion of just using $ where
we used to use @ and %.
-- Darren Duncan
into
an array, but if it doesn't have meaning besides this, in the general
case. Same as all does Str or all does Bool et al.
-- Darren Duncan
the same as Any $foo.
There is no type called Any; that is just a flag for when you accept Object.
Or so I was thinking.
If the actual situation is different, please say how.
-- Darren Duncan
does. We're using "any"
more in that "any of a restricted set" sense than in the "any of
the universal set" sense.
Now that I've heard the explanation of what Any means, I also have no
objection to continuing to use that, such that Any is the complement
of Junction under Universal/Object.
-- Darren Duncan
ail.
If it is true that int et al (ignoring autoboxing) is not conceived
of as an object by users, that reinforces the idea that Universal
sounds more like "everything" than Object does.
-- Darren Duncan
.
After this change, the term Hash is then freed up to be used more
specifically to describe an implementation detail of something and/or
hashing functions et al.
I think this change would be a good thing.
Feedback is appreciated, either pro or con.
-- Darren Duncan
iated matter now. -- Darren Duncan
nfused with pod, which is always not indented.
Simple.
And since Perl 6 does consider whitespace significant sometimes, this
is not unprecedented.
-- Darren Duncan
s benefit, and to
save me from repeating the same answers ad nauseum. Unless the
response is not suitable for public discourse, in which case, sure,
go private email; ditto if you're not sure about appropriateness.
Thank you in advance.
-- Darren Duncan
the Pugs repo since Feb 17th. Actually, see
http://svn.pugscode.org/pugs/ext/HTTP/docs/ first, which is a copy of
the important emails by Juerd which the HTTP+Web were started from.
-- Darren Duncan
orry about now.
-- Darren Duncan
answer for
them. By contrast, the =:= operator always tests if 2 things are the
same object or not, even for those of value types. -- Darren Duncan
extensions should be in the core. Now, it may just so happen that
certain extension-installing tools might make use of XML-based
protocols to do their job, but that's beside the point; presumably
these would be very specialized and not support any aspect of XML
that isn't specific to
At 2:51 PM +0900 12/4/07, cdumont wrote:
Sorry.
Where can I find a mailing list that is about Perl 6 in general then?
Thank you.
I would recommend that [EMAIL PROTECTED] is the best place to talk
about these things, out of the official Perl 6 lists that I know of.
-- Darren Duncan
such as myself.
I for one can assert that both of these are being produced right now.
Also that neither is part of the Perl 6 kernal, though the kernal may
enhanced over time to better support them. -- Darren Duncan
At 10:23 AM +0300 12/11/07, Richard Hainsworth wrote:
Darren Duncan wrote:
At 9:04 AM +0300 12/10/07, Richard Hainsworth wrote:
Equally, Something to replace CGI or DBI will be essential to the
uptake of P6. I would far prefer to have a skilled and resourceful
professional, such as yourself
re be more confident that it is safe to use some optimizations.
-- Darren Duncan
y are very simple. But really, you know better to make
this call yourself, having more information on your circumstances.
-- Darren Duncan
P.S. Does anyone think that the main part of this email may provide
a starting point for a general best practices tutorial item or
Perl.com article?
27;nfd_codes' etc.
I'm glad to see, from your latest post, that this is how Perl 6
actually works as well. That .codes specifically works in terms of a
particular normal-form (either a specified one or a default one)
rather than the current implementation, and so makes this aspect of
Perl 6 a lot more deterministic while portable.
-- Darren Duncan
hows the numify in the order [-1,0,1], but the
Order values are not in the corresponding sequence.
To fix the problem, the S29 text should probably say:
returns |Order::Increase|, |Order::Same|, or |Order::Decrease|
(which numify to -1, 0, +1)
That way, reading the S29 text makes more sense.
This is, I believe, what Joe was pointing out needed to be fixed.
-- Darren Duncan
ence of mine,
as I prefer standardizing on prefix notation for all routine/operator
calls where possible. Still, I suppose I may not complain too loudly
if the change you suggest was made.
I'd be more interested in hearing what precedents if any exist in
this regard. What do other languages call the same concepts?
-- Darren Duncan
well as an open-ended problem.
A better use of this discussion is perhaps to determine whether any
more basic core features would need updating in order to support a
separate extension module to more easily provide the feature that was
being discussed.
-- Darren Duncan
particularly welcome change.
For one thing, it is now possible to have defined, deterministic
semantics while freeing a compiler to auto-parallelize the list
assignment, as the container assignments themselves are now uncoupled.
-- Darren Duncan
ation of simply rounding to lesser precision, not
necessarily just to integers.
Or maybe your question is more about what method to use by default if users
don't explicitly choose one?
-- Darren Duncan
(3,4,5) for example?
Are you just supporting that with all operators for parsing rule simplicity
as per a macro? I can understand that reasoning, but otherwise ...
I would think it makes sense to restrict the use of the reduction
meta-operator to just work over operators that are at least associative.
-- Darren Duncan
at or manipulates the environment is not an operator.
Most language built-ins would qualify as operators, including all pure
functions and ordinary assignment operators.
Built-ins that would not be operators include: print, curr_time, <$*STDIN> etc.
-- Darren Duncan
ets you do the right thing interface-wise while
remaining secure without contortions.
Everything I just said ignores the fact that you can always additionally
make public accessor methods for private attributes, to control/protect
limited access to them for the general public.
-- Darren Duncan
Perl 5 classes have to deal with this problem all the time as
all attributes and methods are actually public even if undocumented.
2. It would be very easy for anyone to defeat the security that the privacy
is supposed to give, without the class being exposed having any say about it.
-- Darren Duncan
erl 6 would be a one-element array|seq whose element is the
empty array|seq. That is,
[X] ()
equals this:
( () )
Larry et al, on a related note, the list of identity values for reduce in
S03 should be updated to account for this; [X] wasn't on the list last I
looked.
-- Darren Duncan
any
tuple T with a tuple having zero elements is the first tuple T.
Since the normal output of X is 2-dimensional, it stands to reason that
( () )
should be a reasonable identity value for X, I think.
-- Darren Duncan
llary".
Alternately, the word is spelled "niladic", which also has the advantage of
looking like "monadic", "dyadic", etc. -- Darren Duncan
ing-quoted, that feature should be enough
to let us use things like whitespace in names, so unquoted identifier names
should err on the side of being more strict and limited, I think. -- Darren
Duncan
as
users say "use Perl-6.0.0" their code relying on the older/current Test.pm
like interface won't break.
-- Darren Duncan
://portabler.blogspot.com/search/label/Corel%20Draw%2011%20Portable
-
- Coffe Cup Gif Animator (1)
-
http://portabler.blogspot.com/search/label/Coffe%20Cup%20Gif%20Animator
- CuteFTP (1)
- http://portabler.blogspot.com/search/label/CuteFTP
- Digital Object Rescue (1)
-
-- Darren Duncan
literals that equal the base in question; the current system is
still just as good, if different, and does not need replacing, and any
replacement needs exact syntax that won't confuse with other language
constructs like Pair literals or routine calls.
-- Darren Duncan
work.
If you are wanting to actually mutate a Dog in a user-visible way rather
than deriving another Dog, then I don't think that calling Dog a value type
is appropriate.
-- Darren Duncan
no reason to make floats an exception where
they aren't unlimited where integers and other rationals are; after all,
what is a float or scientific notation than just another notation for a
rational value literal.
-- Darren Duncan
nent is always -1 then your profile should be the same as a
numerator/denominator representation. By contrast, normalization for best
memory use would involve using as large a number as possible in the
exponent; ideally the radix would be small as possible, such as 2 or 10.
-- Darren Duncan
Darren Duncan wrote:
4.5207196*10**30 -> 45207196*10**37
Before anyone nitpicks, I meant to say on that line:
4.5207196*10**44 -> 45207196*10**37
-- Darren Duncan
units as additional attributes or metadata.
-- Darren Duncan
t would be exact and unlimited precision, and maybe Symbolic or
IRat or something would be the symbolic number type, also with exact precision
components.
Come to think of it, isn't "whatever" how Num is already defined? If so I think
that is clearly distinct from Rat.
-- Darren Duncan
, an inexact numeric sin() that results in an exact rational is just
a wrapper over the last 2 operations combined, and it takes rounding-control
parameters. I see no problem here. -- Darren Duncan
nction are as if it had; so eg that reduction could be
done lazily, just when the Junction is first used. -- Darren Duncan
e
definition of a Junction as "Set with additional behaviors" but the one()
constructor just excludes values that appear multiple times in its argument
list. In other words, one() *is* the same as any() except for the added filter.
-- Darren Duncan
common default value of a
boolean-typed argument is false. Naming something "case_sensitive" implies that
sensitivity is special whereas sensitivity should be considered normal, and
rather insensitivity should be considered special.
-- Darren Duncan
t; to get grapheme-insensitive comparisons.
But the grapheme abstraction level is generally what you want anyway since
character data is for humans and humans don't consider the various unicode
normal forms as distinct characters; they *display* with exactly the same glyphs.
Darren>> [This] implies that sensitivity is special whereas sensitivity
Darren>> should be considered normal, and rather insensitivity should be
Darren>> considered special.
I think Darren may be right, because even case-sensitivity is a real problem.
It sure is.
-- Darren Duncan
Tom Christiansen wrote:
In-Reply-To: Message from Darren Duncan <[EMAIL PROTECTED]>
There is ABSOLUTELY NO WAY I've found to tell whether these utf-8
string should test equal, and when, nor how to order them, without
knowing the locale:
"RESUME",
101 - 200 of 477 matches
Mail list logo
