lated 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
$new-language-name-for-perl6-goes-here (tm)
-- Darren Duncan
If we assume the use of NQP is part of the project's identity, then yes that
makes sense. Historically that wasn't the case, eg the earlier Rakudo were
written to Parrot PIR directly, and there's the possibility this could change
again, though I see that as unlikely. Not a bad
Bad idea. There should not be any number in the name, in any way shape or form.
No six, no ten, or any other. Differentiating factors should be something not
a number. -- Darren Duncan
On 2018-02-09 9:15 PM, Brent Laabs wrote:
Might as well follow Apple and Microsoft and call it Perl Ten
ajor releases (albeit skipping 6 to avoid confusion) just as
Postgres and many other projects do these days, as staying at 5.x forever is weird.
-- Darren Duncan
n't actually 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 wou
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
this email thread is
relevant to this thing that I'm working on, a DBI for Perl 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
So what 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
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
; but they
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
as release.
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
quot; etc 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
fault. -- 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 incompa
ose classes. They share the same method spaces.
Hey, that sounds like a nice elegant design, I learned something new. -- Darren
Duncan
, be part 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
: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 the
' that
isn't any less restrictive:
use Dog:auth:ver(v1.2.1..v1.2.3);
use Dog:auth:ver(v14.3..v16.2);
That is, the cross-product answer is not restrictive enough.
I don't know if this hypothetical use case has been discussed before, but if
not, I hope that the Perl 6 specifi
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
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
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 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 r
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
t 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
r 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
So I guess we have a rare failure of a spam filter. -- Darren Duncan
Tom Christiansen wrote:
Darren Duncan 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 then it is
diff
point out that those are typically in a "<>"-quoted context, and we also
don't see symbolic bareword operators in the same place. Apples and oranges.
-- Darren Duncan
But when I
have the time, you will see it run.
-- 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
things like concurrency become a lot easier with immutables.
You can fake object mutability with syntax, or only allow what references point
to to change.
-- 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
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
and then the
field names in your rowset can be a properly flat namespace.
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 = Fake
Carl Mäsak wrote:
Darren (>):
Specific units, even "seconds" should not be mentioned at all in the
definition of "Instant" or "Duration"; instead, any particular units or
calendars or whatever would just be a property of the composing class.
No disrespe
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 declaratio
nsionality, such as
like Numeric may include Complex, or do we want it to explicitly be
one-dimensional (though units agnostic), like Real?
And whatever choice we pick, maybe there should be suitable generic names given
to the complementary concept of what I mentioned.
-- 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
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 the 4 that we have now for bases 2,8,16,10.
You're joking, right?
s we have an 0a form 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
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
I suppose then if +{} works for bags we could alternately use -{} for sets but I
don't really like it.
-- Darren Duncan
agree though with the principle that sets and bags should be just as easy
and terse to use as arrays.
-- Darren Duncan
om a string or array of string argument. -- Darren Duncan
as another way
of saying "returns nothing" 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
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
responsive 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
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
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*.
to work on 100% of objects then we should
fix .perl so it doesn't break encapsulation.
Or maybe so that we can have our cake and eat it too, there should be two .perl
where the first is more restricted like I say and the second just dumps the
private attributes, and the second can only be used with MONKEY PATCHING.
Then Damian's position (which I support) is supported and so are monkeys.
-- Darren Duncan
hly recommend that "set" be renamed to "put"
in contexts such as attribute accessors like this.
-- Darren Duncan
e accessors could be named "value" and "update_value()".
But regardless of whatever else you do, "set" for this purpose has got to go.
-- Darren Duncan
r that meaning and just use "range" for other
meanings such as high-low distance or the output of a function, or just use it less.
The main wrinkle I can see here is if you were deliberately using "range"
*because* it has multiple meanings, to try and convey all of those meanings at
once. While that may work in some cases, it seems *too* clever in this case.
And if you want to say that, eg, casting a Range object as an integer returns
the difference between its endpoints (meaning #2), Interval works for that too.
-- Darren Duncan
is a good thing, this being an example. -- Darren Duncan
Larry Wall wrote:
On Fri, Sep 10, 2010 at 06:00:30PM -0700, Darren Duncan wrote:
: With regard to http://perlcabal.org/syn/S11.html#Versioning ...
:
: If some Perl code requires a module (or Perl version) that has
: multiple authorities and each authority uses a different
: version-numbering
at?
Can you say something like this?:
use Foo:(auth:ver(1..3,5..*)|auth:ver(2..9))
... but maybe with different syntax?
-- Darren Duncan
on the
list message has the diffs quoted.
-- Darren Duncan
See also my Muldis D language which has explored these same kinds of ideas:
http://search.cpan.org/dist/Muldis-D/lib/Muldis/D/Dialect/PTMD_STD.pod#General_Purpose_Integer_Numeric_Literals
-- Darren Duncan
ng so, having seen David's example here, which it never occurred to me
before was possible. -- Darren Duncan
Darren Duncan wrote:
For another thing, assuming in the typical case that any time a language
evolves, it still provides the means to accomplish anything it was
previously capable of, then each implementation needs no
backwards-compatibility internally, but just the state of the art
Damian Conway wrote:
Darren suggested:
Use namespaces.
The upper/lower/mixed approach *is* a
namespace approach.
Yes it is. But I thought that prefix-namespaces would scale better. Especially
if the documentation system got complicated enough to involve modules, possibly
those by
Carl Mäsak wrote:
Darren (>):
Read what I said again. I was proposing that the namespace comprised of
names matching a pattern like this:
/^ <[A..Z]>+ | <[a..z]>+ $/
/^ [<[A..Z]>+ | <[a..z]>+] $/
Are the square brackets necessary when the pattern doesn't
Brandon S Allbery KF8NH wrote:
On 8/4/10 21:26 , Darren Duncan wrote:
jerry gay wrote:
are there codepoints in unicode that may be either upper-case or
lower-case, depending on the charset? if so, then there's ambiguity
here, depending on the user's locale. i suspect not, but lan
spec will likely just use
all-uppercase or all-lowercase ASCII words, but that isn't a promise and rather
is a convention; there may be a good reason to change later.
Explicit versioning is your friend.
Can I get some support for this?
-- Darren Duncan
l names going out of the ASCII repertoire, which I would recommend
we don't.
-- Darren Duncan
umented, or
alternately an explicit named rounding method of don't care could be provided,
for users who don't care about exact portable semantics, and the implementation
can decide what is fastest. I suggest using the whatever mnemonic for this:
$a = $b div $c :round(*)
... though for those people, probably they'd do it at the file level.
-- Darren Duncan
Martin D Kealey wrote:
On Wed, 28 Jul 2010, Darren Duncan wrote:
I think that a general solution here is to accept that there may be more
than one valid way to sort some types, strings especially, and so
operators/routines that do sorting should be customizable in some way so
users can pick the
ould *not* be the same value, and they should be distinguishable in
any generic context like eqv or given-when. They should only compare alike when
cast into the same type such as with a ? or +.
-- Darren Duncan
this time. -- Darren Duncan
either "False eqv ?0" or "+False
eqv 0" being true is okay.
If people want ~~ semantics, let them ask for it explicitly, such as with:
given $foo {
when ~~ $bar {...}
when ~~ $baz {...}
default {...}
}
-- Darren Duncan
other order.
So then, "a" cmp "ส้" is always defined, but users can change the definition.
-- Darren Duncan
Dave Whipp wrote:
Similarly (0..1).Seq should most likely return Real numbers
No it shouldn't, because the endpoints are integers.
If you want Real numbers, then say "0.0 .. 1.0" instead.
-- Darren Duncan
Darren Duncan wrote:
Aaron Sherman wrote:
The more I look at this, the more I think ".." and "..." are reversed.
I would rather that ".." stay with intervals and "..." with generators.
Another thing to consider if one is looking at huffmanization
. Besides comparing ranges, an interval
would also often be used for a membership test, eg "$a <= $x <= $b" would
alternately be spelled "$x ~~ $a..$b" for example. I would imagine that the
interval use would be more common than the generator use in some problem
domains. -- Darren Duncan
ot; is that the endpoints are comparable, meaning "$foo cmp $bar"
works. Having a .pred or .succ for $foo|$bar should not be required to define a
range but only to use that range as a generator. -- Darren Duncan
, not dependent on any language besides themselves and
C. -- Darren Duncan
have thought this would be reasonable:
3 ~~ 1..5 # TRUE
So if that doesn't work, then what is the canonical way to ask if a value is in
a range?
Would any of these be reasonable?
3 ~~ any(1..5)
3 in 1..5
3 ∈ 1..5 # Unicode alternative
-- Darren Duncan
Darren Duncan wrote:
specific, the generic "eqv" operator, or "before" etc would have to be
Correction, I meant to say "cmp", not "eqv", here. -- Darren Duncan
use "..." instead; ".." should not be overloaded
for that.
If there were to be any similar pragma, then it should control matters like
"collation", or what nationality/etc-specific subtype of Str the 'aa' and 'bb'
are blessed into on definition, so that their collation/sorting/etc rules can be
applied when figuring out if a particular $foo~~$bar..$baz is TRUE or not.
-- Darren Duncan
should be
"value" types.
If you want to derive a DateTime from another, say, then just have the
pseudo-mutator method return a new object with the differences.
-- Darren Duncan
type or role named "Bridge", such that "Bridge" would be casting
as such? Because if not, I would think you'd want the method to not be
capitalized, unless there is some other precedent for doing so. -- Darren Duncan
and a string.
There is also still the need to cover something that looks like a list of
integers, for the general case of a Blob/Buf literal, and yet it should have an
appearance more like that of a scalar/number/string/etc than of an array/etc.
Any thoughts on this?
-- Darren Duncan
ions, to handle some edge cases where nothing else
will do. That module isn't exactly what Darren is looking for since
the keys are English strings with a little meta-language mixed in, but
the rest of it is worth referencing.
Functions are fine. My main point is that all languages are treat
files.
I also recommend against the older "gettext" (name?) design that involved having
one language's text inside the program code and using that as a key for others.
I prefer the more self-consistent design that I proposed.
-- Darren Duncan
Stefan O'Rear wrote:
On Thu, Jun 17, 2010 at 04:55:38PM -0700, Darren Duncan wrote:
So, is "Rakudo Star" meant to be a parallel release series, sort of like
Perl 5.12.x vs 5.13.x are now, or are the monthly Rakudo releases we've
been seeing going to be named "Star&quo
So, is "Rakudo Star" meant to be a parallel release series, sort of like Perl
5.12.x vs 5.13.x are now, or are the monthly Rakudo releases we've been seeing
going to be named "Star" at some point? I thought I read recently that "Star"
would be coming in June. -- Darren Duncan
, so why not?
Or otherwise clarify what Buf and Blob each are.
-- Darren Duncan
ense (than comparing Weight and
Distance) to compare a Manager with an Employee since that can tell you if they
are the same Person. It depends on what kind of equality test you are looking
to do, at what level of abstraction. -- Darren Duncan
rious media and forums. Support is welcome in providing
significant financial sponsorship towards my further work, in which case you
have more of a say in its direction and priorities. But mainly I want to see it
get used to enrich projects and their users and developers.
This project and ancillary projects are a serious endeavor that I intend to
commercially support over the long term, and others can do likewise.
Good day. -- Darren Duncan
Jan Ingvoldstad wrote:
On Sun, Apr 25, 2010 at 00:46, Darren Duncan wrote:
All details specific to any calendar, including Gregorian, including
concepts like seconds or hours or days, should be left out of the core and
be provided by separate modules. Said modules can be self-contained, just
the current datetime, and the
module can introspect its result or calendar() and figure out how to map that to
the internal representation or API it wants to use, as well as figure out the
proper way to invoke sleep().
-- Darren Duncan
Darren Duncan wrote:
Jon Lang wrote:
We _should_ define
Jon Lang wrote:
Darren Duncan wrote:
I think that the most thorough solution is to just take it for granted that
there are multiple reference timelines/calendars and that in general it is
impossible to reconcile them with each other.
Taking this to its logical extreme, there might be a few
s possible.
This brings up a new discussion point though: We should come out with a list of
distinct timelines/calendars and canonical names for them with respect to Perl
6. So to at least help those who are trying to use the exact same calendar to
recognize that they are doing so.
-- Darren Duncan
I believe that any character at all is allowed in a variable name.
Its just that for most characters, when you use them the variable name has to
be quoted. The common unquoted identifier syntax is much more limited, and is
mainly what was being discussed here.
-- Darren Duncan
sitive, as AFAIK Perl 6 currently is; if something looks
different, it is different. -- Darren Duncan
ens, but not
mix and match, unless there is a conceptual distinction between things named
with the different styles that are worth highlighting by using different styles;
barring that, such an inconsistency in Temporal may be something that should be
fixed.
-- Darren Duncan
P.S. My Muldis D lang
Jonathan Worthington wrote:
Darren Duncan wrote:
Dave Rolsky wrote:
On a smaller point, I think second vs whole_second is the wrong
Huffman coding. I'd think most people want the integer value.
Well, whatever you call things, the most important thing is to keep
the seconds count as a s
conds if we're supporting fractional seconds is preferred in
Synopsis 2, and I agree; if people think otherwise, then what is the rationale?
-- Darren Duncan
Martin D Kealey wrote:
On Mar 27, 2010, at 15:43 , Darren Duncan wrote:
For example, say you want to define a graph of some kind, and for
elegance you have a separate container and node and side classes,
On Sat, 27 Mar 2010, Brandon S. Allbery KF8NH wrote:
This sounds like a hackaround for
n't have a predefined order. I just raised
my algorithm since someone else raised another one. -- Darren Duncan
1 - 100 of 478 matches
Mail list logo
