Re: Still about subroutines...
On Fri 17 Sep, Larry Wall wrote: $?fileWhich file am I in? $?lineWhich line am I at? $?package Which package am I in? @?package Which packages am I in? $?module Which module am I in? @?module Which modules am I in? $?class Which class am I in? @?class Which classes am I in? $?roleWhich role am I in? @?roleWhich roles am I in? $?grammar Which grammar am I in? @?grammar Which grammars am I in? ?sub Which sub am I in? @?sub Which subs am I in? $?sub Which sub name am I in? ?block Which block am I in? @?block Which blocks am I in? $?block Which block label am I in? Some of those may be sillier than others. But the fact that these all contain a C? is a good visual indication that they're all potentially generic in meaning when you use them in a macro. I kinda like that. Maybe there are some more... $?perl Which version of perl am I in And relating to the outside world $?osWhich operating system am I operating on I am sure there could be many more, perhaps many (all?) of the special variables could become $? variables for consistency. Richard -- Personal [EMAIL PROTECTED]http://www.waveney.org Telecoms [EMAIL PROTECTED] http://www.WaveneyConsulting.com Web services [EMAIL PROTECTED]http://www.wavwebs.com Independent Telecomms Specialist, ATM expert, Web Analyst Services
Re: Still about subroutines...
Richard Proctor wrote: Maybe there are some more... $?perl Which version of perl am I in $?parrot Which version of parrot is perl running on $?parrot_runloop Which runloop is running ? etc... And relating to the outside world $?os Which operating system am I operating on $?pid Which process ID $?pwd Which working directoy $?uid Which user ID etc... I like it. Will modules be able to add own / override existig which-variables ? example: a module that provides threads, can it somehow add a $?threadWhich tread am I in And is it possible to use these in macros aswell? Thomas Seiler
Re: Still about subroutines...
On Thu, Sep 16, 2004 at 10:35:45PM -0700, Larry Wall wrote:
Except that only one of these variables' meanings is actually
associated with subs. And I kind of like to read the C? as which.
So if we actually make use of our sigils, we get possibilities like this:
$?fileWhich file am I in?
$?lineWhich line am I at?
$?package Which package am I in?
@?package Which packages am I in?
$?module Which module am I in?
@?module Which modules am I in?
$?class Which class am I in?
@?class Which classes am I in?
$?roleWhich role am I in?
@?roleWhich roles am I in?
$?grammar Which grammar am I in?
@?grammar Which grammars am I in?
?sub Which sub am I in?
@?sub Which subs am I in?
$?sub Which sub name am I in?
?block Which block am I in?
@?block Which blocks am I in?
$?block Which block label am I in?
Some of those may be sillier than others. But the fact that these all
contain a C? is a good visual indication that they're all potentially
generic in meaning when you use them in a macro. I kinda like that.
Maybe I'm just being curmudgeonly, but is this really that useful to
have such shortcuts? I presume that there will be alternate ways to
access the same information (like maybe a special hash
(%*WHICH{'package'} and %*WHICH{'file'}) or some other suitable
abstraction (maybe there's an object that represents the program state
that you can query $*PROG.file, $*PROG.line, etc.))
But is it really worth the the secondary sigil?
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: What Requires Core Support (app packaging)
Juerd [EMAIL PROTECTED] writes:
Most worlds don't use file extensions, except for humans.
You exaggerate their lack of importance. File extensions don't matter
to most operating system *kernels*, but they are nevertheless
important for more than just Windows:
* They are of critical importance on Apache-based webservers.
* They instruct command-line tab completion for some shells. This
IMO is a biggie, and would be even bigger if more shells were
smarter. (eshell has a leg up here.)
* They matter somewhat to many *nix applications, such as Emacs and
Gimp. When I say matter somewhat, I mean that the app
understands what the extension means, and so in the absense of the
extension you have to give the app additional information to
compensate.
* They matter to most GUI file managers in the *nix world. I
personally don't use GUI file managers, but some people do.
* They matter somewhat in the VMS world, though not as much as under
Windows I think.
* They matter in the OS/2 world, if anyone is still using that. Also
DOS, with the same caveat.
* On Mac OS X the extension matters for files that don't have
filetype/creator codes attached to them yet (unless the file is
coming from a source that supplies content-type, such as from a web
server or as an email attachment, in which case the content-type
instructs the addition of filetype/creator codes).
The only OS I know of where file extensions are *totally* not used is
Archimedes. It doesn't allow them at all, from what I understand.
--
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b-()}}
split//,[EMAIL PROTECTED]/ --;$\=$ ;- ();print$/
S5: range quantifier woes
The new range quantifier syntax has been bothering me. For reference,
here's the bit of S5 that talks about it:
The repetition specifier is now **{...} for maximal matching, with a
corresponding or **{...}? for minimal matching. Space is allowed on
either side of the asterisks. The curlies are taken to be a closure
returning a number or a range.
/ value was (\d ** {1..6}?) with ([\w]**{$m..$n}) /
It is illegal to return a list, so this easy mistake fails:
/ [foo]**{1,3}
Now for the bothersome parts and some questions and some suggestions in
no particular order:
- for minimal matching the ? is too far away from the operator that it
applies to. It looks like it's doing something to the closure (and
maybe it is) Should that be [foo]**?{$m..$n} instead?
- Must the closure take the exact form of stuff in curlies? What
would these do?
$c = sub { 0..5 };
/[foo]**$c/;# error?
/[foo]**somesub/; # error?
- Is the rationale behind making [foo]**{1,3} illegal strictly to
catch the semantic error of those migrating from perl 5? Because it
certainly seems like it could be a useful thing otherwise.
- because the closure is executed first, you have to read ahead to the
end of the closure and then look back to see what you were
quantifying when trying to grok the code. This isn't such a big deal
if you just have a range, but it's a closure so all sorts of things
can be in there!
- Bringing a closure into the picture seems to put too much power in
such a simple construct. [foo]**{ destroy_the_world; 0... }
- I've always viewed the minimal matching ? as a kind of modifier on
either the quantifiers. If that illusion is to remain true in Perl6,
I'd want an optional colon [foo]*:? Whitespace would disambiguate the
modifier colon from the no backtrack or cut operator (it would
parse as [ foo ] * :? I also seem to recall already have a whitespace
disambiguation rule for ::). And if we apply this idea to the range
quantifier, that would give us something like these:
[foo]*:5# match exactly 5 times
[foo]*:{0...} # verbose [foo]*
[foo]*:{1...} # verbose [foo]+
[foo]*:{1..5} # match from 1 to 5 times
[foo]*:{[1,3,5]}# match exactly 1, 3, or 5 times
[foo]*:[EMAIL PROTECTED]# treat each element of @foo as a
# number and only match that
# many times. (same as previous
# basically)
[foo]*:{foo} # match based on the return value of foo
[foo]*:{%foo} # ???
Those last few suddenly make me want junctioned ranges, though I
don't know what I'd use them for :)
- An alternate syntax was proposed on IRC yesterday. I'm not sure if I
remember the specifics right, but the gist of it is to use a ~
character to offset the ranges, so ...
[foo]~5 # match exactly 5 times
[foo]~{0...}# verbose [foo]*
[foo]~{1...}# verbose [foo]+
[foo]~{1..5}# match from 1 to 5 times
[foo]~{[1,3,5]} # match exactly 1, 3, or 5 times
[EMAIL PROTECTED] # treat each element of @foo as a
# number and only match that
# many times. (same as previous
# basically)
[foo]~{foo}# match based on the return value of foo
[foo]~{%foo}# ???
And surely these can be made to work:
[foo]~[0...]# [foo]:[0...]
[foo]~[1,3,5] # [foo]:[1,3,5]
[EMAIL PROTECTED] # [foo]:@foo
Yes, I realize that the bag variants (e.g., /[foo]*:[EMAIL PROTECTED]/) could be
nightmarish for optimization (e.g. you can't assume monotonically
increasing values) And would minimal match mean stop when you've
reached the first number in the list or do you have to evaluate the
whole thing and literally find the minimum value? (Similar reasoning
and questions apply for the regular greedy version) These may be really
good arguments for not including that particular variant, but I don't
know that :-)
On the whole, I liked the simplicity of the old $m..$n (or even
$m,$n) and would like something just like it only without the
ambiguity of $m. I'd even suggest +$m as a disambiguating mechanism
if we weren't using + and - for character classes.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: S5: range quantifier woes
Jonathan Scott Duff skribis 2004-09-17 9:57 (-0500):
[foo]~5 # match exactly 5 times
[foo]~{0...}# verbose [foo]*
[foo]~{1...}# verbose [foo]+
[foo]~{1..5}# match from 1 to 5 times
[foo]~{[1,3,5]} # match exactly 1, 3, or 5 times
[EMAIL PROTECTED] # treat each element of @foo as a
# number and only match that
# many times. (same as previous
# basically)
[foo]~{foo}# match based on the return value of foo
[foo]~{%foo}# ???
And surely these can be made to work:
[foo]~[0...]# [foo]:[0...]
[foo]~[1,3,5] # [foo]:[1,3,5]
[EMAIL PROTECTED] # [foo]:@foo
Easier:
Variable Literal
\d~$foo \d~5, \d~1..5 # Range object or integer.
[EMAIL PROTECTED] \d~[...] # \d~any(...)
\d~foo \d~{...} # Depending on what the closure returns.
Obviously, $foo can also be an arrayref or coderef.
I think whitespace around the ~ can be made valid without making
anything ambiguous. The expression at its right side should not have
whitespace in it. If it does have whitespace, [] or {} is needed to
disambiguate.
Juerd
Re: What Requires Core Support (app packaging)
On Fri, Sep 17, 2004 at 10:46:36AM -0400, Jonadab the Unsightly One wrote: Juerd [EMAIL PROTECTED] writes: Most worlds don't use file extensions, except for humans. You exaggerate their lack of importance. File extensions don't matter to most operating system *kernels*, but they are nevertheless important for more than just Windows: * They are of critical importance on Apache-based webservers. * They instruct command-line tab completion for some shells. This IMO is a biggie, and would be even bigger if more shells were smarter. (eshell has a leg up here.) * They matter somewhat to many *nix applications, such as Emacs and Gimp. When I say matter somewhat, I mean that the app understands what the extension means, and so in the absense of the extension you have to give the app additional information to compensate. make is an important example here * They matter to most GUI file managers in the *nix world. I personally don't use GUI file managers, but some people do. * They matter somewhat in the VMS world, though not as much as under Windows I think. * They matter in the OS/2 world, if anyone is still using that. Also DOS, with the same caveat. * On Mac OS X the extension matters for files that don't have filetype/creator codes attached to them yet (unless the file is coming from a source that supplies content-type, such as from a web server or as an email attachment, in which case the content-type instructs the addition of filetype/creator codes). The only OS I know of where file extensions are *totally* not used is Archimedes. It doesn't allow them at all, from what I understand. --
Re: Still about subroutines...
On Fri, Sep 17, 2004 at 09:41:37AM -0500, Jonathan Scott Duff wrote:
: Maybe I'm just being curmudgeonly, but is this really that useful to
: have such shortcuts? I presume that there will be alternate ways to
: access the same information (like maybe a special hash
: (%*WHICH{'package'} and %*WHICH{'file'}) or some other suitable
: abstraction (maybe there's an object that represents the program state
: that you can query $*PROG.file, $*PROG.line, etc.))
Except it's not program state, which rightfully belongs in the *
namespace. It's lexical scope state, which is a compiler state, and
has nothing to do with run time, or the process state. The process in
question might not even exist yet! That's the fundamental distinction
between the * and ? namespaces.
: But is it really worth the the secondary sigil?
I believe so. We used to have __FILE__ and __LINE__, which had all
the problems of not being variables, but all the advantages of being
single tokens that can be substituted in at compile time. I'd like
to fix the one without breaking the other. I don't see any reason
to stuff a bunch of unrelated items into the same hash, other than
avoiding cluttering up a namespace, and the secondary sigil works
for that just as well. But I think cluttering up the user's mind
with a named abstraction is not terribly useful. The whichness
of C? happens subconsciously, whereas having a named hash forces
people to think, Now what was that consarned thing called again?
People want to think, I want to interpolate the line number here.
They don't want to think, I want to interpolate the line number
which is a member of this data structure for some strange reason here.
Larry
Re: Still about subroutines...
On Fri, Sep 17, 2004 at 09:25:08AM +0100, Richard Proctor wrote: : Maybe there are some more... : : $?perlWhich version of perl am I in It would be Which version of Perl am I compiled with? But $?perlversion would much clearer. I suppose the same could be said for $?subname. : And relating to the outside world : : $?os Which operating system am I operating on Again, which OS am I compiled on, or at best, which OS does the compiler think I'm compiling for, in the case of cross-compilation. : I am sure there could be many more, perhaps many (all?) of the special : variables could become $? variables for consistency. Most of the special variables are process state, not compiler state, and should live in * instead of ?. Larry
Re: Still about subroutines...
On Fri, Sep 17, 2004 at 11:59:09AM +0200, Thomas Seiler wrote: : $?parrot Which version of parrot is perl running on $?parrotversion would be which version of parrot we were compiled on. $*parrotversion would be which version of parrot we are running on. : $?parrot_runloop Which runloop is running ? Dynamically scoped, so $*parrot_runloop. : $?pid Which process ID : $?pwd Which working directoy : $?uid Which user ID All unknown to the compiler, so all * variables. : Will modules be able to add own / override existig which-variables ? At compile time, yes. : example: a module that provides threads, can it somehow add a : : $?threadWhich tread am I in That would be $*thread. Current thread is unknown at compile time. : And is it possible to use these in macros aswell? Sure. That's part of the motivation. Larry
Re: S5: range quantifier woes
On Fri, Sep 17, 2004 at 09:57:14AM -0500, Jonathan Scott Duff wrote:
: Now for the bothersome parts and some questions and some suggestions in
: no particular order:
:
: - for minimal matching the ? is too far away from the operator that it
: applies to. It looks like it's doing something to the closure (and
: maybe it is) Should that be [foo]**?{$m..$n} instead?
Yes, I felt that way too, and considered doing exactly what you
suggest, but decided that it doesn't make sense to make odd syntactic
exceptions for infrequently used constructs. We're trying to have
few random exceptions in Perl 6 than in Perl 5.
: - Must the closure take the exact form of stuff in curlies? What
: would these do?
: $c = sub { 0..5 };
: /[foo]**$c/;# error?
: /[foo]**somesub/; # error?
Yes, those are not allowed. I considered doing that too, and rejected
it for similar reasons.
: - Is the rationale behind making [foo]**{1,3} illegal strictly to
: catch the semantic error of those migrating from perl 5? Because it
: certainly seems like it could be a useful thing otherwise.
Right. The idea is that someday we could allow random lists,
perhaps even immediately if people allow it by pragma, and if
the regex engine actually supports it, which is not a sure thing.
(On the other hand, it can actually be written now as an assertion
on the number of matches of a previous $1, so there's no big pressure
to make it work, and may never be enough pressure.)
: - because the closure is executed first, you have to read ahead to the
: end of the closure and then look back to see what you were
: quantifying when trying to grok the code. This isn't such a big deal
: if you just have a range, but it's a closure so all sorts of things
: can be in there!
Yes, that's a potential problem, just as you can do all sorts of
stuff in the condition of a Cwhile statement modifier. Cultural
pressure will tend to work against that.
: - Bringing a closure into the picture seems to put too much power in
: such a simple construct. [foo]**{ destroy_the_world; 0... }
No more power than closures anywhere else in the regex. No more
power than plain old Perl outside the regex. I don't see why this
is any kind of an issue at all. The mere possibility of obfuscation
is not something Perl has ever been designed against. If anything,
the opposite is true. Expressive power can be used either for good
or ill, and Perl has generally opted for more potential goodness.
: - I've always viewed the minimal matching ? as a kind of modifier on
: either the quantifiers. If that illusion is to remain true in Perl6,
: I'd want an optional colon [foo]*:?
By that argument, the * is also a modifier and should have a colon. :-)
: Whitespace would disambiguate the
: modifier colon from the no backtrack or cut operator (it would
: parse as [ foo ] * :? I also seem to recall already have a whitespace
: disambiguation rule for ::). And if we apply this idea to the range
: quantifier, that would give us something like these:
:
: [foo]*:5# match exactly 5 times
: [foo]*:{0...} # verbose [foo]*
: [foo]*:{1...} # verbose [foo]+
: [foo]*:{1..5} # match from 1 to 5 times
: [foo]*:{[1,3,5]}# match exactly 1, 3, or 5 times
: [foo]*:[EMAIL PROTECTED]# treat each element of @foo as a
: # number and only match that
: # many times. (same as previous
: # basically)
: [foo]*:{foo} # match based on the return value of foo
: [foo]*:{%foo} # ???
:
: Those last few suddenly make me want junctioned ranges, though I
: don't know what I'd use them for :)
I see no simplifications here from the point of view of either the
parser or the human. All I see are pitfalls. *: is rather ambiguous
with existing constructs. ** is completely illegal, just as *? and
+? were before we added the minimal modifier. Again, this is a seldom
used feature, and doesn't deserve special lookahead rules to determine
that the colon doesn't mean backtracking. Also, all the other :foo
modifiers modify the things after them, not the things before them.
: - An alternate syntax was proposed on IRC yesterday. I'm not sure if I
: remember the specifics right, but the gist of it is to use a ~
: character to offset the ranges, so ...
This feature is so completely not worth Yet Another Metacharacter.
: On the whole, I liked the simplicity of the old $m..$n (or even
: $m,$n) and would like something just like it only without the
: ambiguity of $m. I'd even suggest +$m as a disambiguating mechanism
: if we weren't using + and - for character classes.
**{$m..$n} and **{$m} are precisely one character longer than +$m..$n
and +$m you are advocating. They have the mnemonic value of *
without the
Re: S5: range quantifier woes
On Fri, Sep 17, 2004 at 05:15:58PM +0200, Juerd wrote:
: Jonathan Scott Duff skribis 2004-09-17 9:57 (-0500):
: [foo]~5 # match exactly 5 times
: [foo]~{0...}# verbose [foo]*
: [foo]~{1...}# verbose [foo]+
: [foo]~{1..5}# match from 1 to 5 times
: [foo]~{[1,3,5]} # match exactly 1, 3, or 5 times
: [EMAIL PROTECTED] # treat each element of @foo as a
: # number and only match that
: # many times. (same as previous
: # basically)
: [foo]~{foo}# match based on the return value of foo
: [foo]~{%foo}# ???
:And surely these can be made to work:
: [foo]~[0...]# [foo]:[0...]
: [foo]~[1,3,5] # [foo]:[1,3,5]
: [EMAIL PROTECTED] # [foo]:@foo
:
: Easier:
:
: Variable Literal
:
: \d~$foo \d~5, \d~1..5 # Range object or integer.
:
: [EMAIL PROTECTED] \d~[...] # \d~any(...)
:
: \d~foo \d~{...} # Depending on what the closure returns.
:
: Obviously, $foo can also be an arrayref or coderef.
:
: I think whitespace around the ~ can be made valid without making
: anything ambiguous. The expression at its right side should not have
: whitespace in it. If it does have whitespace, [] or {} is needed to
: disambiguate.
Sigh. It's easy to make random suggestions. It's hard to actually
design a language in which easy things are easy and hard things
are possible. Generalized quantification is one of those things
that should merely be possible. It doesn't rate dangling syntax.
It doesn't rate a bunch of optional syntaxes. It doesn't rate a new
bunch of whitespace dependencies. It especially doesn't rate a new
metacharacter! I'm not just picking on you--everyone on this list
should be trying to pick up some of these basic underlying design
principles as we go along, and reminding each other of the design
principles rather than just going off on non-productive tangents.
Otherwise I'll just end up wasting more of my breath in the future
justifying what seem to me to be fairly obvious decisions. Mind you,
it's kind of fun to shoot down bad ideas, but it's probably bad
for me spiritually.
Larry
Re: Still about subroutines...
On Fri 17 Sep, Larry Wall wrote: : $?osWhich operating system am I operating on Again, which OS am I compiled on, or at best, which OS does the compiler think I'm compiling for, in the case of cross-compilation. Therefore should: $?os Be which operating system it is being compiled on $*os Be which operating system it is being executed on Some of the other special variables may have a similar dual personality. Richard -- Personal [EMAIL PROTECTED]http://www.waveney.org Telecoms [EMAIL PROTECTED] http://www.WaveneyConsulting.com Web services [EMAIL PROTECTED]http://www.wavwebs.com Independent Telecomms Specialist, ATM expert, Web Analyst Services
Re: Still about subroutines...
On Fri, Sep 17, 2004 at 07:35:46PM +0100, Richard Proctor wrote: : Therefore should: : : $?os Be which operating system it is being compiled on : $*os Be which operating system it is being executed on : : Some of the other special variables may have a similar dual personality. Presumably. Which presents an interesting problem, because we currently have things defined like $*PID, not $*pid. Either we have to lowercase the $* variables, or uppercase the $? variables, or decide that it's okay for them to be different. It's probably important to keep $*PID uppercase because of the way they can leak into any other namespace as $PID. The same does not hold true for $?line. On the other hand, people are used to __LINE__ already, so maybe $?LINE isn't so bad, and lights up better as a weird unit with a rectangular shape, something you might see as a funny symbol in a macro assembler. Which is more or less what it is. I originally made them lowercase because they were $=line variables and I didn't want them to conflict with POD names that are typically uppercase, and use of an C= secondary sigil for POD is a no-brainer. But that no longer applies when they have their own ssigil, or sigil2, or 2igil. I guess that would be pronounce twidgle. Larry
Re: Still about subroutines...
Larry Wall wrote: On Fri, Sep 17, 2004 at 07:35:46PM +0100, Richard Proctor wrote: : Therefore should: : : $?os Be which operating system it is being compiled on : $*os Be which operating system it is being executed on : : Some of the other special variables may have a similar dual personality. Presumably. Which presents an interesting problem, because we currently have things defined like $*PID, not $*pid. Either we have to lowercase the $* variables, or uppercase the $? variables, or decide that it's okay for them to be different. It's probably important to keep $*PID uppercase because of the way they can leak into any other namespace as $PID. The same does not hold true for $?line. On the other hand, people are used to __LINE__ already, so maybe $?LINE isn't so bad, and lights up better as a weird unit with a rectangular shape, something you might see as a funny symbol in a macro assembler. Which is more or less what it is. I originally made them lowercase because they were $=line variables and I didn't want them to conflict with POD names that are typically uppercase, and use of an C= secondary sigil for POD is a no-brainer. But that no longer applies when they have their own ssigil, or sigil2, or 2igil. I guess that would be pronounce twidgle. For that matter, what's wrong with $__ as a sigil, as in $__LINE__, et al. It combines the you can use it as a variable with the leading underscores are magic memes, and doesn't impose any wierd learning curve. =Austin Larry
Re: Still about subroutines...
On Sep 17, 2004, at 12:06 PM, Larry Wall wrote: I originally made them lowercase because they were $=line variables and I didn't want them to conflict with POD names that are typically uppercase, and use of an C= secondary sigil for POD is a no-brainer. s/uppercase/lowercase/ ? David
Re: Still about subroutines...
On Fri, Sep 17, 2004 at 03:16:24PM -0400, Austin Hastings wrote: : For that matter, what's wrong with $__ as a sigil, as in $__LINE__, et : al. It combines the you can use it as a variable with the leading : underscores are magic memes, and doesn't impose any wierd learning curve. I am unlikely to buy any use of _ as a twigil because it conflicts with user variable space. Larry
Re: Still about subroutines...
On Fri, Sep 17, 2004 at 12:19:10PM -0700, David Wheeler wrote: : On Sep 17, 2004, at 12:06 PM, Larry Wall wrote: : : I originally made them lowercase because they were $=line variables : and I didn't want them to conflict with POD names that are typically : uppercase, and use of an C= secondary sigil for POD is a no-brainer. : : s/uppercase/lowercase/ ? No, not the verbs, the uppercase nouns we see like =begin COMMENT ... =end COMMENT Larry
Re: Still about subroutines...
On Sep 17, 2004, at 12:21 PM, Larry Wall wrote: No, not the verbs, the uppercase nouns we see like =begin COMMENT ... =end COMMENT Oh, I wasn't sure, because in the Synopses you've been using propercase for =head1 POD. But maybe it's not the subjects of the header and item type verbs you're concerned with... Thanks, David
