Re: Files, Directories, Resources, Operating Systems

[Mark Overmeer]

* 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

[Aristotle Pagaltzis]

* 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 // 

Re: how to write literals of some Perl 6 types?

[Moritz Lenz]

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.
>> 
>>  
> 
> 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

[Carl Mäsak]

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