Dear Brad,
Thank you so much for taking the time to reply!
I wrote a few notes inline, below:
On Sat, Oct 10, 2020 at 4:07 PM Brad Gilbert wrote:
>
> Functions in Raku tend to have one job and one job only.
>
> `split` splits a string.
>
> So if you call `split` on something that is not a string
Oh, thanks, now it makes sense.
On Wed, Oct 14, 2020 at 12:01 PM Brian Duggan wrote:
> On Wednesday, October 14, Aureliano Guedes wrote:
> > In this point, the unique weirdness I'd like to understand is why in Raku
> > `@nums.log == 2.302585092994046e0`. I don't understand where this value
> > c
On Wednesday, October 14, Aureliano Guedes wrote:
> In this point, the unique weirdness I'd like to understand is why in Raku
> `@nums.log == 2.302585092994046e0`. I don't understand where this value
> comes from.
This comes from the length of the array; the array is coerced into a numeric
value:
I'd like to help with my 2 cents.
Given your comparison with R, sum, and mean are expected to play with a
vector rather than log and sin are expected to play with single numbers.
Then, the expected behavior for numerics types in Raku still the same as in
R. The difference is only that the function
On Mon, Oct 12, 2020 at 10:02 AM Larry Wall wrote:
>
> On Mon, Oct 12, 2020 at 01:14:09PM -0300, Aureliano Guedes wrote:
> : > This seems pretty convenient and intuitive. At least, it is possible
> : > to mimic that behavior in Raku:
> : >
> : > List.^find_method('split').wrap: { $^a.map:
Here's another way of phrasing these answers-
Some routines like "join" operate on strings, and thus coerce their
argument to a string.
Some routines like "sin" operate on numbers, and thus coerce their argument
to a number.
Each class defines how it coerces to Str or Num, regardless of what is
On Sat, Oct 10, 2020 at 4:49 PM Tobias Boege wrote:
> On Sun, 11 Oct 2020, Tobias Boege wrote:
> > On Sat, 10 Oct 2020, William Michels via perl6-users wrote:
> > > then proceed to process the function call. As it is my understanding
> that
> > > Raku incorporates a lot of different programming p
Thank you Timo for the favor of a reply!
On Sat, Oct 10, 2020 at 3:35 PM Timo Paulssen wrote:
> On 10/10/2020 23:21, William Michels via perl6-users wrote:
> > So I guess the first question I have is whether the 'auto-joining' of
> > array elements is specc'ed or not.
> >
> > What you seem to be
On Mon, Oct 12, 2020 at 6:02 AM Brian Duggan wrote:
> On Saturday, October 10, William Michels via perl6-users wrote:
> > I can point to the (functional) R-programming language to show what
> happens
> > there. When manipulating "array-like" (i.e. vector) objects in R, you can
> > do nested funct
Thank you, Joe, for taking the time to write such a cogent reply. And
thanks to Tobias and everyone else who has taken the time to reply to my
questions.
On Sat, Oct 10, 2020 at 3:38 PM Joseph Brenner wrote:
> William Michels wrote:
>
> >I actually wondered where the different programming paradi
On Mon, Oct 12, 2020 at 01:14:09PM -0300, Aureliano Guedes wrote:
: > This seems pretty convenient and intuitive. At least, it is possible
: > to mimic that behavior in Raku:
: >
: > List.^find_method('split').wrap: { $^a.map: *.split($^b) }
: > List.^find_method('sin').wrap: *.map
These behave like overwriting
> List.^find_method('split').wrap: { $^a.map: *.split($^b) }
> List.^find_method('sin').wrap: *.map: *.sin;
>
but they don't have to, since Aureliano started with "wrap" they can be
actual wrappers:
sub map-over-arg(\A) {my &nextone=nextcallee; A.map:{nextone $_}}
L
On Mon, Oct 12, 2020 at 10:03 AM Brian Duggan wrote:
> On Saturday, October 10, William Michels via perl6-users wrote:
> > I can point to the (functional) R-programming language to show what
> happens
> > there. When manipulating "array-like" (i.e. vector) objects in R, you can
> > do nested func
On Saturday, October 10, William Michels via perl6-users wrote:
> I can point to the (functional) R-programming language to show what happens
> there. When manipulating "array-like" (i.e. vector) objects in R, you can
> do nested function calls, or sequential (piped) function calls, and still
> ge
On Sun, 11 Oct 2020, Tobias Boege wrote:
> On Sat, 10 Oct 2020, William Michels via perl6-users wrote:
> > then proceed to process the function call. As it is my understanding that
> > Raku incorporates a lot of different programming paradigms (imperative,
> > object-oriented, functional, etc.), I'
On Sat, 10 Oct 2020, William Michels via perl6-users wrote:
> So I guess the first question I have is whether the 'auto-joining' of array
> elements is specc'ed or not.
>
I did not find anything that explicitly requires @array.split() to force
@array into a string, but there are tests in S02-type
Functions in Raku tend to have one job and one job only.
`split` splits a string.
So if you call `split` on something that is not a string it gets turned
into one if it can.
This happens for most functions.
Having `split` be the only function that auto-vectorizes against an array
would be very
William Michels wrote:
>I actually wondered where the different programming paradigms
>would be delineated
I think were the present topic has to do more with the
strong/weak/gradual typing debates-- here Raku is doing an
automatic type conversion that a "strong-typing" fanatic
would sneer at. Th
On 10/10/2020 23:21, William Michels via perl6-users wrote:
> So I guess the first question I have is whether the 'auto-joining' of
> array elements is specc'ed or not.
>
> What you seem to be saying is that when calling a function on an
> array, the first response is for Raku to call something sim
So I guess the first question I have is whether the 'auto-joining' of array
elements is specc'ed or not.
What you seem to be saying is that when calling a function on an array, the
first response is for Raku to call something similar to 'cat' on the array,
then proceed to process the function call
On Tue, 06 Oct 2020, William Michels via perl6-users wrote:
> [...]
>
> So my question regards "special-casing" of split/join in Raku. Is the first
> result on comma-delimited data the default, i.e. joining disparate elements
> of an array together head-to-tail? Or is the second result on
> whitesp
Hello All,
I'm trying to understand Raku's split/join rules. Below is REPL code and
output.
I start by studying a 2-element Array in line A (three letters separated by
commas in each element, 6 letters total). In line B, I perform a split/join
and end up with a 1 element result. Since I started w
On Tue, Jul 14, 2015 at 12:04 AM, Michael Zedeler
wrote:
>
> So far, almost every other language has behaved this way, and it has
> worked. I can see that Rats do solve a problem, but if you'd claim that it
> is very severe then I'd disagree. This is a minor nuisance that I'd only
> pay a small pr
Darren Duncan wrote
> 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
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 like the explanation of how Rats solve a class of rounding errors,
0.3 - (0.2 + 0.1) equals exactly 0 for example. On the other hand,
it's still a compromise that's shifting closer to correctness, fixing
a bunch of potential bugs, but not all in that class:
Rakudo:
> say 2 - (sqrt 2) ** 2
-4.440
On Tue, Jun 16, 2015 at 10:02 PM, Michael Zedeler
wrote:
> I'm not saying that there isn't any alternative to the way other languages
> implements floats, but Rats in particular seems to require a
> nondeterministic algorithm in order to be of practical use.
>
Rats means never having to worry a
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?
Eirik
Yes, unpredictable performance is a price I'm willing to pay. I'm using a
dynamic language after all.
If you aren't willing to pay it, just use typed variables. Or even native
types, like num or int. Choose your own number representation -- there's
more than one way to do it.
The design philos
...and unpredictable performance is a cost you're willing to pay?
M.
The Sidhekin wrote
>On Tue, Jun 16, 2015 at 10:02 PM, Michael Zedeler wrote:
>
>I'm not saying that there isn't any alternative to the way other languages
>implements floats, but Rats in particular seems to require
I really understand your point. If there was several competing OOP modules,
things *could* get really complicated (in my opinion, it isn't the case for
perl 5, but it is worth discussing), but it doesn't seem as if anyone has put
any effort into defining what needs to be common and what doesn't.
Yes. It looks nice that Perl 6 recognizes zero in this way, but the consequence
is that each implementation of Perl 6 has to run a gcd algorithm every now and
then.
I'd be very surprised if the computational complexity of any useful (even
approximate) gcd algorithm doesn't scale with the with
The goal is to avoid everyone using a different not fully compatible
version of everything. Like in perl 5 with the bunch of different ways to
do objects, signatures etc.
Pilling good things on top of each others rather than aiming for an elegant
design is what I consider the core idea of Perl.
Bei
I like that I can start with a fairly simple subset of Perl 6 but pick up more
as I go along, if it’s needed.
chris
On Jun 16, 2015, at 9:45 AM, Paweł Murias
mailto:pawelmur...@gmail.com>> wrote:
I think Perl 6 tries to include too much rather than too little.
It will be possible to just use a
* Michael Zedeler [2015-06-16 18:55]:
> For instance, why have Complex and Rat numbers in the core? If you're
> not working in a very specialized field (which probably *isn't*
> numerical computation), those datatypes are just esoteric constructs
> that you'll never use.
https://www.youtube.com/w
This is another of my points: when presented with all the features in Perl 6 -
what is then essential?
The essential features - besides being presented up front and center to newbies
- are also good candidates for what should go into the core.
For instance, why have Complex and Rat numbers in t
Subsets will be absolutely essential, if it is to be possible to learn
it with a reasonable amount of time and effort.
On 6/16/15, Paweł Murias wrote:
> I think Perl 6 tries to include too much rather than too little.
> It will be possible to just use a subset
>
> On 16 June 2015 at 10:32, Michae
I think Perl 6 tries to include too much rather than too little.
It will be possible to just use a subset
On 16 June 2015 at 10:32, Michael Zedeler wrote:
> On 06/12/15 15:54, Parrot Raiser wrote:
>
>> Has somebody been following the discussions on types?
>> http://xkcd.org/1537/ :-)*
>>
> Perl6
On 06/12/15 15:54, Parrot Raiser wrote:
Has somebody been following the discussions on types? http://xkcd.org/1537/ :-)*
Perl6 has something similar to example 9.
Ranges, hyper-operators as well as the "invocation" operators .+ and .*
doesn't make any sense to me. Those constructs made me stop
On Jun 12, 2015, at 8:54 AM, Parrot Raiser <1parr...@gmail.com> wrote:
> Has somebody been following the discussions on types? http://xkcd.org/1537/
> :-)*
Yes; see the 4 minute lightning talk:
https://www.destroyallsoftware.com/talks/wat
:^)
—
Bruce Gray (Util of PerlMonks)
Has somebody been following the discussions on types? http://xkcd.org/1537/ :-)*
ss some
> imaginary line and have syntactical gridlock where the language design
> descends into a morass of continual minor adjustment. By backing off
> we can often find a much more sweeping solution than just putting up
> lights on every corner. A perfect example is Larry&
ersection to maximize throughput leads to gridlock, zero
> throughput. The exact opposite of what was intended.
>
> We are in danger of doing just that. By wanting to correct,
> streamline and optimize every bump and snag in Perl we may cross some
> imaginary line and have syn
e off traffic. Constant
fiddling with the setups and timings, trying to control each and every
intersection to maximize throughput leads to gridlock, zero
throughput. The exact opposite of what was intended.
We are in danger of doing just that. By wanting to correct,
streamline and optimize every bu
44 matches
Mail list logo
