Jonathan Worthington wrote:
On 30/09/2010 21:38, Darren Duncan wrote:
Mark J. Reed wrote:
Of alternatives you didn't mention, I like put - as pithy as get
and set, with plenty of corresponding history (SmallTalk, POSIX,
HTTP,...).
Actually, *yes*. I didn't think of this one at the time
Moritz Lenz wrote:
Darren Duncan wrote:
I think then that .perl needs to be updated so it is more expressly limited and
only works on some objects rather than on all of them.
The way I see it, .perl is mainly about representing *value* objects in a
serialized form, and what it should produce
to a user on a single core machine. I think that Perl 6's implicit
multi-threading approach such as for hyperops or junctions is a good best first
choice to handle many common needs, the last list item above, without users
having to think about it. Likewise any pure functional code. -- Darren Duncan
is a set, does that mean that a list only contains/returns each
element once when iterated? If a list can have duplicates, then a list isn't a
set, I would think. -- Darren Duncan
or alternately returns an empty junction (a junction
ranging over zero values)? Or would that instead better be treated as an error
such that returning nothing should have been done explicitly? -- Darren Duncan
or array of string argument. -- Darren Duncan
agree though with the principle that sets and bags should be just as easy
and terse to use as arrays.
-- Darren Duncan
like it.
-- Darren Duncan
Jon Lang wrote:
Darren Duncan wrote:
This said, I specifically think that a simple pair of curly braces is the
best way to mark a Set.
{1,2,3} # a Set of those 3 elements
... and this is also how it is done in maths I believe (and in Muldis D).
In fact, I strongly support this assuming
for every power of 2 between
1 and 4, rather than skipping one.
Even more important, with blob literals, we have an 0a form for every power
likely to be used period, since for all practical purposes they can only take
literals in powers of 2 anyway.
So, any thoughts on this?
-- Darren Duncan
, just not so conventional. -- Darren Duncan
Larry Wall wrote:
On Tue, Nov 16, 2010 at 12:11:01PM -0800, Darren Duncan wrote:
: Carl Mäsak wrote:
: Darren ():
: While I haven't seen any prior art on this, I'm thinking that it would be
: nice for a sense of completeness or parity to have an 0a syntax specific to
: base-4 that complements
we pick, maybe there should be suitable generic names given
to the complementary concept of what I mentioned.
-- Darren Duncan
To clarify, by define particular methods I mean that said 2 roles would
require composing classes to define them, not to include the code themselves. --
Darren Duncan
Darren Duncan wrote:
I think that Instant and Duration should simply be declarational
roles that don't have any implementation
stuff like this
that led to us getting a Temporal spec that made sense and could be
implemented.
// Carl
How so? All I'm proposing is having top level markers that aren't too
constraining, but everything specced below that can be quite specific and
implementable. -- Darren Duncan
.
On a side note, you shouldn't name things all uppercase since those are reserved
for use by Perl itself; just say select.
-- Darren Duncan
I come up to the following code:
my $db = FakeDBI.new;
my ($state, $dept) = active storage;
my @out := $db.SELECT
the component words, so to evaluate those components, rather than looking at
words as just entire strings delimited by non-alphanumeric characters.
Not applicable everywhere, but useful in some places.
Of course, this would be an extension feature, not a core feature.
-- Darren Duncan
I agree with the change. Let try be for exceptions and eval be for runtime
compile+run of code. These are very distinct concepts and should be separate.
-- Darren Duncan
Stefan O'Rear wrote:
I intend to change the definition of eval such that it does not catch
exceptions. String eval's
mutability with syntax, or only allow what references point
to to change.
-- Darren Duncan
Patrick R. Michaud wrote:
On Sat, Aug 20, 2011 at 04:41:08PM -0700, Darren Duncan wrote:
I believe the general solution to this problem is to make all
objects immutable, with the only exception being explicit
references, and so mutating an object isn't an option; rather you
have to derive a new
the time, you will see it run.
-- Darren Duncan
are typically in a -quoted context, and we also
don't see symbolic bareword operators in the same place. Apples and oranges.
-- Darren Duncan
Tom Christiansen wrote:
Darren Duncan dar...@darrenduncan.net wrote on Wed, 24 Aug 2011 11:18:20 PDT:
I oppose this. Underscores and hyphens should remain distinct.
That would seem to be the most human-friendly approach.
I disagree. More human friendly is if it looks different in any way
So I guess we have a rare failure of a spam filter. -- Darren Duncan
this for the parsing portion, but I'm wondering
about the rest. (Maybe the all-Perl-6 version would also eventually be able to
produce the fastest running Perl 6 programs too, because it is easiest to write
Perl 6 analysers/optimizers/etc in, corresponding to PyPy as I understand it.)
-- Darren Duncan
that the generic set was probably the best candidate for Foo. But
there might be something better.
Any pointers to precedents on what to use for Foo and how are greatly
appreciated.
-- Darren Duncan
On 2013.11.17 3:48 PM, Darren Duncan wrote:
Thanks a lot to Andrew, John, Raiph, and any later responders. What you've said
so far looks very useful to me, and I will follow up on the leads you gave. --
Darren Duncan
FYI, as of last night I'm intending to use generic ordered lists rather than
I notice from looking at http://design.perl6.org/S02.html that Blob is listed
both as being a role and as a type. See http://design.perl6.org/S02.html#Roles
for an example of the former, and
http://design.perl6.org/S02.html#Immutable_types for an example of the latter.
-- Darren Duncan
On 2015-02-21 2:45 AM, Moritz Lenz wrote:
Hi Darren,
On 21.02.2015 08:51, Darren Duncan wrote:
I notice from looking at http://design.perl6.org/S02.html that Blob is listed
both as being a role and as a type. See http://design.perl6.org/S02.html#Roles
for an example of the former, and
http
Also, there are other newer API docs than the Synopsis that are useful for
study, but printing all this stuff seems very excessive, even more so because
the Synopsis etc keep changing. I advise against printing this stuff in bulk.
-- Darren Duncan
On 2015-05-15 7:54 AM, Elizabeth Mattijsen
of core. Exact rationals are not particularly
complicated. Its perfectly reasonable to expect in the core that if someone
does math that is known to deal with irrationals in general, that loss of
precision then is acceptable.
-- Darren Duncan
how
its done.
Thank you.
-- Darren Duncan
:auth etc. Note that I
raised this question on #perl6 myself shortly before writing perl6-language, but
the email version is better organized. -- Darren Duncan
On 2015-06-10 11:38 PM, Tobias Leich wrote:
Hi, that is a very interesting use case, and IMO a very valid one.
Currently
will get the current behavior with
:D not being default.
I say, save any further major breaking changes before this Christmas for things
that would be really hard to change later and are sure to be worthwhile now, and
the :D thing is not one of those.
What do you think?
-- Darren Duncan
O
.
I mean, this situation seemed to be a solid example of why Perl 6's versioning
scheme exists in the first place, to deal elegantly with things like this.
-- Darren Duncan
silently actually expect Perl 6.0.0.0 semantics. We're always going to be
stuck with this problem if we don't make declarations mandatory now. That's a
much more important change to ingrain into those several hundred existing
modules, if they aren't already, nevermind the :D thing. -- Darren Duncan
. -- Darren Duncan
On 2015-10-13 1:52 AM, Richard Hainsworth wrote:
Following on the :D not :D thread, something odd stuck out.
On 10/13/2015 03:17 PM, Moritz Lenz wrote:
But hopefully none of them breaking backwards compatibility on such a large
scale. The last few backwards incompatible
tudy for whether there is truly a good reason for the code
to work that way, or if there isn't. Keep in mind that the standard libraries
are right now some of the primary examples Perl 6 developers would have to look
at on how to write Perl 6 code. -- Darren Duncan
6 with a PSGI/Plack
inspired design, meaning a no-mandatory-shared-code database interface:
https://github.com/muldis/Muldis-DBI-Duck-Coupling-Perl6/blob/master/lib/Muldis/DBI/Duck_Coupling/API.pod
-- Darren Duncan
are the thoughts on this? Can we get appropriate improvements into Perl
6d and implementations etc? Also, is any of what I said actually already done?
Certainly some key parts at least are not.
Thank you.
-- Darren Duncan
On 2016-10-30 4:11 PM, Darren Duncan wrote:
On 2016-10-30 5:45 AM, yary wrote:
Before/AfterEverything are also easy to understand, and would be as natural to
use for sorting strings, eg. for saying if a database NULL should go before the
empty string or after everything else. On the other hand
ctually lose the family thing.
For documentation/marketing materials and to help with continuity, we can
typically reference "the Rakudo language, a sibling of Perl", where the latter
part is then more of a description.
This is what I really think should and that I would
-language-name-for-perl6-goes-here (tm)
-- Darren Duncan
features, and in that
case they WOULD be normal arguments or return values. And so the regular type
system still needs to support having anything at all as an argument or return
value. -- Darren Duncan
401 - 444 of 444 matches
Mail list logo
