Re: Checking for nil return
On 2020-12-29 6:26 a.m., Ruud H.G. van Tol wrote: Basically, never mix error-state and return-value. Rather use a different channel/dimension for each. Such a separation can't be absolute though. One needs to be able to user-define routines that implement additional generic Failure related 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
Re: A proposal for Perl's branding - let's free all the butterflies
On 2018-02-16 11:15 AM, Nigel Hamilton wrote: Here is a suggestion for Perl's branding: http://nigelhamilton.com/perl-branding-proposal.html I like your proposal. But its details would need fleshing out more, particularly at the end, where it says this: Perl $new_runtime_name_for_perl5_goes_here (tm) Perl $new-runtime-name-for-perl6-goes-here (tm) That implies that the only things being branded this way are runtimes, and not the languages themselves, which I thought was meant to be under that umbrella. So for example: Perl $new_language_name_for_perl5_goes_here (tm) Perl $new-language-name-for-perl6-goes-here (tm) -- Darren Duncan
Re: Naming debate- what's the location for it?
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 idea. -- Darren Duncan On 2018-02-16 3:07 AM, Lloyd Fournier wrote: I'm about to publish some blog posts with using Perl 6 to demonstrate some cryptographic primitives. I was thinking about calling it "rakudo" to at least intrigue people and make them google it. Couldn't we call the language rakudo and the implementation nqp-rakudo? (ie a rakudo implementation in nqp) LL On Thu, Feb 15, 2018 at 5:02 AM Patrick R. Michaud wrote: On Wed, Feb 14, 2018 at 05:55:54PM +, raiph mellor wrote: > (Perl) Rakudo > === > > If jnthn and pmichaud and larry can warm to this idea, then: > [...] > The 'Perl' could be dropped from Rakudo specific propaganda, > calling the language just Rakudo instead, to reinforce that it refers > to 6e and beyond. But the Perl could be retained in any material > covering both Raptor and Rakudo as a reunified tech / community. FWIW, I am VERY MUCH AGAINST the idea of naming a language after its implementation. I've seen the confusion it causes in other environments and we ought not repeat that mistake here, especially since we don't have to. Whatever things end up being called, don't confuse the implementation(s) with the language definition. Pm
Re: Naming debate- what's the location for it?
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. Yes, spelled out. On Fri, Feb 9, 2018 at 8:16 PM, Parrot Raiser wrote: On 2/10/18, Darren Duncan wrote: > I think if we want to keep "Perl" in the name we should use "C" as a precedent. > Other related languages keeping "C" include "Objective C", "C#", "C++", > > Perl++ would work.
Re: Naming debate- what's the location for it?
On 2018-02-09 12:55 PM, Eaglestone, Robert J wrote: I think a name change is too radical. /And yet/. I think Steve has a point, though I don’t know what to do about it. The developers in my little corner of the world may not be up on the new-language-of-the-week, but even they see Perl as a has-been, write-only language, so when their brain matches /perl/i they automatically toss it in the bit bucket. Some of them are too nice to say it outright. Some aren’t. Personally I think having the "6" as part of the name is the worst part of the situation. Its too confusing with a version number. I think if we want to keep "Perl" in the name we should use "C" as a precedent. Other related languages keeping "C" include "Objective C", "C#", "C++", and its much more clear those are separate languages, even if C-alike. So one way or another, "6" should be dropped from the name of the language formally. Then we either have "Foo Perl" or "Perl Foo" or "Foo". After this is done, regular "Perl" can also be free to increment its first version number for major 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
Re: Naming debate- what's the location for it?
My personal favorite resolution is to officially name the language Rakudo, full stop. The implementation that was/is using the name would be renamed to something else so it isn't the same as the language. Then we say "Rakudo" is a sibling language of "Perl", full stop. Then "Perl 6" becomes a deprecated alias for Rakudo, used informally rather than formally from now on, and officially considered a historical footnote rather than anything still cited in official documentation or marketing. The unqualified name "Perl" continues to refer to the original lineage (currently at version 5.x) such as what 99% of the world means when they refer to it. Remember, we can still say "Rakudo is a sibling of Perl" for all the reasons we currently do without actually calling it any kind of "Perl" as an individual; we don'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 would like to happen. -- Darren Duncan On 2018-02-08 12:47 PM, yary wrote: ...and "rakudo" even better by that criterion. And then there's how "rakudo" is already named in many files, databases, websites, and that's enough to make me think it's a "good enough" name. Though I'd like to change that implementation's name to something else if we start calling the language Rakudo! I quite like having the distinction between the language and its implementations. No one confuses C with cc, gcc, pcc, tcc, mvcc, XCode, or Borland. Using the name "rakudo" to mean the language makes me feel a little bad in that it muddies that distinction further, and gives this current implementation a special status. A status which it earned, we're not talking about calling the Perl6 language "pugs" or "parrot" or "niecza" for a reason. /me shrugs.
Re: fixing infinities and ranges etc
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, if I'doing something with tangents and handling pi/2, I'd rather be thinking about PosInf as my exception and not AfterEverything. So, the main thing that I think should exist is a generic before/after-everything concept so that it can be used to indicate that generic intervals are unbounded at either end and that generic 'cmp' etc are automatically defined for every other type and them and use as identity values for min/max. So, following up on this, ... I went with the singleton names Before_All_Others and After_All_Others in my abstract database protocol API for Perl 6, and explicitly documented that these are a type-agnostic analogy to negative/positive infinity whose sole purpose is to canonically sort before or after every other value in the type system, and they expressly do NOT represent any mathematical or physical concept of infinity, including those in IEEE floating point, which should be defined separately where useful. Example uses of these singletons are to represent the endpoints of partially or totally unbounded intervals/ranges, or be the identity values for "min" and "max", or be the result when one calls "pred" or "succ" on the first/last value of an orderable type. And so, I also want to propose that Perl 6 add the 2 singletons X::BeforeAllOthers and X::AfterAllOthers for similar type-generic use cases. Yet other singletons or values can exist to meaningfully represent mathematical infinities etc such as the IEEE floats support so appropriate semantics exist in peoples' code. -- Darren Duncan
Re: fixing infinities and ranges etc
On 2016-10-30 5:45 AM, yary wrote: I'm not sure I entirely understand the proposal- does it change Inf aka ∞ ? Part of the issue I think is that the existing "Inf" aka "∞" don't seem to be very clearly defined. What I could find so far, at least with respect to Ranges, is that they are just syntactic alternatives to the Whatever *. They don't seem to be actual typed values that one can say use as declared types for things. Otherwise I like it, and prefer the X::NegInf and X::PosInf,spellings as being easy-to-understand & a good Huffman-encoding. Ok. 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, if I'doing something with tangents and handling pi/2, I'd rather be thinking about PosInf as my exception and not AfterEverything. So, the main thing that I think should exist is a generic before/after-everything concept so that it can be used to indicate that generic intervals are unbounded at either end and that generic 'cmp' etc are automatically defined for every other type and them and use as identity values for min/max. At the same time, I think some people would want to distinguish between these and a mathematical concept of infinity in a similar manner that people distinguish orderable and ordered and ordinal etc. What I mean by the latter is, "ordered" and "ordinal" have rather precise meanings in set theory or mathematics etc, meanings that don't apply to a lot of data types we tend to sort on. For example, ordered/ordinal strictly speaking wouldn't apply to character strings and they may not apply consistently to the general case of rational numbers and so on; for some types we just want to be able to sort them deterministically but the actual sort order might not be meaningful within the domain. So I made up the term "orderable" to refer to what generic "cmp" or SQL "order by" etc do. The before/after-everything singleton are meant specifically to apply to this "orderable" concept. So, having that, the question is whether we want to have distinct infinity concepts for numbers from those, and I suspect we might. In maths we have directional infinities on a line, but there's also the concept of something being infinite that is not directional such as an unbounded volume, and there's also countable vs uncountable infinities etc. We may not want to imply any of those with our before/after-everything concept which is meant to serve a different purpose. X::BE and X::AE are too short to use outside of this discussion, especially as "BE" is the common verb "be." Maybe X::OBE and X::OAE for "ordered before/after everything"? Anyway, this part is bike-shedding, my main point is that the singletons simply exist and what their properties are. Before/AfterEverything ... 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. So, now this brings up a different thing. A Perl 6 analogy to a SQL Null would ALSO be a Failure singleton type, for example X::NoReason, basically it means that we don't have a normal value of the domain here AND we are giving absolutely no explanation for why the normal value is missing. A SQL Null in general means means "we don't have a normal value and we aren't saying why", it does NOT mean "not applicable" or "unknown" or "missing" or "not matched" or anything like that, it doesn't even say which of those it is. As far as I could tell the Perl 6 Nil singleton had this X::NoReason meaning, but if it actually doesn't, then we should have a new X::NoReason to be more explicit about that. This would mean that a Perl 6 Nil actually IS giving a reason why the normal value is absent. As a final note today, I will mention that the subject of 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
fixing infinities and ranges etc
I have observed that the current Perl 6 spec and implementations seem deficient in regards to representing some special values or conditions, in particular the concept of the two linear directional infinities or otherwise special values that naturally sort before and after everything else. Moreover, some discussion I saw on the matter shows that these issues had been punted, so here I'm trying to propose a resolution or process to that end. Here are some links for context: * http://irclog.perlgeek.de/perl6/2014-08-20#i_9217322 * https://docs.perl6.org/type/Range#method_infinite * https://github.com/rakudo/rakudo/blob/nom/src/core/Range.pm Here are some proposals and comments: 1. I think the best way to represent various special values like this is as singleton types, basically in the same way various Failure or Exception are handled, such as the various X::Foo classes. So for example, we should add X::NegInf and X::PosInf, or alternately per Larry's comment in the first link, something like X::BeforeEverything and X::AfterEverything or X::BE and X::AE. Actually we may want both the infs and the BE/AEs where distinguishing them is useful. Similarly I recommend adding such singletons for various other math concepts such as X::DivByZero and X::ZeroToTheZero etc. 2. In the case of NegInf/PosInf (alternately read as BE/AE from now on), generic ordering sensitive operators like cmp would have signatures defined such as (NegInf, Any), there would be 4 combos of those, which would be defined to always return FALSE or TRUE as appropriate; as such, all values would be comparable with these singletons automatically. Also, any dyadic min/max operators would use these singletons as their identity values. 3. Regular types such as Int or Rat or Str etc should be pure and just include normal values, that is just actual numbers for the numeric types etc. Then, contexts that might produce or want to recognize failure conditions alternately accept or return the appropriate Failure singletons mentioned, as if a type union were defined over the regular types and the failure types; users can choose whether they want to allow the special values explicitly by either including or excluding them from signatures, so naming eg just Int will only accept actual numbers. 4. Independent of the above points, the current Range class has a problem in that it doesn't distinguish which endpoint is infinite. Just as it currently distinguishes whether each endpoint is open or closed, it needs to distinguish whether each endpoint is infinite or finite. All 4 of these cases need to be distinguished: 5..10, -Inf..10, 5..Inf, -Inf..Inf and I hope it should be self-evident why that is important. For starters, it is completely valid to ask whether a value is in any of the given ranges; for half-infinite ranges, it is a generalized form for asking if the value is larger or smaller than the finite end; for fully-infinite ranges, the answer is always TRUE. Another way to think about it is that a Range is just a concise way of expressing a set. The current Range class simply has a boolean attribute that says is the Range infinite, yes or no, and that needs fixing. 5. A generic solution to representing Ranges properly is to use the two special singletons I mentioned be the endpoint values. A lot of comparing operations would then just work. Using the range to generate a list of member values would also work in some cases, depending where the infinities are and in what direction we are enumerating. 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
Re: It's time to use "use v6.c"
On 2016-02-06 11:35 AM, Brandon Allbery wrote: On Sat, Feb 6, 2016 at 2:30 PM, yary wrote: this morning I installed the 2016.01 R*. Now I'm at the NYC perl6 study group, and a helpful neighbor asked me to start up p6doc. This is something of an edge case. It is reasonable for stuff that is supposed to ship *with* perl6 to bend the rules; the problem is that nobody realized that p6doc was broken (this was discovered earlier today), so R* silently (grumble) didn't include it and you got some other p6doc instead. I agree with yary. I also think that dog-fooding it should be done where possible. If stuff that ships with perl6 can't be written using all the same best practices as code users should write, then its a problem. This includes not having "use v6.c". While exceptions may exist, any time they do, that should become a case study 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
Re: Exploit the versioning (was Re: Backwards compatibility and release 1.0)
On 2015-10-15 5:27 AM, yary wrote: Short answer: everything must declare which semantics it expects- everything in Panda/CPAN at least. And we already knew it, just need to do it. I believe this is something Perl 6 should require in general, if it doesn't. That is, it should be MANDATORY for Perl 6 code to declare what version of Perl it expects. (The sole exception is one-liners.) If we don't do this, people are going to be lazy and not say anything, and then there will be a large base of code that officially is just saying "any version of Perl 6 will do" 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
Re: Exploit the versioning (was Re: Backwards compatibility and release 1.0)
On 2015-10-14 6:14 AM, Parrot Raiser wrote: Is this particular change one that could be implemented algorithmically, or at least partially so? (E.g. For all modules check for the presence of a ":D". If it's there, no action. If not, insert a line of code. Run a test. If successful, post change. If not, alert a human) I think this can be done, yes, and in principle it would be a good idea. But the problem Moritz seemed to be raising is that each of the Perl 6 modules is possibly in different repositories under a wide variety of users, and it would still count on a lot of people to take action to accept those changes in order to not have a lot of breaking. While I agree that changing the modules would be better quality-wise, my versioning proposal is likely more practical if we're trying to focus on stability now for a Christmas 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
Exploit the versioning (was Re: Backwards compatibility and release 1.0)
I have a proposal. Unlike with say the GLR, perhaps this whole :D thing may be a good test case for the Perl 6 feature of explicit language versioning. How about we don't make the :D change now, and give more thought as to whether we actually want to do it at all. If we do decide it is worthwhile, lets make it so that the :D change is part of Perl 6.1 say, along with any other changes we decide in the near future would be a good idea. Then, programs that explicitly say "use 6.1" or such will get :D as default, while those that don't or say "use 6.0" 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 Duncan On 2015-10-14 2:54 AM, Moritz Lenz wrote: So a large percentage of the module updates are done by group of maybe five to a dozen volunteers. So, do the math: 5 people updating 70% of 390 modules. Modules they are usually not all that familiar with, and usually don't have direct access. So they need to go through the pull request dance, waiting for reaction from the maintainer. In short, it sucks. The ecosystem hasn't yet fully recovered from the s/done/done-testing/ change, nor from the GLR, nor from the need to prefix 'unit' to some declarations. And this is why I'm getting increasingly frustrated and angry when people propose major breaking changes, brushing off the implications for the ecosystem and its maintainers with "but it's not 6.0", "shouldn't be a problem", "we aren't stable yet". We want to release Perl 6 by Christmas, and it'll reflect *very* badly on us and the language if many modules in the ecosystem are broken. And any change that requires us to touch all .pm files will result in that.
Re: Backwards compatibility and release 1.0
I had a related thought. We want Perl 6 to be the best it can be out of the gate when it is declared production ready at Christmas or whatever. If it is better for the default to be that parameters must be defined where not explicitly declared otherwise, then that is what Perl 6 should specify, and it doesn't matter about the 390+ modules that exist now. Perl 6 is supposed to be a break it all at once release, and this situation is no different. Having :D being default seems right to me, that would seem to huffman code for the safer behavior which users most likely want by default. -- 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 changes still cause pain in the ecosystem. We have 390+ modules, and hand-waving away all trouble of maintaining them seems a bit lofty. Surely, the idea of keeping the release number below 1.0 is to warn early adopter developers that code is subject to change and thus in need of maintenance? Seems strange that after so long and "Christmas" is finally coming up that Rakudo 1.0 is going to be associated with modules that do not comply with the "standard". So if :D is the default specified by the standards, then all modules should be expected to conform to that standard when V1.0 comes out. It does not matter really what the standard actually is, :D or not, so long as what is defined to be the standard is adhered to. Perl6 gives huge flexibility to developers to change standard for themselves, but surely there should be some common 'starting' ground, and modules for general use should adhere to it. When the language and implementation were being co-developed, it was reasonable to expect that different modules would have different states of compliance. But surely V1.0 is a different sort of milestone? 'Hand-waving' all the trouble of maintaining the modules surely is not the issue. Ensuring that the modules comply with the standard set for Perl6 as implemented by Rakudo V1.0 is a reasonable expectation for anyone using the Rakudo version of Perl6 going forward. Even if there is an argument that I have missed in the above about the need for modules to adhere to the standard prescribed by the Perl6, would it not be in the interests of PR around Perl6 for the very first V1.0 implementation to be accompanied by modules that have been brought as close to the standard as possible? These modules will help future developers to understand how to use the language.
Re: To :D or not to :D
On 2015-10-12 1:25 PM, Patrick R. Michaud wrote: On Mon, Oct 12, 2015 at 09:51:13PM +0200, Mark Overmeer wrote: Can you give me an example? Many other languages are capable to live without undef and have first class type objects. Keep in mind that what Perl 6 calls a "type object" isn't quite the same as class objects in other languages -- a Perl 6 typename is really an undefined instance of a class. In other words, the identifiers C, C, C etc. refer to instances of those classes just like the literals C<3>, C<4/5>, and C<[1,2,3]> are instances of those classes. They share the same method spaces. Hey, that sounds like a nice elegant design, I learned something new. -- Darren Duncan
Re: Language design
On 2015-06-16 2:15 PM, The Sidhekin wrote: On Tue, Jun 16, 2015 at 10:52 PM, Michael Zedeler wrote: ...and unpredictable performance is a cost you're willing to pay? I don't write performance-critical applications, but even if I did, why would I prefer getting the wrong answer faster? I agree with Sidhekin and similar mentalities. On the range between safety/correctness and speed, a good programming language / tool should always default to the most safe/correct option when the user doesn't specify where on the range they want, and leave it to the power users to explicitly make the trade-off when they know what they're doing. In this case, people who explicitly want floats because of performance rather than exact rationals do indeed count as power users. Normal people are more interested in not being surprised by the answers they get to what should be common-sense questions, such as when adding 10.3 to 14.2. I should also point out that finance / anything to do with money is an extremely common use case that cares very much about math being exact, its not just esoteric science applications. This all being said, I draw the line where implementing is much more complicated to serve esoteric cases. So for example while exact precision rationals absolutely should be default / part of core, something like symbolic values eg exact representations of irrational numbers, are perfectly valid to, and probably shouldn't, 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
Re: versioning - how to request different 'ver' per 'auth'?
Please get the #perl6 consensus then. I had suspected the answer would be that
the solution would be the :ver code being able to see what :auth was selected
and dispatch based on that. Otherwise supporting the wider version declaration
to have a tree structure, where :ver was embedded inside :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 semantics are, to also explain the correct syntax of the
pair that follows a 'use NAME':
:auth and :ver<1.2> etc are of type Pair. Wenn the compiler hits a
use statement, it smartmatches
the distribution's auth/name/ver against the value of the corresponding
Pair.
That means these Pairs are valid:
:auth # match literally
:auth(/\w+/) # regex match
:auth($author) # okay if $author is known at compile time
:auth(*.chars == 6) # oaky, whatevercode
:auth({ $_.starts-with('Bla') }) # okay, closure
:auth(-> $auth { $auth ~~ /Bla/ }) # okay, something callable with arity
== 1
:auth({ $^auth ~~ /Bla/ }) # okay, something callable with arity == 1
etc
That also means we cannot match different version patterns for different
:auth patterns, because we only
pass one value to the Pair's value to smartmatch against. What I can
imagine though is that if the matcher
is callable, and has an arity of 2, we pass the CompUnit as the first
and the $auth as the second argument.
That needs consensus in #perl6 though.
Cheers, Tobias
Am 11.06.2015 um 05:26 schrieb Darren Duncan:
So I have a question about versioning, either/especially about
compilation units, but also Perl 6 itself.
For context I refer to http://design.perl6.org/S11.html#Versioning .
With regard to "use" statements and specifying 'auth' or 'ver' to
restrict between versions, it seems to me that the spec defines them
interacting in a cross-product fashion.
For example, given this possibly incorrect syntax:
use Dog:auth:ver(4-6, 10-15);
... that would be satisfied by any of TPF versions 4-6,10-15 or
JRANDOM versions 4-6,10-15.
However, what I want is to restrict the 'ver' differently depending on
the 'auth', treating them more as the hierarchy they are, assuming
that different authorities may go off and use different versioning
schemes.
The question I have is how to 'or' the following into a single 'use
Dog' 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 specification has or can gain a
clean way to say how its done.
Thank you.
-- Darren Duncan
versioning - how to request different 'ver' per 'auth'?
So I have a question about versioning, either/especially about compilation units, but also Perl 6 itself. For context I refer to http://design.perl6.org/S11.html#Versioning . With regard to "use" statements and specifying 'auth' or 'ver' to restrict between versions, it seems to me that the spec defines them interacting in a cross-product fashion. For example, given this possibly incorrect syntax: use Dog:auth:ver(4-6, 10-15); ... that would be satisfied by any of TPF versions 4-6,10-15 or JRANDOM versions 4-6,10-15. However, what I want is to restrict the 'ver' differently depending on the 'auth', treating them more as the hierarchy they are, assuming that different authorities may go off and use different versioning schemes. The question I have is how to 'or' the following into a single 'use Dog' 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 specification has or can gain a clean way to say how its done. Thank you. -- Darren Duncan
Re: Synopses size and revision state
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 wrote: On 15 May 2015, at 16:05, Parrot Raiser <1parr...@gmail.com> wrote: Without doing too much work, can anyone offer an estimate of the volume of the Perl 6 Synopses? I'm assuming that by now, they are unlikely to undergo serious modification. I'm trying to estimate the cost of rendering them to dead-tree versions for study. (Personal limitation; I can look up a command definition online, but for study and mental integration, it's got to be something like a real book.) at 4+ lines and 100 lines / page, that would be about 400 pages ? Liz
Re: S02 mistake re Blob?
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://design.perl6.org/S02.html#Immutable_types for an example of the latter. -- Darren Duncan so, you think roles aren't types? (Also, roles auto-pun into classes upon usage). When I said type I meant class. As I recall from the rest of the spec, things were either roles or classes. You can't instantiate a role directly, so if a Blob is declared as a role you can't just instantiate one directly, isn't that how it works? Either way it seemed to be getting treated differently. -- Darren Duncan
S02 mistake re Blob?
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
Re: question - languages with set/foo as only base data type
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 generic unordered sets as the one foundation Foo type for my purposes, as I realized when you had Lisp ops like car/cdr plus generic recursive functions and such you didn't even need to have integers as a precondition to use the ordered lists, as the integers are no longer fundamental to access arbitrary list elements; the orderedness also makes working with these as I want to much much simpler as its easy to identify the element that gives you context to interpret the other elements. -- Darren Duncan
Re: question - languages with set/foo as only base data type
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
question - languages with set/foo as only base data type
I have a question for those among you that are more knowledgeable about Haskell
or other functional programming languages, or related mathematics or set theory
and such.
I recall reading that at least in certain math/logic papers that a programming
language type system can be defined logically in terms of pure sets, making it
essentially self-defined without needing to rely on external definitions of for
example what a number is. In such a type system, every value is a generic set
of 0..N elements, and the value of every element is also such a generic set,
which can recurse arbitrarily such that all leaves are the empty set. In such a
system, you could for example represent the number zero by {}, the number 1 by
{{}}, 2 by {{{}}} or something else, etc. I'm not saying that such a type
system would be practical to implement in a manner resembling this, but more
that it is simply a logical basis for defining a closed system at the most
fundamental level.
I am wanting to try designing a low-level conceptual type system like this and
was wondering what precedents existed, ideally in implemented programming
languages, but otherwise in set logic papers, for how one might do this. For
example, what set values one might use to represent integers, or booleans, or
arrays, or other data types that users would actually work in terms of. Also,
what fundamental/etc set operators one would have in terms of which all other
operators are defined.
Does Haskell at least conceptually work in terms like I described? I seem to
recall reading that how it logically thinks about string values is towards that
direction.
Or to be more clear, what I *actually* am looking to design is a system with a
single concrete base type that can represent all possible values, and that all
other types are declared as subsets.
In Perl 6 syntax I'm looking to have some single base type Foo where all other
types including eg Integers and Arrays etc are definable like this:
subset Integer of Foo where ...;
subset Array of Foo where ...;
...
I thought 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
Perl 6 in Perl 6?
Something (PyPy et al) got me wondering, is it a goal in the Perl community before too long to have a (compiling) implementation of Perl 6 written entirely in Perl 6? Meaning, that at some point the entire non-optional codebase of the Perl 6 compiler (not just the parser) would be written in pure Perl 6? This doesn't necessarily have to produce machine language; it could be another language that needs compiling itself externally, but the point is that the entire process of producing that target language out of Perl 6 would be written in Perl 6. I know STD.pm does 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
Re: CFOs not aligned with Recruiting
So I guess we have a rare failure of a spam filter. -- Darren Duncan
Re: Underscores v Hyphens (Was: [perl6/specs] a7cfe0: [S32] backtraces overhaul)
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
different". (I am not also saying that same-looking things are equal, given
Unicode's redundancy.)
Your mentioning of Unicode is poignant. In Unicode properties, you are not
supposed to have to worry about these things.For example, from UTS#18:
Note: Because it is recommended that the property syntax be lenient
as to spaces, casing, hyphens and underbars, any of the
following should be equivalent: \p{Lu}, \p{lu}, \p{uppercase
letter}, \p{uppercase letter}, \p{Uppercase_Letter}, and
\p{uppercaseletter}
Sure, but Unicode character names are a distinct issue from Perl identifiers.
Apples and oranges.
For dashes and underscores etc, the fact that they both exist distinctly in
Unicode and that people consider have circumstances to use one over the other,
means they are considered distinct, and we need to preserve that treating as
distinct.
-- Darren Duncan
Re: Underscores v Hyphens (Was: [perl6/specs] a7cfe0: [S32] backtraces overhaul)
Smylers wrote: Could we have underscores and hyphens mean the same thing? That is, Perl 6 always interprets illo-figut and illo_figut as being the same identifier (both for its own identifiers and those minted in programs), with programmers able to use either separator on a whim? 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 different". (I am not also saying that same-looking things are equal, given Unicode's redundancy.) If you're going to treat hyphens and underscores in identifiers as being equal then you should make them case-insensitive too, because its the same kind of lack of distinction. I think that a better change, if we're going to change something, is to make hyphens illegal in bareword identifiers, just allowing them in quoted ones. Then we also gain consistency that if something looks symbolic then its an operator, not a question of whether we have a minus operator or not. If one points to XML as an example of working hyphens in bareword identifiers, I should 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
Re: Encapsulating the contents of container types
Moritz Lenz wrote: Moving into the direction of immutability doesn't help with the problem at hand -- it only helps here if we force everything(*) to be immutable, or at least encapsulating every mutable object into special types, like Monads in Haskell. (*) ok, not everything, but everything that can be stored in an object And I'd be very disappointed if Perl 6 turned into Haskell so late in its development stage (remember that we have working compilers, a growing number of modules and active users), especially since it's not tailored to be a language that is tailored towards immutability. Well, you do what works for you. For my part, I have been evolving my new Muldis D language to be essentially what Perl 6 might have been if it were tailored towards immutability. In fact, I would say that is the single largest difference between the 2 languages. I started out more different, and over time came to see the light on how other Perl 6 aspects are actually better for Muldis D than what I had before. The next largest differences are the built-in database functionality, and the fact that mine doesn't even have a hello-world implementation yet. But when I have the time, you will see it run. -- Darren Duncan
Re: Encapsulating the contents of container types
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 object. "Values" of all types should be immutable, even if that type is Array or whatever, and only "Variables" should be mutable. ... To make sure I understand correctly, you're essentially saying that @a.push(3) should not modify @a directly -- someone would have to write something like @a = @a.push(3) # or @a .= push(3) And to do a "shift", one would have to do something like ($value, @a) = @a; since @a.shift would be unable to mutate the array. (I'm not exactly sure what pop would look like.) Is that correct? Yes, that's what I'm saying. And we've already been making moves in that direction. As I recall, regular expression substitutions were already changed to work that way, returning the modified string rather than modifying the argument, so there is precedent. Moreover, thanks to meta-operators, one can typically get a mutating variant of any otherwise non-mutating operator very tersely with just a single added "=" character. This aids learnability as there's a relatively simple mnemonic, where nearly any given operator foo is non-mutating, but by adding an "=" to it you get a mutating variant, so people can look for the "=" to know if it would mutate. The comparison ops are the rare exception to the rule. -- Darren Duncan
Re: Encapsulating the contents of container types
Carl Mäsak wrote:
I ended up implementing a custom accessor method and a sub to
deep-clone hashes, just to make sure that data belonging to readonly
attributes doesn't get changed.
This worries me.
Concrete example (useless output left out):
$ perl6
class A { has @.numbers; method add($n) { @!numbers.push($n) } }
my $a = A.new
$a.add(1); $a.add(2); $a.add(3)
$a.numbers[1] = "OH NOES"
$a.numbers
1 OH NOES 3
Notice that the attribute @.numbers is readonly (since it's not
declared 'is rw'). But that does us a fat lot of good here; it just
means that I'm not allowed to reassign the array reference itself. The
contents are just as writable as any array's.
What worries me -- and the reason I turn to p6l for this -- is that a
lot of class authors will fail to notice this fact and write code that
isn't properly encapsulated and, depending on the circumstances, maybe
even insecure.
I've been worried about this for years, and said so on p6l years ago. I believe
that if you declare something readonly, it should be a guarantee that nothing
can mutate what is stored there to any level of recursive depth, with the sole
exception of elements that are explicitly references.
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 object.
"Values" of all types should be immutable, even if that type is Array or
whatever, and only "Variables" should be mutable.
You should have to go out of your way to mutate something rather than this
happening by default, rather than having to go out of your way to prevent mutation.
As a side benefit, 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
Re: eval and try should be separate
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 role as the catcher of exceptions is a legacy of Perl 1, which had no block eval, and I feel it has no place in Perl 6. The exception catching and associated unwinding makes it impossible to use resumable exceptions across eval boundaries. This includes warn. Given an eval that does not catch exceptions, it is very easy to add catching, using the new blockless form of try, "try eval $code". However, given an eval which does catch, it is impossible to synthesize one that passes exceptions faithfully. Catching exceptions in an eval causes the eval frame to be different from the calling frame, which makes tail call optimization through evals impossible. With the catching eval, it is very easy to write code which accidentally discards exceptions. For the goal of safety it seems best to make discarding exceptions hard by default. Does anyone have objections? Is there general consensus that this change should be made?
spell check in code
It occurs to me, both from my own experience in writing code as well as seeing some production code by others, that spell-checking may be useful in programming languages. To be specific, often user-defined entities such as variable or routine names or attribute names or type names may be declared with dictionary words, but sometimes they may be misspelled, and programmers may not always spot this. I think it would be useful for programming language implementations to provide the option to flag entity names that appear to be mis-spelled dictionary words for programmers. This could also be in text editors, but it could be useful in the compiler also. What would make this different from applying a generic spell checker, is that the code-savvy one would know to take entity names and recognize underscore-separated or mixed-caps or mixed letters and numbers etc and parse out 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
Re: sql idea
Oha wrote:
Hi,
I was thinking how to abuse the p6 grammar to simplify the interface to
SQL DBs.
- First i wanted to have a SELECT which works like a map.
- Then i wanted to use a pointy block to bind fields to variables.
- And i wanted also to make it lazy.
Ah, you have touched on a matter that I care greatly about and have been working
on for awhile, albeit more comprehensively with my Muldis database projects.
First off, see Anton Berezin's DBIx::Perlish Perl 5 module on CPAN, for some
functional prior art of what it looks like you're trying to do.
Next, design-wise, you should be able to have much tighter and more natural
syntactic integration than your example shows, such that you make the database
access code look just like normal Perl code, wherein the database is just a Perl
variable, as if you had something like this (I apologize if this isn't correct
Perl 6, and I'm not sure how to specify a hash slice that returns pairs rather
than just values):
my %db is Database = FooDBMS.new(...);
my ($state, $dept) = ;
my @fetched_users := (%db where {
$_{'state'} eq $state and $_{'dept'} eq $dept
});
for @fetched_users -> $user {
my ($username, $age, $salary) = $user;
say "fetched '$username'";
}
... or since your filter is just anded equality tests, you could alternately say
for the main query (the "matching" takes a Hash second argument, matches by
common key/field names):
my @fetched_users := (%db
matching {state => $state, dept => $dept}
);
A relational database is structurally equivalent to a Hash of Set of Hash (or if
you have multiple schemas, a Hash of Hash of Set of Hash) and you should be able
to syntactically treat it like one in Perl. The various things you can do in a
SQL SELECT can easily have Perl-defined routine/operators doing the same. A
WHERE is just a "grep", picking a subset of fields is just a hash slice keeping
pairs or "map", ORDER BY is just "sort". Joins and groups are a bit more
complicated.
See also my functional Set::Relation Perl 5 module on CPAN, which demonstrates
this.
As for your "(select a.foo, b.bar)" question, don't do that; instead, rename
(with "AS" in SQL") any same-named fields to have distinct names, 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 = FakeDBI.new;
my ($state, $dept) = ;
my @out := $db.SELECT:
-> $username, $age, $salary {
say "fetched '$username'";
"$username => $salary, $age";
}, 'from users where state = ? and dept = ?',
($state, $dept);
say "2nd: ", @out[1];
say "1st: ", @out[0];
say "4th: ", @out[3];
the fake module which make the above code to work (but do not really
connect to a db):
class FakeDBI {
method SELECT(&block, $stm, *...@binds) {
my $sig = &block.signature;
my @fields = map {
$_.name ~~ /\$(\w+)/ or die "invalid
signature params: "~$_.perl;
$/[0];
}, $sig.params;
my @stm = ("SELECT");
if @fields ~~ ('_') { push @stm, '*'; }
else { push @stm, join ', ', @fields; }
push @stm, $stm;
say 'DBG> prepare "', join ' ', @stm, '"';
gather {
say 'DBG> fake execute, fetching rows...';
for -> $row {
my @data = map { $row ~ "_$_" },
@fields;
take &block.(|@data);
}
say 'DBG> no more rows...';
}
}
}
and the output:
DBG> prepare "SELECT username, age, salary from users where state =
? and dept = ? "
DBG> fake execute, fetching rows...
fetched 'john_username'
fetched 'paul_username'
2nd: paul_username => paul_salary, paul_age
1st: john_username => john_salary, john_age
fetched 'sara_username'
DBG> no more rows...
4th: Any()
I found the usage very nice, and the lazyness may be removed by
assigning instead of binding,
so i thought i should share this little useless example, HTH!
TODO: i would like to find a way to use the Signature for table names
(select a.foo, b.bar),
but i don't want to make it too complex, any suggestion?
Oha
Re: exponentiation of Duration's
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 disrespect, but it was the abandonment of abstracty 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
Re: exponentiation of Duration's
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 code to compose. Composing "Instant" or "Duration" into a type simply says that the objects of that type represent a point on a timeline or an amount of time. 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. Said 2 roles would *not* specify that values would numify or strify or boolify in any particular way, such as seconds or otherwise; this is strictly a property of the composing class. Said 2 roles could define particular methods such as, assuming we're just talking one-dimensional: Instant - Instant --> Duration Instant + Duration --> Instant Instant - Duration --> Instant Duration + Duration --> Duration Duration - Duration --> Duration Duration * Numeric --> Duration Duration / Numeric --> Duration Duration / Duration --> Numeric (rational in general) Duration div Duration --> Numeric (integral) Duration mod Duration --> Duration (rational in general) I don't see that multiplying a Duration, or having arbitrary exponentiation, makes any sense when talking one-dimensional, especially when we're being completely units-agnostic. A specific implementing type may have a concept of dimensionality, but I would think that these 2 roles don't. Perhaps a suitable analogy is to look at the level of abstraction that "Numeric" has relative to composing classes. Do we want Instant and Duration to include concepts like dimensionality, 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
Re: exponentiation of Duration's
I think that "Instant" and "Duration" should simply be declarational roles that don't have any implementation code to compose. Composing "Instant" or "Duration" into a type simply says that the objects of that type represent a point on a timeline or an amount of time. 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. Said 2 roles would *not* specify that values would numify or strify or boolify in any particular way, such as seconds or otherwise; this is strictly a property of the composing class. Said 2 roles could define particular methods such as, assuming we're just talking one-dimensional: Instant - Instant --> Duration Instant + Duration --> Instant Instant - Duration --> Instant Duration + Duration --> Duration Duration - Duration --> Duration Duration * Numeric --> Duration Duration / Numeric --> Duration Duration / Duration --> Numeric (rational in general) Duration div Duration --> Numeric (integral) Duration mod Duration --> Duration (rational in general) I don't see that multiplying a Duration, or having arbitrary exponentiation, makes any sense when talking one-dimensional, especially when we're being completely units-agnostic. A specific implementing type may have a concept of dimensionality, but I would think that these 2 roles don't. Perhaps a suitable analogy is to look at the level of abstraction that "Numeric" has relative to composing classes. Do we want Instant and Duration to include concepts like dimensionality, 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
Re: base-4 literals
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 the 4 that we have now for bases 2,8,16,10.
: >
: >You're joking, right?
:
: No, its a serious idea, just not so conventional. -- Darren Duncan
The lack of base 4 numbers in Real Life seems to me to justify the
convention. Do you have a use case?
Actually, the primary case I was thinking of was with blobs.
S02 currently says:
* Blob literals look similar to integer literals with radix markers, but use
curlies instead of angles:
:2{0010_1110_1000_10} a blob1, base 2, 1 bit per column
:4{}a blob2, 2 bits per column
:8{5235 0437 6} a blob3, 3 bits per column
:16{A705E} a blob4, 4 bits per column
Whitespace and underscores are allowed but ignored.
Now, granted, all of the above examples use :N format, but if 0a formats
actually are supported for blobs as I would expect given the above description,
like this:
0b{0010_1110_1000_10} a blob1, base 2, 1 bit per column
0o{5235 0437 6} a blob3, 3 bits per column
0x{A705E} a blob4, 4 bits per column
... then for blobs in particular, I had thought it would be appropriate to have
a base-4 version.
But if there is no agreement, then so be it, I will retract my proposal.
-- Darren Duncan
Re: base-4 literals
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? No, its a serious idea, just not so conventional. -- Darren Duncan
base-4 literals
A simple proposal ... 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. With that addition, the line-up would look like this: 0b - binary (2) 0t - tetra (4) 0o - octal (8) 0d - decimal (10) 0x - hexidecimal (16) Another alterative for 0t is 0q (quad) but I like the look of 0t more because that character's glyph doesn't have a descender like the other 4. With numeric literals, it means 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
Re: Bag / Set ideas - making them substitutable for Arrays makes them more useful
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 that all disambiguation eg with
hashes can be specified.
That would be great.
Glad you agree.
Sets built from multi-dimensional arrays migt be a problem:
{1, 2, 3: 4, 5, 6}
Does that even work? I thought the colon, or is it a semicolon, only had that
meaning in a delimited list like () or [].
In any event, I don't believe there is such a thing as a multi-dimensional set
in that way. Unless you have a concept of multi-dimensional Hash keys, and then
there might be an analogy.
As for bags, well I think that is where we could get fancier.
But *no* doubling up, as we don't want to interfere with nesting.
Instead, it is common in maths to associate a "+" with set syntax to refer
to bags instead.
So, does Perl already ascribe a meaning to putting a + with various
bracketing characters, such as this:
+{1,2,2,5} # a Bag of 4 elements with 2 duplicates
+{} # an empty Bag, unless that already means something
So would the above try to cast the collection as a number, or take the count
of its elements, or can we use something like that?
I'd expect +{...} to count the elements.
Something else I just thought of, and my main reason for writing this reply, is
other options.
Firstly, and I don't necessarily like this option, maybe we could use the simple
curly-brace pair to mean something more general that can be treated as either
a Set or a Bag depending on context. At least from my brief look around, it
appears that maths use the same {foo, bar, baz} syntax to denote both sets and
bags. In some ways it would be like how Perl has the generic "(foo, bar, baz)"
syntax, which remembers order but isn't an Array. We certainly can't use the
presence of duplicates in the {...} to pick Set vs Bag because there could
legitimately be duplicates or not duplicates in the literals for both,
especially if any of the list items are variables and we won't know until
runtime whether any duplicate each other or not.
I still think the better option is to have slightly different looking syntax for
the two. I still prefer Set being the plain brace pair and a Bag being that
plus something extra. It seems that a leading + or ~ or ? is out because those
have established meanings as treating what they're next to in num/str/bool
context, so something else. But it really should be a leading symbolic.
The differentiator needs to be be leading, not trailing; end-weight is bad.
I think that having the marker character /inside/ the curly braces actually
gives us more choices and would cut down on syntactic conflicts, because then we
can basically pick anything that isn't a symbolic prefix unary.
Barring a better suggestion, I suggest the greater-than symbol.
So:
{1,2,3,3,4} # 4-element Set
{>1,2,3,3,4} # 5-element Bag
I think that looks different than anything else we have, and the greater-than
could be a mnemonic that there is "more" in here.
Moreover, the different appearance means we could use => to indicate a count of
that element's contribution to its count, "{>1,2,3=>2,4}", without there being a
confusion with a Hash.
That said, I like the "+" most when differentiating a Bag from a Set, but we
have that symbolic unary "+" which could interfere with it.
-- Darren Duncan
Re: Bag / Set ideas - making them substitutable for Arrays makes them more useful
Jon Lang wrote:
That saves a singlr character over Bag( ... ) and Set( ... ),
respectively (or three characters, if you find decent unicode bracket
choices). It still wouldn't be a big enough deal to me to bother with
it.
As well, my first impression upon seeing [! ... !] was to think
"you're negating everything inside?" That said, I could get behind
doubled brackets:
[[1, 2, 3]] # same as Bag(1, 2, 3)
{{1, 2, 3}} # same as Set(1, 2, 3)
I prefer to have the mnemonic that {} means unordered and that [] means ordered,
so please stick to [] meaning arrays or ordered collections, an {} meaning
unordered collections, so set and bag syntax should be based around {} if either.
This said, I specifically think that a simple pair of curly braces is the best
way to mark a Set.
So:
{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 that all disambiguation eg with hashes
can be specified.
{a=>1,b=>2} # a Hash of 2 pairs
{:a<1>, :a<2>} # we'll have to pick a meaning
{} # we'll have to pick a meaning (Muldis D makes it a Set; %:{} is its Hash)
{;} # an anonymous sub or something
{a=>1} # Hash
{1} # Set
{1;} # anonymous sub or something
But keep that simple an let nesting work normally, so:
{{1}} # a Set of 1 element that is a Set of 1 element
{{a=>1}} # a Set with 1 Hash element
{[1]} # a Set with 1 Array element
[{1}] # an Array with 1 Set element
In certain cases, we can always still fall back to this:
Set() # empty Set
Hash() # empty Hash
Set(:a<1>) # if that's what we wanted
As for bags, well I think that is where we could get fancier.
But *no* doubling up, as we don't want to interfere with nesting.
Instead, it is common in maths to associate a "+" with set syntax to refer to
bags instead.
So, does Perl already ascribe a meaning to putting a + with various bracketing
characters, such as this:
+{1,2,2,5} # a Bag of 4 elements with 2 duplicates
+{} # an empty Bag, unless that already means something
So would the above try to cast the collection as a number, or take the count of
its elements, or can we use something like that?
But I would recommend something along those lines.
I suppose then if +{} works for bags we could alternately use -{} for sets but I
don't really like it.
-- Darren Duncan
Re: Bag / Set ideas - making them substitutable for Arrays makes them more useful
Mason Kramer wrote: I want to propose one major change to the Bag spec: When a Bag is used as an Iterable, you get an Iterator that has each key in proportion to the number of times it appears in the Bag. You present some interesting thoughts here. But I don't have enough time to think about any implications to the point of agreeing or disagreeing with that change, other than to say that the proposal seems reasonable at first glance. However, if the above proposal is done, I would still want an easy way to get the value-count pairs from a bag if I wanted them. I do agree though with the principle that sets and bags should be just as easy and terse to use as arrays. -- Darren Duncan
Re: Lazy Strings and Regexes
Francesco 'Oha' Rivetti wrote: On Sun, 31 Oct 2010 20:29:27 +0100, Moritz Lenz wrote: If we can efficiently match against a lazy string, and if this doesn't turn the lazy string into a (large) normal string, then the best way to process a file might be something similar to: my $fh = open ... err die; my $contents = cat($fh.lines); , followed by matching on $contents. Better still would be to provide a way for filehandles to be directly asked to produce a lazy Str which reflects the file. I guess there's no good reason not to have a .Cat method in the IO class - another thing that'll likely appear when Cats are implemented. What if a regexp may consider a lazy list of string as a single lazy string? i have no idea exactly what does could mean in practice, but i would like to see something like: MyGrammar.parse($fh.lines); or better: MyGrammar.parse($io); # which could be a file or a socket If you want to do that, please don't make it a behavior of lazy lists of strings, since that would be too magical. Instead, either do this using, for example, MyGrammar.parse() taking a Cat argument but that argument can be coerced from a string or array of string argument. -- Darren Duncan
Re: Tweaking junctions
Damian Conway wrote: If it's about parallel data handling, then we have to be prepared to (notionally) fork the entire rest of the runtime, even as far as having a definition of what return value the parent process sees (from "exit") when those threads are implicitly collapsed at termination. That's certainly true, although junctions are supposed to guarantee to coalesce all the threads they may generate back into a single superimposed result back in the originating thread. The problem only arises if an operation or subroutine that has been junctively threaded terminates without returning. But that's just "having a side-effect", which we already know is inappropriate for junctions (and hyperoperators, and autothreaded loops, and pretty much any other kind of parallel construct). Could thread termination without a return reasonably be treated 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
Re: Lists vs sets
yary wrote: I think of a list conceptually as a subclass of a set- a list is a set, with indexing and ordering added. Implementation-wise I presume they are quite different, since a set falls nicely into the keys of a hash in therms of what you'd typically want to do with it. If a list 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
Re: threads?
Aaron Sherman wrote: On Tue, Oct 12, 2010 at 10:22 AM, Damian Conway wrote: Perhaps we need to think more Perlishly and reframe the entire question. Not: "What threading model do we need?", but: "What kinds of non-sequential programming tasks do we want to make easy...and how would we like to be able to specify those tasks?" Things that typically precipitate threading in an application: - Blocking IO - Event management (often as a crutch to avoid asynchronous code) - Legitimately parallelizable, intense computing Interestingly, the first two tend to be where most of the need comes from and the last one tends to be what drives most discussion of threading. Perhaps it would make more sense to discuss Perl 6's event model (glib, IMHO, is an excellent role model, here -- http://en.wikipedia.org/wiki/Event_loop#GLib_event_loop ) and async IO model before we deal with how to sort a list on 256 cores... The last one in particular would legitimately get attention when one considers that it is for this that the concern about using multi-core machines efficiently comes into play. The first 2 are more about lowering latency and appearing 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
Re: [perl6/specs] 58fe2d: [S12] spec setting and getting values of attribute...
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 is a value expression whose execution results in an object which would eqv the original. Are you using "value object" in the same sense as in the Perl 6 specification? I'm essentially thinking in terms of the Perl 6 specified "value types" but I was actually being a little more general so to also include container objects whose current values could change over time; hence I used "eqv" rather than "==="; I didn't want the .perl to be more restrictive than necessary. Bottom line, if .perl isn't supposed to work on 100% of objects then we should fix .perl so it doesn't break encapsulation. +1. The question is: how? My proposal: the default .perl method should only spit out value for public attributes, ie those that have accessors. Maybe .new should also default to his behavior. I agree with this proposal, and would be happy for it like Damian. It would mean the langauge has a good, safe, default behavior, which does what people expect most of the time or is otherwise simple for users to understand and should be simple to implement. And individual classes can write their own .perl/etc when their public API is different from the corresponding internals. 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. 1) please don't abuse MONKEY_TYPING for anything that might look like dangerous Fair enough. In this case I was just echoing Damian's comment. The main idea was that any language built-in which exposes the otherwise private internals of an object should be only be accessible when the user explicitly enables access in a way that states they know what they're doing, such as by enabling a pragma. 2) I find .perl very, very valuable in real world debugging; I don't want to make it its usage any harder. So I suggest we utilize a debugging pragma that enables dumping an object's actual internals; people only get that by explicitly activating the pragma; this pragma could also implicitly be enabled by someone using a debugger. The dumping routine would not be called .perl but rather something else ... internals_perl() perhaps? -- Darren Duncan
Re: not using get/set (was Re: [perl6/specs] 4d77c0: ...)
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 but when you mentioned the various history of pairs I then thought of get/put related to I/O, as well as FTP, etc. Also "put" is clearly an action like "get" is, and they're the same length as you say, while "set" is both an action and not an action. So I amend my prior comment to highly recommend that "set" be renamed to "put" in contexts such as attribute accessors like this. The problem with put/set etc. is that they tend to fail to distinguish binding from assignment (which is bad - there's a reason we have different operators for them). In the REPR API I called this thing bind_attr to be clear that's what it's doing. Fair enough. I stand by my general comment that "set" shouldn't be used for things such as this and that there are better alternatives. -- Darren Duncan
Re: [perl6/specs] 58fe2d: [S12] spec setting and getting values of attribute...
Carl Mäsak wrote:
To summarize, I consider myself having lost that debate. I even
demonstrate the complete unviability of my views (that privacy has any
kind of footing in Perl 6) with the below one-liner.
rakudo: class X { has $!foo; has $!bar; has $!baz }; say
eval(X.new( foo => 1, bar => 2, baz => 3).perl.subst("X.new(", "\{
").subst(/\)$/, " }")).perl
rakudo 8156be: OUTPUT«{"foo" => 1, "bar" => 2, "baz" => 3}»
As long as C<.perl> works the way it does, there can be no real
privacy. And thus C<.get_value> and C<.set_value> are just convenient
access points for the same behaviour.
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 is a value expression whose
execution results in an object which would eqv the original.
It should be possible to provide all the information to construct said object
with a single constructor/new() call, and such a new() call is what .perl should
be producing.
Such as in this context, private attributes are about letting the class designer
have arbitrary differences between the public possible representation and
internal actual representation of an object and the class knows how to map them;
moreover, it should have enough knowledge to make this a 2-way mapping. (Maybe
the type system needs more metadata for that to be automatic? Maybe not?)
Also, some private attributes are redundant and don't need to be separately
turned into source code, such as if they are a cache or something.
The .perl should just use a class' mechanism for producing a complete set of
new() arguments and produce code for that.
Objects that you can't do that with don't make sense to be serialized and so
.perl can reasonably refuse to work on them.
I don't think anyone can argue that every object of every class can reasonably
be serialized with .perl and so it should only try where it makes sense. Now if
.perl is also savvy enough to take a reference to a subroutine and can produce
the source code for said subroutine, I'd have a bit less of a case.
Bottom line, if .perl isn't supposed 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
Re: not using get/set (was Re: [perl6/specs] 4d77c0: ...)
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 but when you mentioned the various history of pairs I then thought of get/put related to I/O, as well as FTP, etc. Also "put" is clearly an action like "get" is, and they're the same length as you say, while "set" is both an action and not an action. So I amend my prior comment to highly recommend that "set" be renamed to "put" in contexts such as attribute accessors like this. -- Darren Duncan
not using get/set (was Re: [perl6/specs] 4d77c0: ...)
nore...@github.com wrote: Commit: 4d77c0bb74957e31934c45ad8b4a990e0f6c024e http://github.com/perl6/specs/commit/4d77c0bb74957e31934c45ad8b4a990e0f6c024e Author: TimToady Date: 2010-09-29 (Wed, 29 Sep 2010) This change includes the addition of get_value() and set_value() routines. I would argue that naming accessors get/set is a bad idea, "set" in particular, because "set" would easily evoke thoughts of having something to do with "set" collection types and values. Instead, much better names for the updating accessor are either "update" or "store" or "assign", and I personally prefer "update" between the three. As for "get", that is less of a problem as it is, though it could alternately be spelled either "fetch" or by leaving the prefix off; for an example of the latter, the 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
meaning of "range" - use "interval" instead?
Larry's updating the Synopsis terminology to say "sequence" instead of "series"
for correctness led me to check out what seems to be a similar problem, "range".
I believe that the Synopsis should just use the term "interval" for what it
currently calls "range" (and "Interval" for "Range"); currently it uses both
terms and Perl 6 has related types named "Range" and "RangeIter".
The problem stems from "range" having multiple relevant meanings in practice:
1. A "where" or "region" kind of meaning, where it is used in the same way as
"interval", as being a collection of everything between 2 locations/points.
2. A "how much" or "distance" kind of meaning, where it is the (scalar)
distance between 2 locations/points.
The relationship between these is like a generalization of the relationship
between a temporal interval (with 2 temporal instant endpoints) and a temporal
duration.
There is also a third meaning of "range" meaning the set of possible output
values of a function, corresponding to "domain" as the set of possible inputs.
I believe that the name Interval is much more specific to the meaning that Range
is going for, without having the other meanings that can confuse, while Range is
more likely to confuse.
In particular, what would someone expect a function named range() to do?
It is often the case that range() would be expected take a nonempty set of
numbers and return a number that is the difference between the largest and
smallest numbers in the set. For example, "range(5,-3,0,6,2,-1)" would return 9
(6-(-3)); similarly, "range(25..52)" would return 27.
A range() function would be in the same category of functions as mean(),
median(), mode(); each takes a nonempty set of numbers and returns a single number.
Now if Range were renamed to Interval, I don't see this as being a problem for
anyone. Sure, Interval is a longer word, but how often would the name of that
type be written out in code? Usually one produces an interval using ".."/etc
notation anyway.
As for places you want to abbreviate, I recommend "Ivl" ("Int" won't work,
obviously); it looks visually different and emphasizes distinct sounds. For
example, with "IvlIter"; granted, this doesn't read as well as "RangeIter", but
would either appear in code that often anyway and not be more of an internal
thing that's used implicitly?
So then, just use "interval" etc for 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
Re: [perl6/specs] 177959: s/series/sequence/ to accord with math culture
nore...@github.com wrote: Commit: 17795925bc48affda10275bd2768e1f2d9ef6345 http://github.com/perl6/specs/commit/17795925bc48affda10275bd2768e1f2d9ef6345 Author: TimToady Date: 2010-09-23 (Thu, 23 Sep 2010) Log Message: --- s/series/sequence/ to accord with math culture To a mathematician, a series is the sum of a sequence. We don't want to confuse the poor mathematicians any more than they already are. These kinds of changes are always welcome. Anything that will be more correct to the mathematicians/logicians/etc without being appreciably worse to anyone else is a good thing, this being an example. -- Darren Duncan
Re: requiring different vers per auth
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 scheme, and the code is compatible with different : version ranges from each authority, then how does the code express : this? Search for "emulates" in S11. I already know about "emulates" and it didn't seem applicable because "emulates" is something you would put in a package declaration so a package declares it emulates another one. But what I'm asking is what a user does when none of the versions of the package they want to use declare "emulates". -- Darren Duncan
requiring different vers per auth
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 scheme, and the code is compatible with different version ranges from each authority, then how does the code express this? For example, say that either of the following would be acceptable: use Foo:auth:ver(1..3,5..*) use Foo:auth:ver(2..9) From S11 I see that one can indicate too many versions like: use Foo:auth(PERIL|PURILE):ver(1..*) ... or too few versions like: use Foo:auth(PERIL|PURILE):ver(2..3,5..9) ... assuming that these "use" would specify the cartesian product of "auth" and "ver". But how does one best express what I actually said would be acceptable, the full "ver" range per "auth" and only that? Can you say something like this?: use Foo:(auth:ver(1..3,5..*)|auth:ver(2..9)) ... but maybe with different syntax? -- Darren Duncan
Re: [perl6/specs] 761178: remove some some duplicate words words
Jason Switzer wrote: On Tue, Sep 7, 2010 at 11:29 AM, Moritz Lenz wrote: Brandon S Allbery KF8NH wrote: On 9/7/10 08:17 , nore...@github.com wrote: Commit: 7611788411e5aff5f3ae150e2da9929ee546d6d8 http://github.com/perl6/specs/commit/7611788411e5aff5f3ae150e2da9929ee546d6d8 It was nicer when these contained the actual diffs like they used to, instead of forcing me to go poke at the tree. Indeed. Any contributions to restoring that behavior are very welcome. I'm surprised anyone actually ever read the diff part of the message. I would prefer to never see that feature again. This has a link to the commit, which has a much better diff viewer than plaintext email (hello? 1997 called, they want their change notices back). It links to the actual change and even highlights the changes. Now I'll actually take a moment to sift through the changes. I vote to never see those diff emails ever again. In fact, if the diffs are brought back, I'll just subscribe to the commit feed and skip the email notice all together. I like the email diffs and think that both they plus the link to the web diff should be in the emails. Sure, the web page diffs are prettier, but the email diffs are much more convenient, and pretty enough. With the email we don't have to click a link to see what changed. And particularly important, if we want to reply with a *comment* on the diff, it is easy to cite the portions we're commenting on, because a simple reply on the list message has the diffs quoted. -- Darren Duncan
Re: Pragma to change presentation of numbers in Perl 6.
Matthew wrote: Today I propose a pragma that changes how numbers are presented in Perl 6. The idea arises from a discussion on the freenode channel #perl6, available here: http://irclog.perlgeek.de/perl6/2010-09-01#i_2773432 I only see this pragma as being useful within limited circumstances, such as when applied lexically for when you want to use a large number of numeric literals in some other base, rather than always at a file level. Generally speaking, I see it better to explicitly specify the base with each number when that base isn't ten, because it is much easier for people to correctly read the code. Believe me when I say I empathize with wanting to let other numeric bases have equal treatment to base 10, but I believe the best way to do that in general is support a common syntax for specifying the base with each number, and Perl 6 already provides this. 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
Re: pattern alternation (was Re: How are ...)
David Green wrote: On 2010-08-05, at 8:27 am, Aaron Sherman wrote: On Thu, Aug 5, 2010 at 7:55 AM, Carl Mäsak wrote: I see this particular thinko a lot, though. Maybe some Perl 6 lint tool or another will detect when you have a regex containing ^ at its start, $ at the end, | somewhere in the middle, and no [] to disambiguate. I think conceptually the beginning and the end of a string feels like a bracketing construct (only without symmetrical symbols). At least that seems to be my instinct. Well, it doesn't in / ^foo | ^bar | ^qux /, but in something like /^ foo|bar $/, the context immediately implies a higher precedence for ^ and $. Maybe something like // foo|bar // could work as a bracketing version? Personally, I had always considered the ^ and $ to be the lowest precedence things in a pattern. But I can understand the flexibility one gains from that not being so, having seen David's example here, which it never occurred to me before was possible. -- Darren Duncan
Re: declaring versions (was Re: How ...)
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. Backwards compatibility can be achieved with version-specific shims over top of this single core, which translate works written to an older spec to their equivalent in the new one. Because versions are explicitly declared, it is trivial to dispatch to the correct interpreter or pseudo-interpreter. As an addendum to this thought ... If a system is also capable of generating a source work from a parsed version that is effectively the same as the original, it should also be possible for a user to request a source translation from some older understood spec version to a newer/current one. So they can be assisted in keeping their sources up to date without having to manually keep updating them, in general. Then when support for older formats is deprecated and removed, by that time their source will have been updated so it is still interpretable without manual updates. Of course, supporting this is optional, but its useful. Like a Perl 5 to Perl 6 translator but on much finer and easier to do scales. -- Darren Duncan
declaring versions (was Re: How ...)
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 different sources, as some others have suggested. That said, I'm inclined to think that the likely complexity of the documentation system over time should grow by fewer orders of magnitude than code in general, and so I grant that some ideas can look like over-engineering. Explicit versioning is your friend. Can I get some support for this? Not from me. ;-) I think it's a dreadful prospect to allow people to write documentation that they will have to rewrite when the Pod spec gets updated. Or, alternatively, to require all Pod parsers to be infinitely backwards compatible across all versions. :-( One main purpose of declaring the intended interpretation context of a work is so that developers of interpreters have a lot more freedom to *not* be backwards-compatible. Each version is effectively a separate language in some ways. Because a work declares its language version, one should be able to take the work anywhere and it would be completely unambiguous as to how to interpret it, no matter how old it is and how much the state of the art has evolved. If the meaning of a keyword changes in a spec, we know without a doubt which meaning the user intended. As for backwards compatibility, this is actually less onerous to implement with my proposal than otherwise. For one thing, if developers want to make an incompatible change, they can release it right away, without a long deprecation or changeover cycle, and in the typical case old works will continue to be interpreted correctly. 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. Backwards compatibility can be achieved with version-specific shims over top of this single core, which translate works written to an older spec to their equivalent in the new one. Because versions are explicitly declared, it is trivial to dispatch to the correct interpreter or pseudo-interpreter. Yet another thing, parsers don't have to be infinitely backwards compatible; they can deprecate support for particular older versions as they choose to, when necessary and reasonable. So, explicit versioning is actually very good for *future-proofing*. I believe there are various precedents for this. In the Perl 5 world, for example, see "autodie" (optional) or "perl5i" (mandatory). use autodie qw(:1.994); use perl5i::2; I have also done this from day one in my Muldis D language, and I have no regrets for doing so. -- Darren Duncan
pattern alternation (was Re: How are ...)
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 contain anything other than the alternatives? I would have thought them optional in the case I mentioned. Rather, they would just be necessary in a case like this: /^ foo [<[A..Z]>+ | <[a..z]>+] bar $/ -- Darren Duncan
Re: How are unrecognized options to built-in pod block types treated?
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 languages are strange beasts, and i don't know the answer. Just say that names consisting entirely of either ASCII-range uppercase letters or ASCII-range lowercase letters are reserved, and that names having either both of those or any of those plus non-ASCII letters are not reserved. The only way I see this being a problem is if we forsee that we might want to have official names going out of the ASCII repertoire, which I would recommend we don't. For the first, you're also excluding scripts that lack the notion of case: Hebrew and Arabic, and all of the ideograms, etc. As to the latter, Perl 6 already has «» and ASCII equivalent <<>>; I would expect similar would be possible and supported in this context. (Yes, I know, I'm not helping. Only thing that occurs to me is something like "x-foobie:".) Read what I said again. I was proposing that the namespace comprised of names matching a pattern like this: /^ <[A..Z]>+ | <[a..z]>+ $/ ... be reserved for official use and the complementary namespace be available for users to define names in. So users can use anything with non-ASCII characters plus those with mixed-case ASCII. So users aren't excluded from using Hebrew or Arabic characters due to what I said, but only that official names wouldn't use them. -- Darren Duncan
Re: How are unrecognized options to built-in pod block types treated?
There's also potentially another simple solution, which in some ways is superior, and means we can avoid the whole thing about upper/lowercase being significant, that case thing honestly seems like a cludge. Use namespaces. In the generic sense, we could say that all names are in at least one level of namespace. Perl just reserves a namespace for itself for official names, and the other namespaces are available for use by others. For brevity, the namespace qualifier may be omitted when referring to the Perl-reserved namespace, and so any names that appear unqualified are assumed to be there by default. This is somewhat analogous to the main:: namespace for Perl code. A parallel solution would be that POD can declare a version, similarly to how Perl code can declare a Perl version, whose spec it is expected to be interpreted according to. If POD declares that it is written to a particular version of the POD spec, then any unqualified names are taken as reserved ones iff that version of the POD spec included them, and they are taken as user-defined otherwise. I really think that's the way to go. It can also be documented that the official POD 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
Re: How are unrecognized options to built-in pod block types treated?
jerry gay wrote: On Wed, Aug 4, 2010 at 15:56, Damian Conway wrote: Specifically, I think it would be easiest to be consistent and say that all purely lowercase and all purely uppercase config option names are reserved, and that unrecognized reserved config options generate at least a warning when they are parsed. Mixed-case config options should be freely available to users and the parser should simply accept them without complaint and include them in the internal data structure it builds, whereupon they will be available to user-defined Pod extensions. 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 languages are strange beasts, and i don't know the answer. There's a simple solution to that. Just say that names consisting entirely of either ASCII-range uppercase letters or ASCII-range lowercase letters are reserved, and that names having either both of those or any of those plus non-ASCII letters are not reserved. The only way I see this being a problem is if we forsee that we might want to have official names going out of the ASCII repertoire, which I would recommend we don't. -- Darren Duncan
rounding method adverbs
Martin D Kealey said (in the a..b thread): >> So then, "a" cmp "ส้" is always defined, but users can change the >> definition. > > I take the opposite approach; it's always undefined (read, unthrown > exception) unless the user tells us how they want it treated. That can be a > command-line switch if necessary. > > To paraphrase Dante, "the road to hell is paved with Reasonable Defaults". > Or in programming terms, your reasonable default is the cause of my ugly > work-around. That might be fair. But if we're going to do that, then I'd like to go a step further and require some other operators have mandatory config arguments for users to explicitly state the semantics they want, but that once again a lexical pragma can declare this at a higher level. Specifically, I think there should be a configuration for any numeric operations that might do rounding, where users specify the rounding method employed. For example, the Int-resulting division and modulo operators should require specifying how to round on an uneven division. I can think of at least 9 rounding methods to choose from off the top of my head: up (ceiling), down (floor), to-zero (truncate), to-infinity, half-up (common), half-down, half-to-zero, half-to-infinity, and half-to-even (statistics, banking, etc). There are probably more, so this should be extensible. The point here is that there are multiple distinct expectations on what is a reasonable default way to do numeric rounding, and it would be a lot more clear for everyone reading code if these semantics were spelled out. Just because such as default is stated in the Perl 6 manual doesn't mean it won't constantly trip people up all the same. In particular, common programming languages are often split between down/floor and to-zero/truncate as their semantics, and I believe even Perl 5 and Perl 6 differ on the issue. Having these options provided also supports some other common tasks. For example, the up/ceiling option would be common, if the task is to figure out how many containers we need to hold our widgets, or how many rows in which to display multi-column data. For example: $num_boxes_needed = $num_widgets div $box_capacity :round(Up) Similarly, explicitly stated rounding semantics are useful for non-integer operations such as currency or statistics or science. Also useful when we want to emulate other languages in Perl 6 elegantly and even-handedly. Now, of course, some rounding methods may be more efficient than others on particular hardware, but that's just something that should be documented, 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
Re: Suggested magic for "a" .. "b"
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 behaviour they want. The customization could be applied at various levels, such as using an extra argument or trait for the operator/function that cares about ordering, That much I agree wholeheartedly with, but ... or by using an extra attribute or trait for the types being sorted. ... puts us back where we started: how do we cope if the two endpoints aren't tagged with the same attribute or trait or locale? In any case I'd much rather prefer that the behaviour be lexically scoped, with either adverbs or pragmata, not with the action-at-a-distance that's caused by tagging something as fundamental as a String. Lexical scoping *is* a good idea, and I would also imagine that users would frequently apply that at the file or setting level. But making this a pragma means that the pragma would have to be a little more verbose than a typical pragma. In the general format, one wouldn't just say, eg: collation FooNation; ... but rather it would at least be more like: collation Str FooNation; ... to say that you're only applying to operations involving Str types and not, say, Numeric types. So then, "a" cmp "ส้" is always defined, but users can change the definition. I take the opposite approach; it's always undefined (read, unthrown exception) unless the user tells us how they want it treated. That can be a command-line switch if necessary. To paraphrase Dante, "the road to hell is paved with Reasonable Defaults". Or in programming terms, your reasonable default is the cause of my ugly work-around. That might be fair. But if we're going to do that, then I'd like to go a step further and require some other operators have mandatory config arguments for users to explicitly state the semantics they want, but that once again a lexical pragma can declare this at a higher level. I'm restating this thought in another thread, "rounding method adverbs", so that's the best place to follow it. -- Darren Duncan
Re: Smart match isn't on Bool
TSa (Thomas Sandlaß) wrote: ... unless you want C to do a value-and-type check, in which case it doesn't exactly follow the pattern for smartmatching of the other builtin types (which only check value equivalence, not type equivalence). This is true only if you want to distinguish 1 and True which are the same value. But 42 should be distinct from this. Same goes for "viaduct". So these three should be a valid disjoint set of choices that can be made given $something. Is that so? 1 and True *are* the same value now? Not Bool wraps Int rather than being a subset type and it and has wholly distinct values? Carl Mäsak wrote: > I don't know whence you got the impression that Bool is a subtype. > Bool is an enumeration type, which makes True and False distinct > objects both of which aren't (but instead wrap) their corresponding > Int values. > >> Asking "False eqv 0" should be false, though either "False eqv ?0" or >> "+False eqv 0" being true is okay. > > All those are as you want them. I would like for what Carl said to be true, but TSa seems to be contradicting it. 1 and True should *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
Re: Smart match isn't on Bool
David Green wrote:
given $foo :using( [===] ) { ... }
given $foo :using(&binary-func) { ... }
I do like the general principle of what you're proposing, that one can customize
the semantics of how given-when picks options. But I have no further details to
suggest at this time. -- Darren Duncan
Re: Smart match isn't on Bool
Brandon S Allbery KF8NH wrote:
I think there's a confusion about what given/when is doing. Naïvely(?), I
expect it to be shorthand where the value for "when" is matched against the
one for "given", thus your example would be (pseudocode) "if 0 == True" and
expecting "OH NOEZ" *would* be unreasonable.
Is given/when trying to do too many things at once?
I would prefer if given/when was nothing more than an alternate syntax for
if/then that does comparisons. That is, these would be equivalent:
given $foo {
when $bar {...}
when $baz {...}
default {...}
}
if $foo eqv $bar {...}
else if $foo eqv $baz {...}
else {...}
On the other hand, Perl 6 has multiple equality comparison operators, eqv, eq,
==, ===, etc, and hence ~~ semantics instead of eqv may seem to make some sense,
though I think that would cause more problems.
So I think if given-when just used eqv semantics and then users explicitly
coerced their arguments instead, that might be best. For example, in the
general case, say they want numeric semantics and the arguments aren't
necessarily already numbers:
given +$foo {
when +$bar {...}
when +$baz {...}
default {...}
}
All this being said, I really do *not* like the idea of saying Bool is just a
subset of Int as it seems to be. Bool should be disjoint from every other
common type like Int/Str/etc instead.
Asking "False eqv 0" should be false, though 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
Re: Suggested magic for "a" .. "b"
Jon Lang wrote: I don't know enough about Unicode to suggest how to solve this. All I can say is that my example above should never return a valid Range object unless there is a way I can specify my own ordering and I use it. That actually says something: it says that we may want to reconsider the notion that all string values can be sorted. You're suggesting the possibility that "a" cmp "ส้" is, by default, undefined. 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 behaviour they want. The customization could be applied at various levels, such as using an extra argument or trait for the operator/function that cares about ordering, or by using an extra attribute or trait for the types being sorted. In fact, this whole issue is very close in concept to the situations where you need to do equality/identity tests. With strings, identity tests can change answers depending on whether you are doing it on language-dependent or language-independent graphemes, and Perl 6 encodes that abstraction level as value metadata. When you want to be consistent, the behaviour of "cmp" affects all of the other order-sensitive operations, including any working with intervals. Some possible examples of customization: $foo ~~ $a..$b :QuuxNationality # just affects this one test $bar = 'hello' :QuuxNationality # applies anywhere the Str value is used Also, declaring a Str subtype or something. Of course, after all this, we still want some reasonable default. I suggest that for Str that aren't nationality-specific, the default ordering semantics are by whatever generic ordering Unicode defines, which might be by codepoint. And then for Str with nationality-specific grapheme abstractions, the default sorting can be whatever is the case for that nationality. And this is how it is except where users define some other order. So then, "a" cmp "ส้" is always defined, but users can change the definition. -- Darren Duncan
Re: Suggested magic for "a" .. "b"
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
Re: Suggested magic for "a" .. "b"
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 is how often the
versions that exclude endpoints would be used, such as "^..^".
I would imagine that a sequence generator would also have this variability
useful.
Does "..." also come with the 4 variations of endpoint inclusion/exclusion?
If not, then it should, as I'm sure many times one would want to do this, say:
for 0...^$n -> {...}
In any event, I still think that the mnemonics of "..." (yadda-yadda-yadda) are
more appropriate to a generator, where it says "produce this and so on". A ".."
does not have that mnemonic and looks better for an interval.
-- Darren Duncan
Re: Suggested magic for "a" .. "b"
Aaron Sherman wrote: The more I look at this, the more I think ".." and "..." are reversed. ".." has a very specific and narrow usage (comparing ranges) and "..." is probably going to be the most broadly used operator in the language outside of quotes, commas and the basic, C-derived math and logic ops. Many (most?) loops will involve "...". Most array initializers will involve "...". Why are we not calling that ".."? Just because we defined ".." first, and it grandfathered its way in the door? Because it resembles the math op? These don't seem like good reasons. I would rather that ".." stay with intervals and "..." with generators. The mnemonics make more sense that way. Having ".." resemble the math op with the same meaning, intervals, is a good thing. 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
Re: Suggested magic for "a" .. "b"
Michael Zedeler wrote: This is exactly why I keep writing posts about Ranges being defunct as they have been specified now. If we accept the premise that Ranges are supposed to define a kind of linear membership specification between two starting points (as in math), it doesn't make sense that the LHS has an additional constraint (having to provide a .succ method). All we should require is that both endpoints supports comparison (that they share a common type with comparison, at least). Yes, I agree 100%. All that should be required to construct a range "$foo..$bar" 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
Re: r31789 -[S32] DateTime immutable, leap seconds validation
Nicholas Clark wrote: I think one weakness of Parrot is that it uses almost no Parrot-based language in its own build system. You need to know Perl 5 or C to be useful to the Parrot core. And if you gain your fun by working on the Parrot core, you actually stop being a Parrot user, and hence experiencing what they experience. Well, one major roadmap item for Parrot 3.0 of January 2011 is to eliminate the dependency on Perl 5. And so we should have more dogfooding within 5 months. Which is good, since then Parrot/Rakudo will be more at the level of typical language implementations, not dependent on any language besides themselves and C. -- Darren Duncan
Re: Suggested magic for "a" .. "b"
Larry Wall wrote: On Tue, Jul 20, 2010 at 11:53:27PM -0400, Mark J. Reed wrote: : In particular, consider that pi ~~ 0..4 is true, : because pi is within the range; but pi ~~ 0...4 is false, because pi : is not one of the generated elements. Small point here, it's not because pi is fractional: 3 ~~ 0...4 is also false because 3 !eqv (0,1,2,3,4). There is no implicit any() on a smartmatch list pattern as there is in Perl 5. In Perl 6 the pattern 0..4 may only match a list with the same 5 elements in the same order. For some reason I thought smart match in Perl 6, when presented with some collection on the right-hand side, would test if the value on the left-hand side was contained in the collection. So, for example: my @ary = (1,4,3,2,9); my $test = 3; $test ~~ @ary; # TRUE Similarly, since a range represents a set of all values between 2 endpoints, I might 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
Re: Suggested magic for "a" .. "b"
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
Re: Suggested magic for "a" .. "b"
Aaron Sherman wrote: 2) The spec doesn't put this information anywhere near the definition of the range operator. Perhaps we can make a note? This was a source of confusion for me. My impression is that a "Range" primarily defines an "interval" in terms of 2 endpoint values such that it defines a possibly infinite set values between those endpoints. For example, 'aa'..'bb' is an infinite sized set that includes every possible character string that starts with the letter 'a', plus every one that starts with the string 'ba'. And so, asking $anysuchstring ~~ 'aa'..'bb' is TRUE. (Note that for ".." to work, its 2 arguments would need to be of the same type, so that we know which set of rules to follow. Or to be specific, the generic "eqv" operator, or "before" etc would have to be defined that takes both of the ".." arguments as its arguments. Although this might be fuzzed a bit if the spec defines somewhere about automatic casting. For example, if someone said 'foo'..42 then I would expect that to fail.) A "Range" can also be used in a limited fashion to generate a finite list of values, but that is not its primary purpose, and the "..." operator does that job much better. 3) It seems that there are two competing multi-character approaches and both seem somewhat valid. Should we use a pragma to toggle behavior between A and B: A: "aa" .. "bb" contains "az" B: "aa" .. "bb" contains ONLY "aa", "ab", "ba" and "bb" I would find A to be the only reasonable answer. If you want B's semantics then 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
Re: r31777 -[S32/Temporal] Reverted DateTime back to being mutable. I think we ought to make a big change like this only after reaching some kind of consensus to do so, not least because I just implem
pugs-comm...@feather.perl6.nl wrote: Modified: docs/Perl6/Spec/S32-setting-library/Temporal.pod Log: [S32/Temporal] Reverted DateTime back to being mutable. I think we ought to make a big change like this only after reaching some kind of consensus to do so, not least because I just implemented a lot of mutating methods! Note that += and friends need only the *container* on the LHS to be mutable, not the value?\226?\128?\148'$x += 1' should be allowed whether $x holds an Int, a Date, or a DateTime. Types representing temporal artifacts should *not* be mutable; they 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
Re: r31735 -[spec] Say a bit about Numeric operators and Bridge.
pugs-comm...@feather.perl6.nl wrote: Author: colomon Date: 2010-07-16 20:39:33 +0200 (Fri, 16 Jul 2010) New Revision: 31735 Modified: docs/Perl6/Spec/S32-setting-library/Numeric.pod Log: [spec] Say a bit about Numeric operators and Bridge. +Users who provide their own scalar real numeric types are encouraged to implement the +C role. Because all C types are well-ordered, it is desirable that any two +C types be mutally compatiable, even if they are not aware of each other. The +current proposal requires you to define a C method in your C type, which +converts your type into a neutral C type by restating it in terms of the fundamental +Perl 6 types and calling C on them. This then makes the default C methods +and operators all work with your C type. While the name of this method may changed, +it is hoped that something like this will remain in the spec. Is there some 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
Re: r31630 -S02 : add initial formats for Blob (or Buf) literals
pugs-comm...@feather.perl6.nl wrote: =item * +Blob literals look similar to integer literals with radix markers, but are +distinct in their details. A Blob literal has 1 format with 3 radix +options: + +0b<00101110100010> base 2, 1 bit per column +0o<523504376> base 8, 3 bits per column +0x base 16, 4 bits per column + +TODO: Expand this for more generality. Meanwhile, this existing +definition covers the common cases of specifying in bits and hexits. Note that another option might be substitution of a quotation-pair for the <>: 0b'00101110100010' base 2, 1 bit per column 0o'523504376' base 8, 3 bits per column 0x'A705E' base 16, 4 bits per column But the general idea is that a Blob/Buf literal ought to look like something between an integer 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
Re: Perl 6 in non-English languages
yary wrote: Reminds me of an article of yore from The Perl Journal "Localizing Your Perl Programs" http://interglacial.com/tpj/13/ which discusses the reasoning behind Locale::Maketext the point of which is that the "values" you're looking up should be able to be functions, 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 treated in exactly the same way as far as where their user text is stored and what format it has. The common format could in fact be a Perl module for each language containing the user text, and these all do a common role representing all the messages that could be used. You should not be treating the user text for one language differently from others, by using the text of one language to look up the text of another, or by embedding one user language in the main program code. Now, this isn't to say that the common key can't resemble English, but you should still have the separate copies of all the messages that are the actual user text, and the common English-like key can be a simplified version. A main point here is that if any translator or human-interfaces person wants to tweak user text, say to capitalize a word or fix a misspelling, they shouldn't have to go into the main program code to do it, and the process is the same for every language, and you only have to update not more than one copy or location per language. Something I want to avoid is the actual English user text being used to look up the others, because then if you want to tweak a misspelling or something in English, you'd then have to find an change all the other copies of the text in order for the mapping to be maintained. Its a similar problem actually to a bad relational database design, where you use something descriptive and likely to mutate (such as the English name of a product for sale) as the column that a foreign key copies and points to, in contrast to say a less descriptive product code. What I am proposing is to use the analogy of the product code in your main code rather than the English product name. But the code can still be quite English like. Such as a role's function name can be English like. -- Darren Duncan
Re: Perl 6 in non-English languages
Moritz Lenz wrote: However there are things that can be translated to other languages, and that is documentation, error messages and warnings. And the next step is non-error messages intended to be seen by users. The latter two require that we standardize exception types and messages, and provide some means to load different localizations. If somebody could take on that project, that would be really great for non-English speakers (and would also help the standard, English implementation, because standardize exceptions make testing of meaningful errors much easier). That would be a real benefit for the Perl 6 landscape at large, and probably not all too difficult (I'm sure that implementors of compilers and STD.pm will help with technical details where necessary, I for one would do my best to integrate such an effort into Rakudo). I highly recommend a key-based approach, such that not even the English versions of these error messages and warnings etc are in the program code, but rather are in separate files, in the same format as versions of any other languages, and that the only thing actually in the code is a non-human-language lookup key, though that can be meaningful to programmers such as a variable name is. See my simple Locale::KeyedText module for a working proof of concept of what I speak of. Its the first module of mine that has matching Perl 5 and Perl 6 versions, and I had produced the Perl 6 version in 2005 as part of the early Pugs development effort. This said, I haven't updated it in years and I don't expect it to still run under Rakudo, but it did run under Pugs in the day. The concept I describe and demonstrated is inspired by how Mac OS X works, where all user text is in separate language resource 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
Re: Announce: Rakudo Perl 6 development release #30 ("Kiev")
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" at some point? I thought I read recently that "Star" would be coming in June. -- Darren Duncan Rakudo Star is a parrallel release series; however, it is not a series of compiler releases, but a series of complete Perl 6 environments. A single release of Rakudo Star will contain: - Some version of Rakudo (not necessarily a monthly) - Some version of Parrot - Some random libraries - Documentation all vetted to work OK together. Ah, that's even better than I expected. So then the experience to a Perl 6 user could be like the same opaque experience of installing Perl 5 or some other language, where the whole language implementation is together and a single configure/make/etc will take care of everything, and users don't have to know about the distinct Parrot+Rakudo+etc components if they don't want to, as they get the "perl" binary. Will this package work on Windows too like Strawberry for Perl 5 (I'm not a Windows user but that's a valuable project), or just Unixen for now? -- Darren Duncan
Re: Announce: Rakudo Perl 6 development release #30 ("Kiev")
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
Re: r31051 -[S02] refine Blobs to simply be immutable Bufs, with similar generic characteristics
pugs-comm...@feather.perl6.nl wrote: Author: lwall Date: 2010-06-02 19:30:34 +0200 (Wed, 02 Jun 2010) New Revision: 31051 Modified: docs/Perl6/Spec/S02-bits.pod Log: [S02] refine Blobs to simply be immutable Bufs, with similar generic characteristics Thank you for this change; it was essentially what I wanted with the Blob type. @@ -666,6 +666,8 @@ Callable Positional Associative +Buf +Blob However, I believe a further change is needed. With the above addition, you have both Buf and Blob roles as well as Buf and Blob types. I think you need to make each of those just a role or a type, and then add another named entity which is the counterpart role or type. For example, as you have Stringy as a role with the Str type, maybe you can have Blobby with the Blob. And maybe Buffy with the Buf? The Perl community already seems to like such puns, so why not? Or otherwise clarify what Buf and Blob each are. -- Darren Duncan
Re: eqv and comparing buts
Larry Wall wrote: Or going the other direction, perhaps we're missing a primitive that can produce a data structure with the type information stripped, and then eqv might be able to determine structural equivalence between two canonicalized values. Often you still want to know the declared type, though, because while sometimes we want things to be equivalent if they are structurally equivalent, other times we don't. A declared type implies a particular intended interpretation of a value. For example, we could have two classes named Weight and Distance, both of which have a single Num-typed attribute named $v. A structural comparison of a Weight.new(3) and a Distance.new(3) may consider them equal, but logically we would want those two to not compare equal, because no weight is a distance or vice-versa, so every Weight should compare as not equal to every Distance. Ignoring the declared type only really makes sense when the two values are subtypes of a common parent type. It only makes sense for objects of two classes to be declared equal if you can say that a value of a type "is a" value of the other type. For example, it makes more sense (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
ANNOUNCE - Muldis D version 0.129.1
c to Muldis D and its implementations: "-announce", "-devel", and "-users"; just the latter 2 are for discussions. If you want a "homepage" url to link to, you can use http://www.muldis.com/ concerning this project or particularly its commercial support. And http://github.com/muldis/ is its main public GIT version control repository. Thank you in advance for any interest in or support for this project that you can give. Any kind of support is welcome, from trying to update your own projects to use Muldis D, or from contributing your time and expertise to improving Muldis D or its implementations or ancillary projects, or promoting this project in various 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
Re: Proposal for a new Temporal time-measurement paradigm
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 say using Perl's ordinary numeric and string types for internal representation, and Perl's single core now() routine they can use to determine 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(). I think you're taking minimalism at least two steps too far; your bikeshed has become too small to contain a bike. A standard library can and should provide reasonable functionality. We _know_ that the North-Western civilizations' common understanding of time (calendars and time-of-day), as defined in various standards, are fundamental to how we handle a lot of programming problems. I don't see any good reason not to provide the basic functionality needed, and especially not when it's already there. Mark J. Reed wrote: Absolutely ridiculous. The Gregorian calendar is in universal use for civil purposes and definitely belongs in the core. Just because things are practically universal or commonly used doesn't necessarily mean they belong in the Perl 6 core. Granted, many things that are commonly used do belong in the Perl 6 core, when they are relatively simple such as basic generic numbers and strings and collections. But the Gregorian calendar and related matters are sufficiently complex that they should be a non-core component, because both they are sufficiently complex and because their definitions change frequently enough over time, and so they should be free to be developed and updated independently of the Perl 6 core. Case in point, see the Perl 5 DateTime module. This module is frequently updated just for reasons of giving it an updated time-zone database or a database of leap-seconds. It is also updated for other reasons. Keeping these details out of the core frees them up to be easier to keep up to date on a schedule independent of the Perl 6 core. If anything, your argument about Gregorian being universal or common should be an argument for Perl packagers to bundle Gregorian-knowledgeable temporal modules, so that users get them by default. But then there would also be a package-managing system for more easily keeping those non-core components updated as new time-zone databases or leap-second measurements are made. My argument still stands; it is better to not have Gregorian et al in the language core, and rather it should be a recommended module for bundlers. -- Darren Duncan
Re: Proposal for a new Temporal time-measurement paradigm
I want to clarify that I currently believe that the Perl 6 core should only include temporal roles and *no* temporal classes. So the Perl 6 core could provide, say, 3 roles, Instant, Duration, and Calendar (or use some other name for the last one). It would also provide now(), sleep(), and calendar() routines that have signatures of Instant, Duration, and Calendar, respectively, without necessarily being more specific. And so, what now() returns would then be entirely implementation-defined; all Perl 6 guarantees is that now() would return some object that does Instant but not what class that object is nor what any of its capabilities are. Each Perl 6 implementation would be responsible for bundling at least one non-core module of its own choice that provides a class for each of the 3 core roles, such that now() can return something on that system. Or alternately, now() doesn't actually have to work at all, say if this Perl is to run say on some embedded system all of whose programs don't need a clock, in which case no implementing classes are bundled. The Calendar role would be the role composed by values that you get from introspecting the return value of now() so that you know in a more generic sense what that Instant-doing object is capable of. You could consult calendar() to introspect what classes now() and sleep() use and know about how to interpret them. 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 say using Perl's ordinary numeric and string types for internal representation, and Perl's single core now() routine they can use to determine 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 a "default calendar", which is the one that Perl uses when returning values from now(), etc. That is, Perl 6.0.0 should define the Instant and Duration roles as you outlined above, plus a set of classes that implement those roles according to the Gregorian calendar system. If you want to replace that with another calendar system in your implementation of Perl, the language already has the means of allowing you to do so (e.g., replacing &now with a variant that returns a different type of Instant). I am more on the fence in regards to default implementations of the roles. But I think that all the messy details of particular calendars, such as Gregorian leap seconds and timezones etc, should not be bundled with Perl, and be separate, where users can upgrade them separately independent of Perl as the measurements and political declarations come in. I still suggest just letting Perl itself be minimalist as far as providing classes go, just say have a class representing a Unix et al timestamp that directly corresponds to the implementation's time system, which differs per OS, plus a means for a program to ask what the current OS's calendar is, and then let separately distributed DateTime et al modules examine this and take care of all the mapping. For example, Perl 6 should include the analogy of Perl 5's "time" but not an analogy to "gmtime" or "localtime"; implementing the latter should be left exclusively to separate modules. This fits in with a Perl philosophy of mainly sticking to being grammar and letting CPAN/etc be the language, especially where complexity comes in. It also means that temporal modules can be bundled with Perl, but that is a choice made by the Perl packagers, not the Perl core, same as deciding what templating or networking or database or whatever modules to bundle.
Re: Proposal for a new Temporal time-measurement paradigm
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 (admittedly fringe) cases where someone might want a calendar that, even in principle, cannot be reconciled with anything else: consider someone who's writing an application that tracks events in a fantasy setting, such as the Lord of the Rings or the Wheel of Time. (Something like this actually occurred with a friend of mine, who's hobby is pen-and-paper roleplaying games; he wanted to build a database to track the events in his campaign, but ran into the problem that nothing allowed for the creation of a custom calendar such as the one in his fictional setting.) Yes, and in a middle ground between fiction and modern records that we are reasonably confident about are historical records. For example, "such-and-such happened during the wet season in the 14th year of so-and-so's reign". Often-times we don't know exactly when that was, or even if it was a true account, and so using a distinct reference calendar, say "so-and-so's reign" (actually further qualified), means we have a way of recording exactly what we know without degrading the information by forcing a conversion based on not well known information at the entry stage. And so, what we can do in general is simply have an Instant role and a Duration role, and pairs of types where each member composes one of those, and then all that needs to exist for temporal routines is an independent collection for each pair that is closed within that pair. This is what I was trying to say. And where you _can_ convert between calendars, you can always write a "type-casting" routine that takes, say, a Julian Instant as an input and produces a Gregorian Instant as the output. Yes, we seem to see eye-to-eye here. Incidently, it might be possible for two calendar systems to share the same Duration implementation; IIRC, the Julian and Gregorian calendars both use the same concept of seconds, minutes, hours, etc. Likewise, a calendar system might end up with more than one type of Duration: it's always possible to convert between seconds, minutes, hours, days, and weeks; and its also always possible to convert between months, years, decades, centuries, and millenia; but it isn't always so easy to convert between days and years. I could see the Gregorian implementation having two kinds of Durations: short Durations that deal with everything from seconds to weeks, and long Durations that deal with everything from months to millennia. Similarly, there would be a calendar for "I don't know what calendar", or varying degrees of such, which is often the case for dated historical records. With this, I'm not quite following you. Could you give an example of what you mean? There are several variants of this. See also my first reply paragraph about "the reign". For example, you could say that such-and-such happened "in Summer of 1406", and you want to record it that way because that's exactly what you know the record says, and having to change this to a specific Gregorian month or day would actually be losing information because you would be claiming more detail as being a recorded fact when it actually isn't; so if someone just records "in Summer ..." then someone looking at it can know better how sure we are or aren't about something. This isn't to say that we couldn't also record "July of 1406" as a separate related datum, but then the latter would be explicitly annotated as being a shoehorning guess to make some kinds of operations easier, but the other "Summer ..." is all that we actually know. Or, say we have a date saying "this was at 6:37am on March 1st of 1887"; however, we may not know if they are talking about the Julian or the Gregorian calendar, and so we can't just fix the date into one of those calendars; rather we have to fix it to "I believe it is either Julian or Gregorian but I don't know which", which is a distinct calendar. Ultimately a system for handling data should be accurate in clarifying what it does or doesn't know, and only claim exactly what it knows and no more. It needs to be able to distinguish knowing for a fact that something occurred at a specific hour and minute of a specific day on a specific calendar, with considering that information to be more of a guess that they aren't so sure about. Then, say if one wants to compile records and solve a problem, they can give greater weight regarding details to the records that claim to be more certain about what they are saying versus those that claim to be
Re: Proposal for a new Temporal time-measurement paradigm
Jon Lang wrote: Why do I find myself thinking of roles and classes here? IMHO, we should have a role that represents abstractly a moment in time. This role should, in and of itself, not be tied to any particular calendar; its purpose is so that one can write functions that make reference to instances in time without locking oneself into a particular labeling scheme. We should also have a series of classes that compose that role, each class representing a different calendar scheme. For perl 6.0.0, only one such class need be defined: the one representing the Gregorian calendar. Later on, modules can be written to provide additional classes representing other calendar schemes. Fine in theory; in practice, the big question is: how much can we get the role to do, within the "no calendar preference" constraint? And a corollary to this: can we get it to do enough to be worthwhile? 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. And so, what we can do in general is simply have an Instant role and a Duration role, and pairs of types where each member composes one of those, and then all that needs to exist for temporal routines is an independent collection for each pair that is closed within that pair. Each instant simply says, "I am this point on this particular timeline/calendar", and not try to imply that it is anything against any other calendar. For example, each instant is only a datetime in the Gregorian or Julian or Muslim or Jewish or TAI-1958 or TAI-1970s or whatever. This may result in a proliferation of calendars, but that can be blunted somewhat anywhere there are multiple measuring systems that are guaranteed to be commonly-defined. Similarly, there would be a calendar for "I don't know what calendar", or varying degrees of such, which is often the case for dated historical records. So all Perl 6 really needs to define is: 1. There is an Instant role and a Duration role. 2. A Duration is an amount of time that isn't fixed on a timeline; to get something fixed on a timeline, use a Range of Instant. 3. The system routine now()/etc returns a value of some Instant-composing class. 4. The Instant/Duration roles define functions like these: abs Duration -> Duration Duration + Duration -> Duration Duration - Duration -> Duration Duration abs_diff Duration -> Duration Duration * Numeric -> Duration Duration / Numeric -> Duration Instant - Instant -> Duration Instant abs_diff Instant -> Duration Instant + Duration -> Instant Instant - Duration -> Instant 5. There are absolutely no attributes defined by the Instant or Duration roles; attributes are defined entirely by the specific implementing classes, or other roles that they compose which compose Instant or Duration etc. There is no concept of years/days/etc in Instant or Duration. We might be counting time on Mars for example, so no Terra-centricity. So, basically like that. It keeps the core very simple and we avoid most of the bikeshedding seen so far. What calendars/timelines are supported can be implementation-defined and/or provided by modules. Each Perl 6 implementation can be minimalist as far as composing classes go; just provide some programmatically readable way to discover what calendar the system uses so then modules can use that to decide how to make a particular calendar work on any system as 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
Re: underscores vs hyphens (was Re: A new era for Temporal)
Doug McNutt wrote:
${A-1} = 3.14159;
$A = $A-1;
$A = $A -1;
$A-=2;
$A = 123E-2;
$A = Pi();
$B = sin ($A-1);
$B = sin (${A}-1);
$B = sin($A -1);
-2**2 = -4 except when it comes out +4 as in MS Excel.
_2**2 = +4 in some other languages that use _ as a unary minus operator.
Will editors be bothered when I try to include "-" in the list of characters
that are considered words when double clicking? When doing a find and replace all as
words?
Is the unicode equivalent of allowed in a variable name?
See http://perlcabal.org/syn/S02.html#Names for your answers.
Essentially, 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
Re: underscores vs hyphens (was Re: A new era for Temporal)
Damian Conway wrote: The relevant suggestion regarding hyphens vs underscores is: "...to allow both characters, but have them mean the same thing." That is, any isolated internal underscore can be replaced with an isolated internal hyphen (and vice versa), without changing the meaning of the identifier. I am formally opposed to this idea. I see that making underscores and hyphens to be equivalent is akin to having case-insensitive identifiers, where "Perl","PERL","perl" mean the same thing. Rather what I want is to be everything-sensitive, as AFAIK Perl 6 currently is; if something looks different, it is different. -- Darren Duncan
underscores vs hyphens (was Re: A new era for Temporal)
John Siracusa wrote: Forgive me if this is a question the reveals how poorly I've been following Perl 6 development, but what's the deal with some methods using hyphen-separated words (e.g., day-of-week) while others use "normal" Perl method names (e.g., set_second)? There are 2 answers to that question: 1. Unlike with Perl 5, Perl 6 supports the use of hyphens in bareword identifiers, except as the first character. In principle, I think this is very welcome, as hyphens are just as reasonable for separating words as underscores, and several other languages support this, and in XML at least it is standard practice. For that matter, Perl 6 also supports single-quotes in bareword identifiers, so you can have routines like isn't() or can't(); I don't like that so much as I prefer not to have characters used for quoted string delimiters in the middle of a bareword string, but I can understand why it was done. And so, if the language supports it and it is reasonable, why not use it? 2. I do think that any particular module should be internally consistent in its naming scheme, so Temporal should use all-underscores or all-hyphens, 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 language also has the feature of Perl 6 about supporting both underscore and hyphen separated bareword identifiers, though I don't support the single quotes. While users are free to use what style they want, for all the built-in stuff I have adopted the following convention: For all normal identifiers like the names of system-defined routines or variables or parameters or attributes etc, I use underscore separation. (Type names are typically camel-case like in Perl.) For language keywords or special operator syntaxes in the concrete language grammars, I use hyphen separators when said keywords have multiple words, rather than either underscores or whitespace. I find that this distinction is very effective at making different things look different, and for the keywords or special syntaxes, hyphens actually look better than either underscores or spaces.
Re: expression of seconds (was Re: A new era for Temporal)
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 single number which can do fractions, or if you really must break them up, then have the fractional second part as a real in 0..^1. The whole "nanosecond"-integer-fixed-onesizefitsall-subsecond-precision thing is a terrible hack. Keeping a single number for seconds is best from a conceptual and a usability and a math point of view. If users only want the integer value, then they can just store the second as an integer in the first place. As for the name, well "whole_second" can be made shorter, or its value could automatically truncate if users assigned it to an Int. my Int $x implies a constraint, *not* a coercion. That's: $dt.seconds.Int Though even clearer and same number of characters as whole_seconds is: $dt.seconds.round Jonathan Yes, exactly, thank you Jonathan. -- Darren Duncan
expression of seconds (was Re: A new era for Temporal)
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 single number which can do fractions, or if you really must break them up, then have the fractional second part as a real in 0..^1. The whole "nanosecond"-integer-fixed-onesizefitsall-subsecond-precision thing is a terrible hack. Keeping a single number for seconds is best from a conceptual and a usability and a math point of view. If users only want the integer value, then they can just store the second as an integer in the first place. As for the name, well "whole_second" can be made shorter, or its value could automatically truncate if users assigned it to an Int. Even Larry said that using reals for seconds 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
Re: You never have privacy from your children in Perl 6
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 an incomplete implementation of ADTs. No, it's simply a reflection that the one-to-one relationship between the attributes of a single storage object is too simplistic to use as the *only* encapsulation boundary. Of course, that points towards having access limits that depend not just on the type, but on the specific object: in Darren's example, nodes should be able to see the details of the edges and faces they're attached to, but probably not any other edges or faces. And definitely not the edges or faces in some completely disconnected mesh or network. I agree. And in my experience actually implementing said graph thingy, one of the things I regularly had to test is whether an object I was given as an argument is in the same network as another one, and the easiest way to do that is to test if both have the same container object. FYI, that graph implementation was the now-deprecated http://search.cpan.org/~duncand/Rosetta-v0.71.0/lib/Rosetta/Model.pm (aka SQL::Routine), last substantially updated in mid-2005. This url is a Perl 5 version, but I had also ported it to Perl 6 in the first few months of Pugs' existence to help test Pugs, though it was soon after wiped from Pugs' repo, as they added the policy that most ext/ things should actually be distributed separately from Pugs, or there was some reason. -- Darren Duncan A connected mesh or network is a reasonable ADT, but to implement it you're going to want several classes. The mesh-object-as-a-whole is the appropriate encapsulation boundary. If we had a really sophisticated ADT that could represent a "Network", that would indeed solve the encapsulation problem. So what tools are we going to need to build such an ADT? Well, privacy, trust, ... -Martin
Re: Ordering in \bbold{C}
Leon Timmermans wrote: Maybe it's just me, but I don't see the value of having some *arbitrary* predefined order for complex numbers. If people really want to order their complex numbers, let them do it themselves in whatever way they want. Leon I agree actually that Complex shouldn't have a predefined order. I just raised my algorithm since someone else raised another one. -- Darren Duncan
