6 ms·

You might be a little confused, I'm pretty sure that wantarray and the concept of functions caring about context is entirely gone in Perl 6. Now you are expecte

You might be a little confused, I'm pretty sure that wantarray and the concept of functions caring about context is entirely gone in Perl 6. Now you are expected to return objects which 'do the right thing'. However, if you really want to do some of the other things you've listed they are possible to do. Perl 6's syntax can be augmented by the programs being executed. I'm honestly interested though, was I ultimately wrong above? Is there a smart way to define a function in python that can take both a single item and a list of items? In Perl 6 I'd just define a multi sub where the list form applies the single item sub for each item in the list.

DonHopkins 11y ago
It might be gone from Perl 6, but the idea of dividing all possible types into two different classes, and then using punctuation to distinguish variables holding those two classes, is from Perl 5, just like the idea of functions caring about the context of their return value. If Perl 6 is an entirely new language, then why is it riddled with so many bad ideas from another language that only coincidentally shares the first 4 alphabetic characters of its name? Why the artificial scalar/array dichotomy? What is it that is so important about being able to distinguish variables holding scalar-like values and array-like values by punctuation, but it doesn't matter that you can't distinguish variables holding strings and integers by their punctuation? And how can you be consistent about types that act like both scalars and arrays, like strings? Or user defined types that might behave like scalars or arrays but are represented by objects? Are those treated as arrays? Or are they references, treated as scalars? Scalar -vs- array is a false dichotomy that's deeply and unnecessarily embedded in the very syntax of the language.
- hahainternet 11y ago
  I'm not entirely sure you've illustrated that it's a bad idea. I believe that I illustrated that a simple pattern is not easily doable in Python but is in Perl 6. You'll have to show that this is a bad pattern or the implementation is bad or something at least to prove your point. There's more to sigils than just scalars and arrays too, as you can see here: http://doc.perl6.org/language/variables#Sigils http://doc.perl6.org/language/variables#Sigils The difference in your examples are that scalars describe more the 'shape' of the variable than its type. Given that a lot of programming is dealing with lists or 'dictionaries' this is a fairly minimal intrusion into the code that very much improves succinctness, correctness and the ability to easily read what some code is doing. Oh, and strings don't act like arrays in Perl 6 AFAIK. Because they could be split on characters, or codepoints, or bytes, you must be explicit: > for "Hello".comb -> $c { say "Character $c" } Character H Character e Character l Character l Character o (Or to be perly) > .say for "Hello".comb
  - DonHopkins 11y ago
    What's wrong with using "isinstance(lst, str)" when necessary? The few cases when you need to make that distinction aren't worth infecting the rest of the code with punctuation marks. Using letters to explicitly spell out self-documenting words in the few function names that need to make that distinction is much less intrusive, more flexible, unambiguous and capable of precisely distinguishing many more nuances, than using a small set of punctuation characters throughout all of your code to mitigate rare problems with just a few cases. Of course it can be taken to an extreme, but it's much easier to guess or google for the meaning of an Objective C selector than for a bunch of Perl punctuation. http://stackoverflow.com/questions/15152171/what-is-the-longest-method-name-you-have-seen-in-ios-cocoa-touch http://stackoverflow.com/questions/15152171/what-is-the-long...
    - hahainternet 11y ago
      > What's wrong with using "isinstance(lst, str)" when necessary? In order for it to be like the Perl6 implementation I would have to check against every type of iterable AFAIK. For example, a generator would be perfectly acceptable, but is there a unique function I could check with hasattr? Clearly you feel that sigils are intrusive in Perl 6, but having written a bunch I find it quite enjoyable, and they're pretty easy to find in the documentation too. Ultimately, you can use variables without sigils, but with caveats: http://doc.perl6.org/language/variables#Sigilless_variables http://doc.perl6.org/language/variables#Sigilless_variables
      - lmm 11y ago
        > In order for it to be like the Perl6 implementation I would have to check against every type of iterable AFAIK. For example, a generator would be perfectly acceptable, but is there a unique function I could check with hasattr? Define what it is you want - which function you want to use - and then check that (e.g. if you want to iterate over it check for __iter__; if you want to want to test membership check for __contains__). In one part of the code a generator might be acceptable; in another it might not. Which is the point really - array vs scalar seems like a simple, sensible, widely usable distinction on first glance, but it turns out the meaning you actually want is very context-dependent, and a global distinction is a lot less useful than it appears.
- raiph 11y ago
  > the idea of dividing all possible types There is no such division of types in Perl 6 in the normal CS sense of the word "types". There are several kinds (in the English sense, not CS sense) of data containers. Elements of these containers can be of any type (CS meaning). > just like the idea of functions caring about the context of their return value. As the GP just said, Perl 6 dropped that. > Why the artificial scalar/array dichotomy? The distinction between singular and plural is natural, wired in to our brains, not artificial. > What is it that is so important about being able to distinguish variables holding scalar-like values and array-like values by punctuation, but it doesn't matter that you can't distinguish variables holding strings and integers by their punctuation? As explained above, it's not about the values but the containers. Strings and integers are data. Containers are not data. > And how can you be consistent about types that act like both scalars and arrays, like strings? Perl treats strings as values.
  - DonHopkins 11y ago
    Strings and integers are data, but containers are "magic". Right. The propensity for fuzzy magical thinking is wired into our brains, not artificial. But that doesn't mean it's a good way to design a programming language. Containers can certainly be data. A string is a container of characters, and we're certainly interested in its value as data. A window is a container of sub-windows. In many systems, windows inherit from and/or behave like containers, so you can loop over them and manipulate them just like containers. So should the window.Add(subWindow) method automatically loop over the subSubWindows of subWindow and add each of them as direct children of window, or should it simply add subWindow to window directly so its subSubWindows are grandchildren of window? I was referring to Perl's scalar/array distinction as being artificial and fuzzy -- I wasn't claiming the singular/plural concepts in your brain weren't natural. They're vastly different things. It's fuzzy magical thinking to believe that Perl's dichotomy of scalar/array maps directly to your brain's concept of singular/plural. Does everyone's brain's built-in concept of plurality naturally support nested polymorphic arrays? Do those arrays in people's brains also behave like keyed hash tables, like Perl and JavaScript arrays? Must the keys be strings, or might they be any hashable idea? What does it mean for an idea to be hashable? Do Perl references work exactly the same way as actual human neurons? What about dolphin brains? Please show me some peer reviewed scientific studies that prove Perl arrays accurately model natural language and mirror human thought, and then I will concede that Perl is more linguistically or biologically "natural" than Python. But until I see some proof to the contrary, I believe that Larry Wall is to linguistics as Deepak Chakra is to physics: "While in graduate school at the University of California, Berkeley, Wall and his wife were studying linguistics with the intention of finding an unwritten language, perhaps in Africa, and creating a writing system for it. They would then use this new writing system to translate various texts into the language, among them the Bible. Due to health reasons these plans were cancelled, and they remained in the United States, where Larry instead joined the NASA Jet Propulsion Laboratory after he finished graduate school." https://en.wikipedia.org/wiki/Larry_Wall https://en.wikipedia.org/wiki/Larry_Wall

DonHopkins 11y ago

It might be gone from Perl 6, but the idea of dividing all possible types into two different classes, and then using punctuation to distinguish variables holding those two classes, is from Perl 5, just like the idea of functions caring about the context of their return value. If Perl 6 is an entirely new language, then why is it riddled with so many bad ideas from another language that only coincidentally shares the first 4 alphabetic characters of its name? Why the artificial scalar/array dichotomy? What is it that is so important about being able to distinguish variables holding scalar-like values and array-like values by punctuation, but it doesn't matter that you can't distinguish variables holding strings and integers by their punctuation? And how can you be consistent about types that act like both scalars and arrays, like strings? Or user defined types that might behave like scalars or arrays but are represented by objects? Are those treated as arrays? Or are they references, treated as scalars? Scalar -vs- array is a false dichotomy that's deeply and unnecessarily embedded in the very syntax of the language.

hahainternet 11y ago
I'm not entirely sure you've illustrated that it's a bad idea. I believe that I illustrated that a simple pattern is not easily doable in Python but is in Perl 6. You'll have to show that this is a bad pattern or the implementation is bad or something at least to prove your point. There's more to sigils than just scalars and arrays too, as you can see here: http://doc.perl6.org/language/variables#Sigils http://doc.perl6.org/language/variables#Sigils The difference in your examples are that scalars describe more the 'shape' of the variable than its type. Given that a lot of programming is dealing with lists or 'dictionaries' this is a fairly minimal intrusion into the code that very much improves succinctness, correctness and the ability to easily read what some code is doing. Oh, and strings don't act like arrays in Perl 6 AFAIK. Because they could be split on characters, or codepoints, or bytes, you must be explicit: > for "Hello".comb -> $c { say "Character $c" } Character H Character e Character l Character l Character o (Or to be perly) > .say for "Hello".comb
- DonHopkins 11y ago
  What's wrong with using "isinstance(lst, str)" when necessary? The few cases when you need to make that distinction aren't worth infecting the rest of the code with punctuation marks. Using letters to explicitly spell out self-documenting words in the few function names that need to make that distinction is much less intrusive, more flexible, unambiguous and capable of precisely distinguishing many more nuances, than using a small set of punctuation characters throughout all of your code to mitigate rare problems with just a few cases. Of course it can be taken to an extreme, but it's much easier to guess or google for the meaning of an Objective C selector than for a bunch of Perl punctuation. http://stackoverflow.com/questions/15152171/what-is-the-longest-method-name-you-have-seen-in-ios-cocoa-touch http://stackoverflow.com/questions/15152171/what-is-the-long...
  - hahainternet 11y ago
    > What's wrong with using "isinstance(lst, str)" when necessary? In order for it to be like the Perl6 implementation I would have to check against every type of iterable AFAIK. For example, a generator would be perfectly acceptable, but is there a unique function I could check with hasattr? Clearly you feel that sigils are intrusive in Perl 6, but having written a bunch I find it quite enjoyable, and they're pretty easy to find in the documentation too. Ultimately, you can use variables without sigils, but with caveats: http://doc.perl6.org/language/variables#Sigilless_variables http://doc.perl6.org/language/variables#Sigilless_variables
    - lmm 11y ago
      > In order for it to be like the Perl6 implementation I would have to check against every type of iterable AFAIK. For example, a generator would be perfectly acceptable, but is there a unique function I could check with hasattr? Define what it is you want - which function you want to use - and then check that (e.g. if you want to iterate over it check for __iter__; if you want to want to test membership check for __contains__). In one part of the code a generator might be acceptable; in another it might not. Which is the point really - array vs scalar seems like a simple, sensible, widely usable distinction on first glance, but it turns out the meaning you actually want is very context-dependent, and a global distinction is a lot less useful than it appears.
raiph 11y ago
> the idea of dividing all possible types There is no such division of types in Perl 6 in the normal CS sense of the word "types". There are several kinds (in the English sense, not CS sense) of data containers. Elements of these containers can be of any type (CS meaning). > just like the idea of functions caring about the context of their return value. As the GP just said, Perl 6 dropped that. > Why the artificial scalar/array dichotomy? The distinction between singular and plural is natural, wired in to our brains, not artificial. > What is it that is so important about being able to distinguish variables holding scalar-like values and array-like values by punctuation, but it doesn't matter that you can't distinguish variables holding strings and integers by their punctuation? As explained above, it's not about the values but the containers. Strings and integers are data. Containers are not data. > And how can you be consistent about types that act like both scalars and arrays, like strings? Perl treats strings as values.
- DonHopkins 11y ago
  Strings and integers are data, but containers are "magic". Right. The propensity for fuzzy magical thinking is wired into our brains, not artificial. But that doesn't mean it's a good way to design a programming language. Containers can certainly be data. A string is a container of characters, and we're certainly interested in its value as data. A window is a container of sub-windows. In many systems, windows inherit from and/or behave like containers, so you can loop over them and manipulate them just like containers. So should the window.Add(subWindow) method automatically loop over the subSubWindows of subWindow and add each of them as direct children of window, or should it simply add subWindow to window directly so its subSubWindows are grandchildren of window? I was referring to Perl's scalar/array distinction as being artificial and fuzzy -- I wasn't claiming the singular/plural concepts in your brain weren't natural. They're vastly different things. It's fuzzy magical thinking to believe that Perl's dichotomy of scalar/array maps directly to your brain's concept of singular/plural. Does everyone's brain's built-in concept of plurality naturally support nested polymorphic arrays? Do those arrays in people's brains also behave like keyed hash tables, like Perl and JavaScript arrays? Must the keys be strings, or might they be any hashable idea? What does it mean for an idea to be hashable? Do Perl references work exactly the same way as actual human neurons? What about dolphin brains? Please show me some peer reviewed scientific studies that prove Perl arrays accurately model natural language and mirror human thought, and then I will concede that Perl is more linguistically or biologically "natural" than Python. But until I see some proof to the contrary, I believe that Larry Wall is to linguistics as Deepak Chakra is to physics: "While in graduate school at the University of California, Berkeley, Wall and his wife were studying linguistics with the intention of finding an unwritten language, perhaps in Africa, and creating a writing system for it. They would then use this new writing system to translate various texts into the language, among them the Bible. Due to health reasons these plans were cancelled, and they remained in the United States, where Larry instead joined the NASA Jet Propulsion Laboratory after he finished graduate school." https://en.wikipedia.org/wiki/Larry_Wall https://en.wikipedia.org/wiki/Larry_Wall