Re: POD - Code entanglement
Moritz Lenz:
=begin pod
=head3 Cmethod from_string(Str $s);
[..]
=end pod
method from_string(Str $s){
# implementation of that method here
}
Since method signatures are very expressive in Perl 6, there should be a
way of accessing them in the POD without copy paste.
As I read =head 3 method... I also had the idea that semantically more
meaningful directives might be a good idea.
I mean POD uses constructs like headlines, lists, blocks, italic etc.
which all describe _how it looks like_ and not _what it is_.
A head3 might be the headline of a method documentation as well as one
introducing the contact information for the author of a module.
The directive doesn't have much semantics.
Other people might use head2 for documenting methods, what leads to a
pretty inconsistent look of the documentation.
So maybe directives like method, sub, attribute, class etc. might be a
better choice regarding semantics.
Of course those semantics are directly given in the code, so why not use
them as MarkOv proposed?
It's a bit like HTML-XML, where the former lacks most of the semantics
and makes the information processing - not to speak about a consistent
look over several documents - a lot harder.
I could imagine a semantic documentation in Perl6, that could be
translated to XML/HTML+CSS or to POD(6) for formatting it.
A semantic documentation could also be very useful in IDEs, where the
IDE could clearly (without guessing) determine the documentation for a
certain element.
Also you could automatically test if every method/class/.. has been
documented etc.
Semantics are very useful in documentation, why throw them away?
--
Thomas Wittek
http://gedankenkonstrukt.de/
Jabber: [EMAIL PROTECTED]
Re: propose renaming Hash to Dict
Larry Wall: Nope. Hash is mostly about meaning, and very little about implementation. Please don't assume that I name things according to Standard Names in Computer Science. I name things in English. Hash is just something that is disordered, which describes the associative array interface rather nicely, distinguishing it from the ordered Array interface. Hm, but with which would you explain a hash in plain english? What would be the closest equivalents in the real world? I'm not a native english speaker, but I've never heard or read the word hash outside CS. I guess this ones are close: - collection (contra: doesn't imply the access to an item) - dictionary (contra: might be assumed ordered) - directory (contra: might be assumed ordered, clashes with a file directory) - index (contra: might be assumed ordered, might be too technical) The problem with the implication of an order in the real world concepts is that you probably won't find one that isn't ordered. Those things allow us to find something easily by a word. But as we first have to find that word, we have an ordered list of the words... So there is no perfect candidate in the above list. But in my opinion they are still more english than hash. Additionally I believe it would be easier to learn that it's (e.g.) a dictionary that just is not ordered than learning a whole new word like a hash (which it was for me as a non-native english speaker). -- Thomas Wittek http://gedankenkonstrukt.de/ Jabber: [EMAIL PROTECTED]
Re: propose renaming Hash to Dict
Daniel Hulme: Larry Wall: I name things in English. Hash is just something that is disordered I'm not a native english speaker, but I've never heard or read the word hash outside CS. you've never eaten corned beef hash. To conclude, as hash definitely tastes better than a dictionary, we should stick to that name. ;) At least nobody can say that Perl is bad taste! -- Thomas Wittek http://gedankenkonstrukt.de/ Jabber: [EMAIL PROTECTED]
Re: Is Perl 6 too late?
Moritz Lenz schrieb: What makes Perl hard to read is the excessive use of special characters (/\W/). I disagree: The make it look ugly, but not hard to read. Even if it's only ugly: To what advantage? I don't think ugliness is a good characteristic of a programming language. Global variables with cryptic names, that no beginner can make any sense of by reading it. And after not working with $ for some months I can't remember it either, although I've got quite some Perl experience. Well, most of them are gone or renamed to more readable ones in p6. I hope so. I could only find the counterparts for __PACKAGE__ etc. in S02. I didn't find the one for e.g. $. Additionally I'm not a friend of sigils: Then you shouldn't program in perl. Really. Reason? I still haven't seen a good justification for sigils. To allow arrays and scalars and subs to have the same name (besides the sigil) although they have different content? No good idea I think. I also can't remember that I ever named a variable like a reserved word or operator. And even if I could, I'd consider it to be bad style. I would also like semicolons to be optional. Most people don't ;-). Oh, really? Source? :) I think they were invented to allow easier parsing and not easier coding. E.g. in JavaScript, Python, Ruby and Groovy they are optional or even don't exist. As I said, there are much more cases where you wouldn't need them but have to write them than vice versa. Optional semicolons save keystrokes, eye pain and stupid syntactic errors. And if you still like them, you could just use them, which is the definition of optional. I really like the Python way of doing it: Set the variables type on the assignment and remember it. The (fewer) operators now work according to the type of the operands. No implicit (and error prone) type casting. That way seems to be the best compromise of easiness and type safety. Well, if you like the python way, feel free to code in python. Oh, if I didn't like Perl, why should I care about posting my ideas here? Perl has stolen the largest part of the language from other languages. Why not do so again by adopting good ideas. Don't get me wrong, there's nothing bad in writing some critics, but yours is impossible to realize in Perl 6 Admittedly I'm much too late and I didn't expect applause for my critics -- but at least I hoped to get a discussion based on arguments. and therefore are it's hard to call it constructive. Unfortunately I already thought this. Even if everyone agreed that sigils (or forced semicolons, or tons of operators, ...) are more bad than good (and this seems like persuading the pope to allow homosexual muslims to marry with priests) the design process is probably too far to introduce such dramatic changes. Sadly. -- Thomas Wittek http://gedankenkonstrukt.de/ Jabber: [EMAIL PROTECTED]
Re: Is Perl 6 too late?
chromatic wrote: Global variables with cryptic names, that no beginner can make any sense of by reading it. And after not working with $ for some months I can't remember it either, although I've got quite some Perl experience. Most of those have gone away. Oh, some someone must agree that word characters might be the better choice. As I wrote Moritz, I could only find the replacements for __PACKAGE__ and alike. Additionally it would be very nice to group them in packages. Additionally I'm not a friend of sigils: I'm not a friend of potential conflicts between built-in operators and my identifier names (and especially the conflicts between scalar, aggregate, type, and function names). As I partially wrote Moritz, I a) don't think that it's the case very often. you have to write the sigil a thousand times where it wouldn't be useful for only 1 case where you'd have a name conflict. b) even if there would be a conflict, it might be considered bad style to use identical identifiers (besides the sigil) for different things (vars/objects/subs/operators/...). I would also like semicolons to be optional. When (smart) people talk about Python's whitespace problem, they don't mean *horizontal* whitespace. I'm not much into Python. But as at least Ruby, Python, JavaScript, Groovy and Lua (which all are relatively young languages) don't force you to write semicolons. So semicolons don't seem to be the best invention since sliced bread. There should be extra-syntax for the rare cases (multiline) and not for the common ones. Some say that there are too much operators in Perl(6). I partially agree. That's like saying there are too many function calls in Scheme. Perl's an operator-oriented language! And it should be. I really like the expressive power of most of the operators. Especially the new zip/junction/reduce/smart-match ones. But I don't like doing implicit type casting with operators. It's even discouraged in Perl5 as we have a warning for that. So maybe it'd be a good idea to completely drop it. People not only want code that _is_ sexy, but they also want it to _look_ sexy. At least almost everyone to whom I said, that I do most work in Perl, responded with some sentence containing the word ugly or unreadable. To get away from that image, it's neccessary to do some radical changes I think. -- Thomas Wittek http://gedankenkonstrukt.de/ Jabber: [EMAIL PROTECTED]
Re: Is Perl 6 too late?
Andy Armstrong schrieb: On 14 May 2007, at 11:51, Thomas Wittek wrote: I also can't remember that I ever named a variable like a reserved word or operator. And even if I could, I'd consider it to be bad style. How did you know which reserved words and operators were going to be introduced in the future so you could avoid them all? How did C, C#, Java, Ruby, Python, Lua, JavaScript, Visual Basic, etc. know? They didn't. If there is a new release, you always have to check if your code still runs. -- Thomas Wittek http://gedankenkonstrukt.de/ Jabber: [EMAIL PROTECTED]
Re: Is Perl 6 too late?
herbert breunung schrieb: please make a decision for you to program in a language [..] [..] try python. [..] Oh, just because I think that they've some smart design decisions? Why not steal them? BTW: Why do so much people say go away if you don't like it instead of being open for ideas and discussing them from a neutral point of view? -- Thomas Wittek http://gedankenkonstrukt.de/ Jabber: [EMAIL PROTECTED]
Re: Is Perl 6 too late?
Andy Armstrong schrieb: On 14 May 2007, at 12:31, Thomas Wittek wrote: How did C, C#, Java, Ruby, Python, Lua, JavaScript, Visual Basic, etc. know? They didn't. If there is a new release, you always have to check if your code still runs. I think that may be the point I'm making. Your point is that you don't have one? Do you believe, that new keywords are the only cause of breaking backwards compatibility? I don't think so. So you rely on testing your code anyway. Sigils won't save you from that. -- Thomas Wittek http://gedankenkonstrukt.de/ Jabber: [EMAIL PROTECTED]
Re: Is Perl 6 too late?
Frank Wiles schrieb: Take a look at actual code written in other languages and you'll find many variable names that end in things like _ary, _array, _dict, _list, etc. Actually I've not seen that often. Where I've seen it frequently is in Visual Basic and Delphi/Pascal. I hated it too. But I think that the name of an identifier (noun/verb, single/plural, the meaning of the word) already gives enough context to understand what type it is. And every use of it (assigning and reading) additionally makes it clear. So _for me_ there is no need for an additional hint for the type. -- Thomas Wittek http://gedankenkonstrukt.de/ Jabber: [EMAIL PROTECTED]
Re: Is Perl 6 too late?
chromatic wrote: theproblemlinguisticallyspeakingisthatsometimes [snipped] I can't remember that I said that you shouldn't separate your expressions (by punctation/whitspaces), $.but! (*adding$ %*characters _+that^# $might) @#not_ !#be() !necessary_ *#$doesn't! *(make) [EMAIL PROTECTED] =_easier to read and to type (in addition it was a torture to type that). So semicolons don't seem to be the best invention since sliced bread. There should be extra-syntax for the rare cases (multiline) and not for the common ones. Somehow English seems to get by with periods at the ends of statements, though almost no one pronounces them. Oh, I thought Perl was a programming language. My fault. Apples and oranges. Most modern scripting languages don't need the semicolons. I think there's no plausible reason for them. I agree. You need less ignorant colleagues. I'm not sure Perl 6 can fix that. I don't think that it's a point of ignorance. Especially as they (and enough other people on the web) only seem to be ignorant regarding Perl. Strange, huh? By the way, I'm still waiting to meet your cadre of Dylan hackers. I never claimed to have some. -- Thomas Wittek http://gedankenkonstrukt.de/ Jabber: [EMAIL PROTECTED]
Re: Sigils by example
Juerd Waalboer wrote: Thomas Wittek skribis 2007-05-14 22:20 (+0200): But I think that the name of an identifier (noun/verb, single/plural, the meaning of the word) already gives enough context to understand what type it is. [examples] You are right, I should have weakened this sentence by in most cases. Tricky from you to cut out my next sentence, which was about additional context that's needed in this cases and that your examples are missing of course: Thomas Wittek also wrote: And every use of it (assigning and reading) additionally makes it clear. So _for me_ there is no need for an additional hint for the type. Juerd Waalboer wrote: And how on earth would you write object.foo(), where foo is a variable holding a reference to a method, not the name of the method, if you had no sigils? That would not happen in my code. I consider having the same name for different things bad. I even wouldn't do that _with_ sigils. The Perl Way: $object.foo() calls the method called foo. $object.$foo() calls the method that is in the variable $foo. My way: someref = somemethod object.someref() Of course you could argue that you don't know in advance, if object has a method with that name, so you cannot manually avoid the conflict. But it should be no problem to put out a warning/error at runtime (or maybe even at compile time) when a variable name clashes with a method name. -- Thomas Wittek http://gedankenkonstrukt.de/ Jabber: [EMAIL PROTECTED]
Re: Is Perl 6 too late?
Juerd Waalboer schrieb: Thomas Wittek skribis 2007-05-14 0:42 (+0200): excessive use of special characters (/\W/). This seems to be I don't like regexes. Ignoring for now that Perl 6 regexes will be more verbose and thus easier to read for someone without much prior exposure to them, what would you suggest as an alternative to regex matching? Not ignoring that will nullify your argument. Regexps/rules are great, and I never said anything differing. If the syntax gets more readable without any cost (in which I belive) its even better. Now do s/Regexps\/rules are/Perl is/ on the last sentence. On the other hand, the overall structure of a program is often more obvious, exactly because so much more fits in one screenful. My suggestions won't have an impact on the expressiveness of Perl. So in many cases you might have even less characters on your screen. Of course some special character sequences would be replaced by word character sequences, but that won't fill your screen by a magnitude. -- Thomas Wittek http://gedankenkonstrukt.de/ Jabber: [EMAIL PROTECTED]
Re: explicit line termination with ;: why?
Andrew Shitov: If the line of code is not ended with ';' the parser tries first to assume [..] Wouldn't that be unambigous? foo = 23 bar = \ 42 ? I think there would be no ambiguities and you only had to add additional syntax for the rare cases instead of the common cases. -- Thomas Wittek http://gedankenkonstrukt.de/ Jabber: [EMAIL PROTECTED]
Re: Is Perl 6 too late?
Austin Hastings: A similar trade-off exists with the statement terminating semicolon. In this case, it involves the number of statements per line: A language that terminates statements can ignore whitespace, allowing multiple statements per line and statements that span multiple lines. Still possible with optional semicolons (as you say later): a = 1 b = \ 2 c = 3; d = 4 The vast majority of languages have opted to terminate statements. Most of the younger scripting languages didn't. Probably the best argument is that encountering a semicolon (or full stop, in COBOL) is a positive indicator rather than a negative one. I see a semicolon. I know the statement is over. as opposed to I don't see a continuation marker, so it's likely that the statement is over, although it could be tabbed way off to the right or something. Your semicolon could also be tabbed way off, so you can't be sure there either. I see no semicolon, so it's likely that the statement continues on the next line. So line termination doesn't gain a punctuation character No problem I think. and causes the ends of lines to be uncertain. It's exactly as certain as with semicolon termination. See above. It does reduce typing, for the small crowd of people that wouldn't just use them anyway because they use them in every other language. I think the lack of value here outweights the savings of one character per line. But even if the advantage of line termination is low (some characters saved, some people might say it looks cleaner), I cannot see any advantage of semicolon termination. -- Thomas Wittek http://gedankenkonstrukt.de/ Jabber: [EMAIL PROTECTED]
Re: Sigils by example
Juerd Waalboer schrieb: Thomas Wittek skribis 2007-05-15 0:48 (+0200): The Perl Way: $object.foo() calls the method called foo. $object.$foo() calls the method that is in the variable $foo. My way: someref = somemethod object.someref() Of course you could argue that you don't know in advance, if object has a method with that name, so you cannot manually avoid the conflict. Indeed. Now you have to know your object very well, and avoid all of its method names for variable names. For example, an HTTP::Request object has a .headers method. If Your Way were in effect, I could no longer safely use the name headers for my own variables, and then still call the headers method on the object. You are right, it would not be practical to prohibit variable names to be the same like any other object method names. But still I can't imagine a useful example where I want so call a method of object A on object B, which doesn't have this method. Would it be a good idea to call methods on objects, that never thought of this methods? If it wasn't allowed to do so (because it may be not a good idea at all -- i don't know), we wouldn't have that problem: Storing a reference to a method of object A, that will only be called on object A could be done like this: my ref = A.method ref() Perl allows both avoiding clashes and not-avoiding clashes. Your way only strictly requires the former programming style. And since my preferred style is different, I'm glad you're not designing Perl 6. I'm also glad not to do that as I don't think that I'd have the knowledge to do that. I just offer my thoughts. -- Thomas Wittek http://gedankenkonstrukt.de/ Jabber: [EMAIL PROTECTED]
Re: Sigils by example
chromatic schrieb: On Monday 14 May 2007 15:48:24 Thomas Wittek wrote: But it should be no problem to put out a warning/error at runtime (or maybe even at compile time) when a variable name clashes with a method name. Do you always know all of the method names in your entire memory space at compile time? No, and as I wrote to Juerd, I now think that it's also not a good idea at runtime. -- Thomas Wittek http://gedankenkonstrukt.de/ Jabber: [EMAIL PROTECTED]
Re: explicit line termination with ;: why?
John Macdonald schrieb: It's also, in many cases, harder to edit - that's why a trailing comma in a list that is surrounded by parens, or a trailing semicolon in a block surrounded by braces, is easier to manage. Now that the list is surrounded by parens makes clear that it ends with the closing paren and not with a line break. So you could still use commas (without backslashes) to separate the items over multiple lines. See e.g. http://docs.python.org/ref/implicit-joining.html Having punctuation where there is a stop is more natural than having an explicit marker for don't stop here, keep going. That's the pro-semicolon reason that makes most sense in all comments that I've read so far in this discussion. But maybe that's just something where you have to get used to. -- Thomas Wittek http://gedankenkonstrukt.de/ Jabber: [EMAIL PROTECTED]
Re: Is Perl 6 too late?
chromatic schrieb: On Thursday 03 May 2007 03:06:43 Andrew Shitov wrote: What is nedded is a very simple step: Contributors. And to attract contributors, you have to have a convincing vision. I'm not sure, if the (current) Perl6 specs are convincing enough to attract the developers out there. Sure there are a lot of great ideas. But imho Perl6 still has quite some deficiencies, that are criticized very often for Perl5. digressing I'm only a distant observer of the Perl6 design process, so I might not be in the position to criticize Perl6. On the other hand, a distant view might be insightful. This is not intended to be a provocation. But I also think that there is a great opportunity to make _big_ changes to Perl to be even more competitive. But maybe Perl6 is probably too far defined to encounter big changes in some critical aspects. As Ruby and Python are getting more and more attraction [1][2] I think they do something right, that Perl doesn't. What I think where both (especially Python) do better is in readable code. What makes Perl hard to read is the excessive use of special characters (/\W/). In my opinion, reducing the use of those characters would make Perl a lot easier to read and also easier to write. Global variables with cryptic names, that no beginner can make any sense of by reading it. And after not working with $ for some months I can't remember it either, although I've got quite some Perl experience. Additionally I'm not a friend of sigils: Typing them is relatively painful, for reading there is no advantage if you use an editor with decent syntax highlighting and the code looks more cryptic. The answer in Perl6 are twigils, great... One step backwards in my optinion. Most programming languages /C(++|#)?|Java(Script)?|Python|Ruby|Groovy/... don't need them. The only obvious advantage of using sigils is variable interpolation in strings. But that could easily be done only in strings without the need to put a $ in front of each and every variable name in the rest of the code. I would also like semicolons to be optional. There are far more cases of single line statements than multiline statements. So you would save quite some characters, when the semicolon would be optional and you could concatenate multiline statements with e.g. a backslash. Some say that there are too much operators in Perl(6). I partially agree. I don't like the implicit type casting forced by the operators (== int / eq string). That's harder to learn and remember. Harder to read also. I really like the Python way of doing it: Set the variables type on the assignment and remember it. The (fewer) operators now work according to the type of the operands. No implicit (and error prone) type casting. That way seems to be the best compromise of easiness and type safety. I could continue on that, but I've already written too much... [1] http://radar.oreilly.com/archives/2007/05/state_of_the_co_6.html [2] http://www.google.com/trends?q=perl%2C+python+-snake%2C+ruby /digressing People not only want code that _is_ sexy, but they also want it to _look_ sexy. -- Thomas Wittek http://gedankenkonstrukt.de/ Jabber: [EMAIL PROTECTED]
Re: for ... else
Darren Duncan schrieb:
At 11:17 PM +0100 3/3/07, Thomas Wittek wrote:
Larry Wall:
: if ($item = 'foobar') {
== of course ;)
If you actually wrote that, then you'll always find that the first
item has the value 'foobar'. :)
Care to try a third time?
I don't think the numeric-casting == will do what you want either.
Shame on me. I confused my examples. Read the 42 thing and wrote above.
Must be of course, to leave the gag running ;)
Next time I should write my messages with use warnings;...
--
Thomas Wittek
http://gedankenkonstrukt.de/
Jabber: [EMAIL PROTECTED]
Re: for ... else
Larry Wall:
: if ($item = 'foobar') {
== of course ;)
If you actually wrote that, then you'll always find that the first
item has the value 'foobar'. :)
Well, leaving out the extraneous stuff, here's both kinds of else in one:
$result = first 42, (@items || say No items.)
err say The end has been reached. 42 not found.;
That's a solution to find the first matching item.
But that's not the only reason to loop through a list.
else would be a general purpose solution.
To get all of it in, you could use something more like:
$result = first Any, gather for @items || say No items. {
FIRST {
say Mh, I'll look for 42!
}
when 42 {
say I've found the Answer to Life, the Universe, and Everything!;
take $_;
}
LAST {
say The end has been reached. 42 not found.;
}
}
That's, well, elegant! Yes.
Because and but it's tricky.
Nothing where I'd say wow, thats an easy solution to my problem!.
It's a bit complicated, because you have to understand and combine
several concepts. That's elegant. But not easy, I think.
I think it's not simple enough for this simple kind of problem.
--
Thomas Wittek
http://gedankenkonstrukt.de/
Jabber: [EMAIL PROTECTED]
for ... else
Today I stumbled upon the Perl5 module For::Else.
It adds an else block to a foreach loop:
foreach my $item (@items) {
#process each item
} else {
#handle the empty list case
}
I find it a very nice addition as I've written code like this:
if (@stuff) {
for my $thing (@stuff) {
..
}
} else {
..
}
many times. An else block would save keystrokes and would make the code
more readable. Python also has it.
What do you think?
--
Thomas Wittek
http://gedankenkonstrukt.de/
Jabber: [EMAIL PROTECTED]
Re: for ... else
Luke Palmer schrieb:
That is not what it means in Python.
You trapped me. :) Actually I don't know any python but I've once read a
for/else construct in python. But obviously it doesn't dwIm.
From the Python Reference Manual:
When the items are exhausted (which is immediately when the sequence
is empty), the suite in the else clause, if present, is executed,
and the loop terminates.
I'm not sure about either interpretation, but admittedly Python's is
harder to emulate clearly.
I'd like the For::Else behaviour more. Especially as I remember numerous
times writing an if clause to check if a list is empty before processing it.
I don't remember many cases where I wrote something like this:
my $found;
foreach my $item (@items) {
if ($item = 'foobar') {
$found = 1;
last;
}
}
unless ($found) {
..
}
To make it more clear, I could imagine (a subset of) this:
for @items - $item {
say $item;
if $item == 42 {
say I've found the Answer to Life, the Universe, and Everything!;
last;
}
} start {
say Mh, I'll look for 42!
} end {
say The end has been reached. 42 not found.
} empty {
say No items.
}
--
Thomas Wittek
http://gedankenkonstrukt.de/
Jabber: [EMAIL PROTECTED]
Re: Y not
Damian Conway schrieb: If the very much more readable 'zip' and 'minmax' are to be replaced with 'ZZ' and 'MM', then I think that's a serious step backwards in usability. Fully agree here and I think that there are still even more places, where the usability could be improved: Say more words/letters, less symbols/special characters. Especially special characters (shift + num: [EMAIL PROTECTED]*...) are harder to type (I think I can type a 5-char word a lot faster than shift-5 = % - additionally the shift-wrench disturbs the typing flow) and above all harder to read/intuitively understand/learn/remeber than plaintext keywords. Of course there will always be a trade-off and special characters are the most usable choice in many cases. But I also think that in many other cases words will be more usable. As the usability of a tool greatly influences it's acceptance and usage, this is a point, where we really should think about. -- Thomas Wittek http://gedankenkonstrukt.de/ Jabber: [EMAIL PROTECTED]
Re: Y not
Larry Wall schrieb: I think the ¥ and Y operators are going to have to change to something else. Very probably I missed something as I'm only a distant observer of the Perl6 development: Why not just call it zip?! There is a function called zip, wouldn't it be possible to create an operator with the same name? zip(@a; @b) - function @a zip @b - operator Or would that lead to grammar ambiguities, that are impossible to resolve? -- Thomas Wittek http://gedankenkonstrukt.de/ Jabber: [EMAIL PROTECTED]
Re: CGI Session management (was Re: the CGI.pm in Perl 6)
Fagyal Csongor schrieb: Ian Langworth wrote: A general, simple CGI handling module fits into 200 lines, including POD. [..] You don't really need more. IMHO a CGI module parses/preprocesses/decodes/etc. all incoming parameters (POST, GET, COOKIES), and that's it. I can support this statement: In a ~30k lines (incl POD) web project I actually use CGI.pm mostly for parameter parsing: $ grep -ri 'cgi-' * | grep -v new | wc -l 97 Wehereas I hardly use for anything else: $ grep -ri 'cgi-' * | grep -v new | grep -v param | wc -l 7 4 of these 7 matches address file upload handling, the other 3 match in an other custom module with the name *::CGI - not CGI.pm. But I think that it would be a good idea to create a clean, servlety foundation, upon which you still can implement a 200 lines CGI.pm/Web.pm/foo.pm that covers the most common web-request tasks. Regards -- Thomas Wittek http://gedankenkonstrukt.de/ Jabber: [EMAIL PROTECTED]
OT: Re: Web development I: Web::Toolkit
A. Pagaltzis schrieb: On top of this, roughly 80% (or so it sometimes feels) of the useful attributes defined in HTML do not have any tangible browser support (such as `cite` on `blockquote`/`q`, or `datetime` on `ins`/`del`). At least without CSS. You can use those tags to create a more semantic markup which can be styled using CSS. Of course there is more than just design. The cite attribute of the blockquote tag isn't supported by any browser AFAIK. -- Thomas Wittek http://gedankenkonstrukt.de/ Jabber: [EMAIL PROTECTED]
Re: renaming grep to where
Jonathan Lang schrieb: IMHO, syntax should be left alone until a compelling reason to change it is found. While I think it would be nice to have a more intuitive name for grep What would be the disadvantage of renaming it to a more intuitive name? I can only see advantages. I don't think that this qualifies as a compelling reason to change it - especially since it's so easy to add aliases via modules As Smylers said above: Please, no more aliases. They only create confusion. Regards -- Thomas Wittek http://gedankenkonstrukt.de/ Jabber: [EMAIL PROTECTED]
Re: the CGI.pm in Perl 6
(Randal L. Schwartz) schrieb:
David == David Cantrell [EMAIL PROTECTED] writes:
David That's two tasks. It should be two modules.
No, it's an *integrated* task. The form-generation stuff needs tight
coupling
with the getting (and setting) of the incoming param values.
A separate module, say HTML::Formgenerator, could easily use CGI.pm (or
Web.pm,...) to get and set parameters:
$value = $query-param('foo');
$query-param('foo','an','array','of','values');
I see no need to integrate those modules.
Regards
--
Thomas Wittek
http://gedankenkonstrukt.de/
Jabber: [EMAIL PROTECTED]
Re: renaming grep to where
Trey Harris schrieb:
@filtered = @originals.where:{ .foo eq $bar };
Note that this can be written:
@filtered = any(@originals) ~~ { .foo eq $bar};
I generally like words more than sequences of non-word characters as
you can quickly remember/guess the meaning, what's not always the case
when you're reading code (of a language) that you haven't read for a
while. Also you can usually type them more quickly as the word-charactes
have a more prominent position than the special characters on most keybords.
Best Regards
--
Thomas Wittek
http://gedankenkonstrukt.de/
Jabber: [EMAIL PROTECTED]
Re: the CGI.pm in Perl 6
Steffen Schwigon schrieb: Thomas Wittek [EMAIL PROTECTED] writes: An other acceptable solution would be to create a backwards compatible P6 CGI.pm and create a new Web.pm with an all new interface, like Mark suggested. I would strongly expect the CGI module to do the same as it did for the last 200 years and create another name for any new school web development. Catalyst, Jifty, Acme, Acyou, SillyIdol, WhatEver. So we might agree ;) Catalysy, Jifty [..] are all higher level complete frameworks. I used CGI.pm for rather lower level tasks (POST/GET-parsing, HTTP redirects, ...) than as a foundation to build complete applications (where the higher level framework come in). So I think that there should be a (well designed) module for those lower level (donkeywork) tasks and only for those (so definitely no HTML-generation...). Other frameworks (or simple CGI-scripts or even a backwards compatible CGI.pm) could be built upon this foundation. -Thomas
Re: the CGI.pm in Perl 6
Trey Harris schrieb: I agree with the sentiment, but as a practical matter, not having HTML methods in CGI.pm could drastically limit Perl 6 adoption. Oh well. I thought it was common sense that it's a bad idea to mix code and markup. Who really wants to do itself this pain should use a separate module for that imho (or better a templating system like Template Toolkit). If Perl 5 programmers get used to how they can mechanistically port their programs to Perl 6, they will do so with the same sort of ah-hah moments you've posted about on the Pugs blog, and it will be a good experience. They can do: use perl5:CGI; if they want that legacy support. If Perl6 CGI.pm is intended to be the successor of the P5 CGI.pm (the quasi-standard for Perl web programming) is should really get a modern design. An other acceptable solution would be to create a backwards compatible P6 CGI.pm and create a new Web.pm with an all new interface, like Mark suggested. But then this new module cannot profit of the popularity of the name CGI.pm and many people will say Ah, Perl6 web development is stuck at the 10 years old Perl5 CGI.pm interface. I'll use (python|ruby( on rails)?|.+). That would be sad. now: use CGI; use CGI::HTMLgenerators; # Available separately, deprecated That'd be ok. Just my 2ct. -Thomas
Re: S04 - forbidden coding-style
Bearing that in mind, would the eye-socket-burning return $foo IF $something; really be so bad? Operators/reserved words should be lowercase. Period. ;) I think that this would heavily break consistency, annoying new users. -Thomas
Re: S04 - forbidden coding-style
Markus Laire schrieb: Operators/reserved words should be lowercase. Period. ;) I think that this would heavily break consistency, annoying new users. There are already many uppercase reserved words in perl6: Pseudo-packages from S02 MY, OUR, GLOBAL, OUTER, CALLER, CONTEXT, SUPER, COMPILING Closure traits from S04 BEGIN, CHECK, INIT, END, FIRST, ENTER, LEAVE, KEEP, UNDO, NEXT, LAST, PRE, POST, CATCH, CONTROL From S10 AUTODEF, CANDO Submethods from S12 BUILD, BUILDALL, CREATE, DESTROY, DESTROYALL Pseudo-class from S12 WALK I might've missed some. So making statement modifiers uppercase would just be an another place where perl6 uses uppercase reserved words. Actually I don't know all of them but most seem to be (part of) identifiers, not operators. Of course they are reserved words. What I wanted to say is that it would annoy me, if almost all operators and control-flow keywords are lowercase but a hand full of them has to be written uppercase. It would be especially annoying, if a keyword like if exists in both lower and upper case. Besides the fact that is looks ugly and is a bit harder to type, imho ;) -Thomas
Re: Mutil Method Questions
Steffen Schwigon:
Thomas Wittek [EMAIL PROTECTED]:
Maybe I just phenomenally misunderstood multi subs, but unless I
did, I can't see why we want to have subs when we can have multi
subs that can do the same and even more.
I understand your point and I confess I'm not sure.
At least there seems to be a visibility difference. In S12 I found
those two sentences:
1. [sub (or method) without a multi] [...] Only one such sub (or
method) can inhabit a given namespace, and it hides any outer subs
(or less-derived methods) of the same short name.
2. [subs or methods declared multi] [...] It does not hide any
routines with the same short name but a different long name. In
other words, multis with the same short name can come from several
different namespaces provided their long names differ and their
short names aren't hidden by a non-multi declaration in some
intermediate scope.
So it looks like we can hide several multis with one sub:
class Foo {
multi method somesub (Int $arg) {
foo - Int: $arg.say
}
multi method somesub ($arg) {
foo - Scalar: $arg.say
}
}
class Bar is Foo {
multi method somesub ($arg) {
bar - Scalar: $arg.say
}
}
class Baz is Foo {
method somesub ($arg) {
baz - Scalar: $arg.say
}
}
my $foo = Foo.new;
my $bar = Bar.new;
my $baz = Baz.new;
$foo.somesub(scalar);
# foo - Scalar: scalar
$foo.somesub(42);
# foo - Int: 42
$bar.somesub(scalar);
# Bar - Scalar: scalar
$bar.somesub(42);
#I'd expect (but it doesn't do that, see text below):
#using more specialized method from Foo
# Foo - Int: 42
$baz.somesub(scalar);
# Baz - Scalar: scalar
$baz.somesub(42);
#_not_ using method from Foo as a non-multi sub overwrites it
# Baz - Scalar: 42
Interestingly $bar.somesub(42) doesn't use the multi method somesub (Int
$arg) of the class Foo (whose signature would provide a better match)
but it also uses multi method somesub ($arg) of the class Bar. So
actually every method that somehow matches in a less derived class
will be used. The more specialized methods of the more derived classes
are hidden, which I didn't expect (but what probably will be better
performance wise).
So I have no Idea why I would like to use a non-multi as even multis
hide the methods of more derived classes.
So even if there are cases where I want the non-multi-behavior (what
ever it really is), I think they are rare.
So I'd suggest that this behavior shouldn't be the default for all subs.
Instead I'd find it more intuitive if every sub is a multi sub by
default and that you could opt in the non-multi-behavior with a keyword
like overriding, dominant or preferred.
I think that the multi-behavior will be more common and thus should be
the default (as it is in most other languages). The probably less common
non-multi-behavior should require an additional keyword. Not vice versa.
Again, that's all written from my fairly small knowledge of the Perl6
language. But supposed that one, who starts learning Perl6, will also
have a small knowledge at the beginning, this concepts might confuse the
beginner, if he/she has to define extra keywords for a behaviour that's
probably more common and omitting the keywords will lead to a less
common behavior.
Maybe we should steal the ruby principle of least surprise here, which
I find a very good principle.
Maybe someone can enlighten me ;)
Best regards,
-Thomas
Re: Mutil Method Questions
Steffen Schwigon schrieb:
At least the many keywords seem to be necessary to map the complexity
of different paradigms possible in Perl6. Multimethods are not just
overloading as in C++. Second, the different keywords declare
different behaviour you can choose. Just read S06, it's explained
quite understandable.
Hm, but wouldn't whose be equivalent?
sub foo ($bar) {
$bar.say;
}
multi sub foo ($bar) {
$bar.say;
}
Aren't subs a subset of multi subs, meaning that every sub can be
expressed as a multi sub?
Is there anything a sub has in advantage of a multi sub?
So might not just every sub be a multi sub?
If the only difference is, that you _must not_ declare a sub twice with
different argument lists, I think that this one is relatively
unimportant and letting every sub be a multi sub seems to be more
consistent to me in opposite to this arbitrary looking distinction.
Maybe I just phenomenally misunderstood multi subs, but unless I did, I
can't see why we want to have subs when we can have multi subs that can
do the same and even more.
-Thomas
Name of this wiki
Conrad Schneiker schrieb: 3) (Quoting from above link): I propose that the wiki be called P6 to signify its use of Perl6. I presently prefer something like the Perl++ Wikicosm. Another idea: Wiki is hawaiian for quick, fast. Why not take another hawaiian word? Some examples (you will find more on the web): -Aloah: Greeting, love ;) -Kākau: Write -Kala: To release, free -Kāmelo: Camel -Makana: Gift -Mana: Spiritual power -Momi: Pearl -Nani: Beautiful -Pinao: Dragonfly Maybe combine these word with wiki: Kāmelo wiki = Fast camel :). I'd also like Bikini wiki, sounds sexy, doesn't it? Unfortunately, this word does not have much in common with Hawaii, instead of both lying in the pacific ocean. -Thomas
Re: class introspection and extention
max demmelbauer schrieb: * how can i serialize objects (like the use Storable qw(freeze thaw) in perl5.8) Try $object.perl(.say) as stated in http://svn.openfoundry.org/pugs/docs/articles/tpr.pod (or http://gedankenkonstrukt.de/perl6doc/articles/tpr.html ;) ) -Thomas
Re: $1,000 prize for Perl 6 Wiki written in Perl 6
Udo Güngerich schrieb: Thomas Wittek wrote: Unfortunately you probably have to throw away/heavily modify earlier increments, if you add features like a flexible syntax, which will need a different internal infrastructure. Well, if object-oriented design has any advantage at all, here it is! [..] Only you will have to define the abstract class or plugin bay from the first minute in the right way (the only was softly ironic). Of course. But I guess that the architecture/design for such a flexible piece of software will be relatively complex. I think that creating this architecture might even take too long to get a running wiki quickly. Where quickly of course is a term still to be defined ;) -Thomas
Re: $1,000 prize for Perl 6 Wiki written in Perl 6
Juerd schrieb: * Markdown does not have tables. * Textile does not have paragraphs in table cells. * Kwiki does not have paragraphs in table cells. Unless someone comes up with another way to do side-by-side layouts (extremely useful for showcasing differences between Perl 5 and Perl 6), all of these formats are not suitable. I suppose doing it the Perl-way: Stealing the best of each syntax, adding what's missing. I don't think that we have to choose an existing syntax, but can create one that combines the best features of the existing ones. Of course, this would be more work. Probably it will not be easy to get a common agreement of what's best. Additionally the mixed up syntax shouldn't look too inconsistent - but that won't be too hard I think. Also some restrictions have to be considered. E.g. if we want to allow block oriented parsing (nested blocks in other blocks), the syntax must be unambiguous on how to detect blocks (within other blocks). That's mainly what I did as stated in my first post[1]. Look at several wiki-syntaxes and combine, what _I_ think is the syntax suited best for a wiki. And I think that such a (then collaborative) process might be a good idea for the definition of the syntax of this wiki. -Thomas
Re: $1,000 prize for Perl 6 Wiki written in Perl 6
Damn, forgot the link. Thomas Wittek schrieb: That's mainly what I did as stated in my first post[1]. [...] [1]: news://nntp.perl.org:119/[EMAIL PROTECTED]
Re: $1,000 prize for Perl 6 Wiki written in Perl 6
Udo Güngerich schrieb: Why not doing a wiki system that does NOT have a fix syntax but rather allows defining its syntax rules in e.g. YAML and thus being entirely flexible? [..] It should have a proper user/groups system as well... [..] Why not give the wiki a web service API [..] Good ideas. But maybe we should start a bit smaller ;) It might be a good idea to create a list of features separated in several increments (releases) to get a running system early. I could imagine increments like Parsing/Converting, Storage backend/Revision control, User management, ... Unfortunately you probably have to throw away/heavily modify earlier increments, if you add features like a flexible syntax, which will need a different internal infrastructure. But targeting such a feature monster will probably take too much development time. Maybe a feature complete version could be targeted as the Perl6-Wiki-Software. But before this one a Lite Version, which will be used to have a wiki quickly available, could be developed. -Thomas
Re: Where can I find a Perl 6 langauge reference? - Conclusion
Thomas Wittek wrote: Where should I start, when I want to get myself a picture of the current Perl 6 language features and syntax? To conclude this, I'll give a list of online docs I find interesting about learning Perl6: 1) Synopses: http://dev.perl.org/perl6/doc/synopsis.html 2) pugs/docs/Perl6/ (HTML): http://gedankenkonstrukt.de/perl6doc/ (HTML-ified every day at 0:00 on this (my) server) 3) pugs/docs/Perl6/ (POD): http://svn.openfoundry.org/pugs/docs/Perl6/ 4) pugs/examples: http://svn.openfoundry.org/pugs/examples/ 5) Pugs first blood (german): http://dresden-pm.org/cgi-bin/twiki/view/PM/PugsFirstBlood 6) Pugs first blood (english): http://dresden-pm.org/cgi-bin/twiki/view/PM/PugsFirstBloodEnglish 7) German Perl6 tutorial: http://wiki.perl-community.de/bin/view/Wissensbasis/Perl6Tutorial 8) Perl 6 Wiki: http://perl.net.au/wiki/Category:Perl_6 Regards, -Thomas
Re: $1,000 prize for Perl 6 Wiki written in Perl 6
A. Pagaltzis schrieb: * Amir E. Aharoni [EMAIL PROTECTED] [2006-05-28 23:00]: The popularity of Wikipedia made Media-Wiki syntax the de-facto standard. It's not perfect, but please don't reinvent the wheel (even though it's a PHP wheel). [..] Noone other than Mediawiki uses the Mediawiki syntax. I posit that the reason is that that syntax blows chunks. I have to agree. 'bold and italic' is definitely not what I understand as an intuitive syntax. I did some work on designing an easy wiki syntax for a wiki plugin for my (yet another...)[1] webdev framework. I looked at the syntax of several wikis and tried to create an easy to write (and to parse) syntax: http://gedankenkonstrukt.de/konstrukt/syntax.html This actually has been implemented and works fine. It's not released yet and also not intended to be a base for a perl6-wiki. I'm just posting it to suggest a possible syntax. Interestingly it is very similar to Markdown although I never heard about it before :) Regards, -Thomas [1]: I believe everyone has to build one on its own ;)
Re: $1,000 prize for Perl 6 Wiki written in Perl 6
A. Pagaltzis schrieb: * Thomas Wittek [EMAIL PROTECTED] [2006-06-03 22:30]: Interestingly it is very similar to Markdown although I never heard about it before :) Hmm, it doesn’t look similar at all to me? Headers (Markdown): # This is an H1 ## This is an H2 ## This is an H6 Headers (/me): = This is an H1 == This is an H2 == This is an H6 Lists (Markdown): * Red * Green * Blue Liste (/me): * Red * Green * Blue Code (Markdown): This is a normal paragraph: This is a code block. Code (/me): This is a normal paragraph: This is a code block. Horizontal Rules (Markdown): - Horizontal Rules (/me): - Emphasis (Markdown): e.g. *single asterisks* Emphasis (/me): *single asterisks* There are of course many cases where the syntax differs, but only I said that they are similar, not identical ;) Especially the linking differs from my syntax. Not even superficially similar, but most importantly, it looks line-based. Markdown is block-based. If you want another example of block-based, take a look at the new-style PhpWiki markup. These let you do things like put a code block inside a blockquote within a list item, or heck, even things as simple as multi-paragraph list items. Mediawiki markup, like many other wiki syntaxes, can’t express that. Yours doesn’t look like it can either. No, (currently) blocks cannot be nested. Blocks are separated by =1 newlines and consist of only one type of the ones listed in http://gedankenkonstrukt.de/konstrukt/syntax.html#BLOCK_SYNTAX. I only wanted to cover the most common formatting cases. It's far from being feature-complete and not intended to be a full-sized wiki-system. Bye, -Thomas
Where can I find a Perl 6 langauge reference?
Where should I start, when I want to get myself a picture of the current Perl 6 language features and syntax? Where is the best place to take a look at, when I want to start experimenting with Perl 6 and pugs? Would you recommend reading the synopses[1]? Or should I take a look at pugs-doc? Or is there a point to start? Thank you! -Thomas [1] http://dev.perl.org/perl6/doc/synopsis.html
Re: best of perl6 for tutorial
herbert breunung schrieb: its understood that i will try, once finished to translate it for the pugs trunk. Might have been better vice versa. First write it in english and then translate it to german. This way you would've got more responses on that... -Thomas
