Hacker News new | past | comments | ask | show | jobs | submit login

Lists that cannot contain other lists are not reasonable in a high level language.

Perl has supported arrays of arrays since 1994.

Pointers are not reasonable in a high level language.

Perl has never supported pointers.

Explicit function signatures are a superior language design.

I agree with this. Perl 5 should have had them years ago.




If you put a list in a list in Perl, don't you have to specifically dereference the sublist when accessing it? Otherwise you get what looks to my eye like a pointer (a weird random number). The first google result I get is this: http://www.webreference.com/programming/perl/nested/ -- and to me "reference" == "pointer". And the fact that it is all weakly typed (that is, pointers are not a distinct type) makes it that much worse.


If you put a list in a list in Perl, don't you have to specifically dereference the sublist when accessing it?

You mean "array" instead of "list", but yes. Are there languages which don't require some special syntax for accessing nested data structures?

Otherwise you get what looks to my eye like a pointer (a weird random number).

When you stringify a reference, you get either the default stringification or an overloaded stringification, if you've overloaded stringification for a particular class. When you numify a reference, you get a unique number. Think of it as a cheap object identifier, because that's effectively what it is. It's not a great interface to expose to users, but that's its intent.

I argue that it's not a pointer, because you can't do pointer arithmetic with it.

...pointers are not a distinct type...

You mean "reference", and indeed they are distinct. They're RVs. That's a scalar type (SV).


Are there languages which don't require some special syntax for accessing nested data structures?

Isn't that true for... most languages? Python, Ruby, Java, PHP, Smalltalk. And any language created in modern times. Perl in this respect is like a transitional animal in the evolution of languages -- what seemed somewhat modern given its peers (like shell or Tcl) now seems horribly outdated, the programming language world moved on having considered nested data structures a solved problem. It's like goto or dynamically scoped variables in other eras.


How to make an array of arrays in Perl 5:

    @aoa = ( [ 1, 2, 3 ], [ 4, 5, 6 ] );
How to make a list of lists in Python:

    lol = [ [ 1, 2, 3 ], [ 4, 5, 6 ] ]
How to access the second element of the second array in Perl 5:

    $aoa[1][1];
How to access the second element of the second list in Python:

    lol[1][1]
The difference seems to be nomenclature and Perl's use of sigils. Where's the "horribly outdated" design?


You've selected one option where Perl looks sane, while leaving out cases like "[ [1, 2, 3], [4, 5, 6] ]" or "( (1, 2, 3), (4, 5, 6) )". And of course there's other cases like lists containing hashes, and hashes containing lists. All of these are handled consistently in languages like Python and Ruby, and the programmer never needs to consider the interaction of the container and the objects it contains -- numbers and lists and strings and hashes are all objects and all act exactly the same with respect to containers.


I'm not going to defend Perl 5's dereferencing syntax for container operations. Perl 6 changed that for a very good reason.

I could give you examples of Ruby's and Python's inconsistency in their use of parentheses, as sometimes they group expressions to influence parsing precedence and sometimes they denote first-class data structures, but as you persist in asserting that parentheses create lists in Perl and that lists are first-class data structures, I suspect this discussion will continue to go nowhere.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: