Re: POD <-> Code entanglement
Moritz Lenz:
> =begin pod
>
> =head3 C
> [..]
> =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
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: 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: 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: 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: 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: 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?
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: 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?
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: 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?
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?
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 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?
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?
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 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. 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 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
Steve Lukas schrieb:
> More exceptional rules in a language are bad in itself.
> Those exceptions force people to more to learn more stuff
I guess that most people would understand the for/empty(/start/end) code
without having ever written any line of Perl.
They won't understand first/Any/gather directly, I think.
> On the other hand, there is no important reason for it because C<
>
> for @rray -> $el {}
> if ! @rray {}
>
> should work. It's short and easy to understand.
Agree, this looks good indeed.
--
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]
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]
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: 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: 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: 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: 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: 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: 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
