-
Notifications
You must be signed in to change notification settings - Fork 287
Some work on py-nutshell.rakudoc #4698
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from 2 commits
0e3ac1f
9605a68
c82d575
1de6d36
3b73256
6f8e5ed
323acff
5e6f26f
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -32,7 +32,7 @@ Raku | |
| put "Hello, world!" | ||
|
|
||
| There is also the L<say|/routine/say> keyword, which behaves similarly, but will | ||
| call the L<gist|/routine/gist> method of its argument. | ||
| call the L<.gist|/routine/gist> method of its argument instead of the C<.Str|/routine/Str> method. | ||
|
|
||
| Raku | ||
|
|
||
|
|
@@ -64,8 +64,9 @@ matching curly braces are closed. | |
|
|
||
| In Raku, a semicolon signifies the end of a statement. | ||
| The semicolon may be omitted if it is the last statement | ||
| of a block. The semicolon may also be omitted if there | ||
| is a closing curly brace followed by a newline. | ||
| of a block (i.e. of a list of statements enclosed in curly braces). | ||
| The semicolon may also be omitted after a closing curly brace | ||
| followed by a newline. | ||
|
|
||
| Python | ||
|
|
||
|
|
@@ -81,6 +82,7 @@ Raku | |
| 3 + 4; | ||
| say 1 + | ||
| 2; | ||
| if True { say 42 } | ||
|
|
||
| =head2 Blocks | ||
|
|
||
|
|
@@ -123,7 +125,7 @@ initialized or declared and initialized at once. | |
| $foo = 12; # initialize | ||
| my $bar = 19; # both at once | ||
|
|
||
| Also, as you may have noticed, variables in Raku usually start with sigils -- | ||
| Also, as you may have noticed, variables in Raku usually start with sigils – | ||
| symbols indicating the type of their container. Variables starting with a C<$> | ||
| hold scalars. Variables starting with an C<@> hold arrays, and variables | ||
| starting with a C<%> hold a hash (dict). Sigilless variables, declared with a | ||
|
|
@@ -398,20 +400,23 @@ I<Raku> | |
| say "Symbol '$symbol' stands for $element"; | ||
| } | ||
|
|
||
| =head2 Lambdas, functions and subroutines> | ||
| =head2 Functions, subroutines and lambdas | ||
|
|
||
| Declaring a function (subroutine) with C<def> in Python is accomplished | ||
| with C<sub> in Raku. | ||
|
|
||
| =begin code :lang<python> | ||
| def add(a, b): | ||
| return a + b | ||
| =end code | ||
|
|
||
| =begin code | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Why split this code up?
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The intention was to have Python code and Raku code apart like elsewhere in the document to emphasize the shift in language (and to not have Raku code in a block marked as "Python highlighting"). But the example does work well the way it is, perhaps even better, so yes I think I'll revert it (and probably add comments
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Oh, I hadn’t even noticed they were not the same language - in that case, sorry, please separate them AND tag each with the right language attribute - the more raku code we can verify the better
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ah, I see – I've done that now |
||
| sub add(\a, \b) { | ||
| return a + b | ||
| } | ||
| =end code | ||
|
|
||
|
|
||
| The C<return> is optional; the value of the last expression is used as | ||
| the return value: | ||
|
|
||
|
|
@@ -431,8 +436,8 @@ sub add($a, $b) { | |
| Python 2 functions can be called with positional arguments | ||
| or keyword arguments. These are determined by the caller. | ||
| In Python 3, some arguments may be "keyword only". | ||
| In Raku, positional and named arguments are determined | ||
| by the signature of the routine. | ||
| In Raku, each argument is either positional or named, | ||
| as determined by the signature of the routine. | ||
|
|
||
| Python | ||
|
|
||
|
|
@@ -827,4 +832,23 @@ Raku using the List type, or from an external module. | |
| my $list4 = (|$list1, |$list2); # equivalent to previous line | ||
| say $list3; # OUTPUT: «(1, two, 3, hat, 5, 6, seven)» | ||
|
|
||
| =head1 Ecosystem | ||
|
|
||
| Where Python has pip, anaconda or uv, Raku has zef as its preferred tool for module management. | ||
|
|
||
| Where Python has PyPi, Raku has <raku.land|https://raku.land/> | ||
| as the central index of third-party L<modules|/language/modules>. | ||
| There are modules from three different ecosystems – | ||
| please stick to the I<zef> ecosystem. | ||
| (The others, I<p6c> and I<CPAN>, are deprecated when it comes to Raku.) | ||
| See L<here|https://deathbyperl6.com/faq-zef-ecosystem/> for additional information, | ||
| including guidance on how to publish your own modules. | ||
|
|
||
| =head2 Web development | ||
|
|
||
| The Raku module L<Cro|https://raku.land/zef:cro/cro> serves a similar job as Python's L<Django|https://djangoproject.com/>. | ||
|
|
||
| The Raku module L<Red|https://raku.land/zef:FCO/Red> is an object–relational mapper, similar to Django's ORM capabilities or to SQLAlchemy. | ||
|
|
||
| =end pod | ||
|
|
||
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
here I replaced two dashes (rendered as two dashes) by an en dash
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wouldn't an em-dash be more appropriate here?
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure.
Current factual usage in the docs is about evenly split between spaced en dashes and unspaced em dashes. (For the convenience of anyone wanting to check with a ripgrep: – and — )
The Wikipedia style says both are fine, just keep it consistent within a given article.
The Chicago Manual of Style and also a guide on technical writing do agree that unspaced em dashes should be used.
However, the text of the Raku docs is not being rendered via LaTeX or any other print-focused typesetting system, but instead (for most people) on the website and (for some people) in the rakudoc CLI tool.
How others do it:
Personally I now tend toward using spaced em dashes, especially because of all the padded inline code on docs.raku.org, and because of the CLI. However, it's probably best if there's a consensus, which one can then put into the styleguide.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My understanding is that the en dash has three particular use cases that call for it, and that this context isn't one of those.
https://en.wikipedia.org/wiki/Dash#En_dash says
To offset a parenthetical remark, as here, an em dash is called for. I have no opinions about the whitespace; from what you say, it sounds as if it would work better with spaces around it.
If any of those en dashes that you found in the current docs are not examples of one of the three use cases mentioned above, they probably ought to be changed to em dashes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since wikipedia says either, and the Tribune picks one, I’m happy to make that one the recommendation, add a style test for it, and then make sure we pass the test (and also add it to the styleguide) - Let’s move that into a new ticket and whatever we end up with for this PR is fine, we’ll fix it in post if we have to.