Re: Files, Directories, Resources, Operating Systems
* Aristotle Pagaltzis ([EMAIL PROTECTED]) [081204 16:57]: * Mark Overmeer [EMAIL PROTECTED] [2008-12-04 16:50]: * Aristotle Pagaltzis ([EMAIL PROTECTED]) [081204 14:38]: Furthermore, from the point of view of the OS, even treating file names as opaque binary blobs is actually fine! Programs don’t care after all. In fact, no problem shows up until the point where you try to show filenames to a user; that is when the headaches start, not any sooner. So, they start when - you have users pick filenames (with Tk) for a graphical applications. You have to know the right codeset to be able to display them correctly. Yes, but you can afford imperfection because presumably you know which displayed filename corresponds to which stored octet sequence, so even if the name displays incorrectly, you still operate on the right file if the user picks it. With all these different encodings, it is easy to show filenames which are not a little-bit incorrect, but which are unrecognizably corrupted. In the whole debate, it look like there are only two groups of developers involved: the programming language authors and the end-application developers. But do not forget that there are also CPAN library authors and maintainers (my main involvement) When you create a good library, you have to support multiple (unpredicatable) platformas and languages. Each time you say: oh, just let the end-user figure that out, you add complexity and distribute implementation horrors. Good, generally available libraries are crucial for any language. - you have XML-files with meta-data on files which are being distributed. (I have a lot of those) Use URI encoding unless you like a world of pain. You are looking at it from the wrong point of view: Perl is used as a glue language: other people determine what kind of data we have to process. So, also in my case, the content of these XML structures is totally out of my hands: no influence on the definitions at all. I think that is the more common situation. NTFS seems to say it’s all Unicode and comes back as either CP1252 or UTF-16 depending on which API you use, so I guess you could auto-decode those. But FAT is codepage-dependent, and I don’t know if Windows has a good way of distinguishing when you are getting what. So Windows seems marginally more consistent than Unix, but possibly only apparently. (What happens if you zip a file with random binary garbage for a name on Unix and then unzip it on Windows?) I have no idea what other systems do. Well, the nice thing about File::Spec/Class::Path is that someone did know how those systems work and everyone can benefit from it. So why are you all so hessitating in making each other's life easier? There is no 100% solution, but 0% is even worse! Once upon a time, Perl people where eager for good DWIMming and powerful programming. Nowadays, I see so much fear in our community to attempt simpler/better/other ways of programming. We get a brand new language, with a horribly outdated documentation system and very traditional OS approach. As if everyone prefers to stick to Perl's 22 years and Unixes 39 years old choices, where the world around us saw huge development and change in needs. Are we just getting old, grumpy and tired? Where is the new blood to stir us up? - MarkOv Mark Overmeer MScMARKOV Solutions [EMAIL PROTECTED] [EMAIL PROTECTED] http://Mark.Overmeer.net http://solutions.overmeer.net
Re: Files, Directories, Resources, Operating Systems
* Mark Overmeer [EMAIL PROTECTED] [2008-12-07 14:20]: - you have XML-files with meta-data on files which are being distributed. (I have a lot of those) Use URI encoding unless you like a world of pain. You are looking at it from the wrong point of view: Perl is used as a glue language: other people determine what kind of data we have to process. So, also in my case, the content of these XML structures is totally out of my hands: no influence on the definitions at all. I think that is the more common situation. If you start with a broken data format, no amount of papering over it will unbreak it. Sorry, Perl 6 won’t have magic ponies to fix that. Ambiguous data cannot be disambiguated by smart code. If you want to try anyway, talk to someone who didn’t get their name on an IETF RFC out of disgust with the state of an unfixably messy legacy data format. NTFS seems to say it’s all Unicode and comes back as either CP1252 or UTF-16 depending on which API you use, so I guess you could auto-decode those. But FAT is codepage-dependent, and I don’t know if Windows has a good way of distinguishing when you are getting what. So Windows seems marginally more consistent than Unix, but possibly only apparently. (What happens if you zip a file with random binary garbage for a name on Unix and then unzip it on Windows?) I have no idea what other systems do. Well, the nice thing about File::Spec/Class::Path is that someone did know how those systems work and everyone can benefit from it. These modules are completely and utterly oblivious to encoding issues, so I have no idea how they are relevant in the first place. So why are you all so hessitating in making each other's life easier? There is no 100% solution, but 0% is even worse! Because I have seen Java, and it taught me that the 90% solution is worse than the 20% solution. Provide 20% in the language and someone will use that and write Path::Class. And if we abstain from putting today’s best solutions in the core library, then we have a chance that tomorrow’s best solutions might gain traction. (Otherwise we get 10 years of CGI.pm again.) Once upon a time, Perl people where eager for good DWIMming and powerful programming. And yet it’s the CPAN that turned out to be Perl’s greatest strength. If you suggested the initial concept of the CPAN today, people would laugh at you – it would seem like an April fool’s joke. It didn’t even have a standard package format! Nowadays, I see so much fear in our community to attempt simpler/better/other ways of programming. Simpler in what way? All abstractions leak. Take this into account or make users suffer. We get a brand new language, with a horribly outdated documentation system and very traditional OS approach. As if everyone prefers to stick to Perl's 22 years and Unixes 39 years old choices, where the world around us saw huge development and change in needs. If you can show me a ubiquitous kernel that runs perl and was designed less than 15 years ago, I’ll show you a modern OS API approach. If you want to see an attempt at an abstract interface layered over crusty OS designs, I’ll show you Java. Abstaining from the attractive nuisance of abstracting small- seeming differences away seems to have worked out well enough for DBI, anyway. Would you argue that DBI is not a good or relevant example? (And if so, why?) Or are you suggesting that approach was a failure or horrible in some way? Are we just getting old, grumpy and tired? Where is the new blood to stir us up? Busy designing their own second system. You want to invite a bunch of PHP kids? I’m game. :-) Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: how to write literals of some Perl 6 types?
Dave Whipp wrote: Carl Mäsak wrote: Paul (): I can't find anything in the existing synopses about Blobs. Probably looking in the wrong place, sorry. http://perlcabal.org/syn/S02.html#line_912 Re-reading that, a slightly tangent (though still on topic, I hope) thought come to mind. The definition of the Mapping immutable type: Mapping Set of Pairs with no duplicate keys The question is, what to do when a Mapping is created from a source that contains pairs with duplicate keys? The Perl5 answer is simply to silently drop all but the last in the list ... but I can think of many other answers: sometimes you might want an error; other times you might want to create a list/set/bag from the values of the duplicate keys; other times a junction might be appropriate. One theme of P6 is to not lose information unnecessarily -- which is what P5 does here. It would be nice indeed if there were a simple syntax for specifying that. OTOH it's not hard to do it manually in two lines or so. The option of creating a list of the values is interesting because, in scalar context, a list returns the value of its last item That's Perl 5 semantics, not Perl 6. In Perl 6 a List in scalar context becomes a List or Array object: $ ./perl6 -e 'my $x = 1, 2, 3; say $x.perl' [1, 2, 3] -- which is the existing P5 semantics but without losing information until the value is used as a scalar. And lists can be used to construct all the other interesting cases. Will there be a syntax for choosing the strategy for reducing a list of pairs that contains duplicate keys to a Mapping? Moritz
Re: [perl #61126] return should apply to the lexically enclosing routine, map is no exception
Daniel, in rakudobug ticket [perl #61126] ():
The following two snippets of code are supposed to behave the same:
sub bar($code) { $code() };
sub foo { bar { return 1 }; return 2; }; say foo;
and
sub foo { map { return 1 }, 1; return 2 }; say foo;
both are supposed to return 1.
For some reason, map is being handled specially, while it is supposed to
be dispatched as any regular sub.
The above reasoning raises the following question for me: how do I
return from a sub or a method from within a map block?
(Let's say, for the sake of discussion, that there is a legitimate
reason to do this. I know that use a for loop if you want that kind
of side effect is a reasonable purist answer.)
// Carl
