Re: syntax for accessing multiple versions of a module
On Wed, Oct 19, 2005 at 09:12:47PM -0400, Rob Kinyon wrote: : On 10/19/05, Nate Wiger [EMAIL PROTECTED] wrote: : My concern is that we're solving problems that don't really exist in : real-world Perl usage. Are there really two competing authors of DBI? : Or, for any product, do two people really try to market SuperWidget? : No, one person just changes to SuperGadget. And with URI's, one person : gets amazon.com. Sorry, name taken. : : I think we're actually *encouraging* problems by allowing long, clashing : names. Pretty soon all DBI modules will have to start with : : use DBI:TIMB; : : Because JEFFSTER decided to upload his DBI (Derivative Binary Index) : module. : : I think it will have the opposite effect of what we're trying to avoid. : : I'm of two minds about this, in large part because I have two : experiences with the current CPAN. : : My first CPAN module was taking over PDF::Template, originally written : by DFERRANCE. Now, it's maintained by RKINYON, soon to be maintained : by RKINYON and STEVAN due to amazing contributions by AUTRIJUS (or : whatever those characters are supposed to be). : : Now, how are authorship-changes going to be handled, particularly in : the face of having two PDF::Templates out there already? Everyone is : disambiguating their modules with PDF::Template-DFERRANCE vs. : PDF::Template-JRANDOM. Now, they cannot upgrade to my latest feature : because that requires changing every place they had hard-coded : DFERRANCE. Or, will the package system map PDF::Template-DFERRANCE to : PDF::Template-RKINYON? I suspect you just use PDF::Template and have some other way of instructing the library system about your general policy preferences, so that anywhere that uses PDF::Template on your project uses the same one by default. : The second experience is one I'm going through right now. I was adding : a feature to Tree:Simple a few weeks back and realized that it needed : to be gutted to do what I needed it to do. With the encouragement of : the author, I rewrote it completely. My development name for the : distro is Forest, but I have Tree and Tree::Binary as the packages. : (Yeah, it's a math joke.) : : Except, there's two problems with that - Tree is a TLN (top-level : namespace) with a lot of unrelated distros beneath it. And, Tree is : owned by someone else, but that person hasn't updated Tree in 6 years. : And, Tree::Binary is owned by the same guy who owns Tree::Simple. : : How is that going to work in P6? (For the record, I still haven't : figured out what I'm going to do yet. Check Perlmonks for the SOPW in : a few minutes.) We probably need some meta-information somewhere about which names claim to offer the same interface, and which are just accidental collisions. That part isn't terribly well defined yet. Larry
Re: syntax for accessing multiple versions of a module
On Wed, Oct 19, 2005 at 03:58:17PM -0700, Nate Wiger wrote:
: Larry Wall wrote:
: This is one of those accomodations to the real world, like everyone
: agreeing on a standard URI format. We're really trying to keep
: these module names close to what you'd see as the name of, say,
: the corresponding .rpm file. These modules have to have names that
: work outside of Perl as well as inside, and {...} isn't going to fly
: in general.
:
: My concern is that we're solving problems that don't really exist in
: real-world Perl usage. Are there really two competing authors of DBI?
: Or, for any product, do two people really try to market SuperWidget?
: No, one person just changes to SuperGadget. And with URI's, one person
: gets amazon.com. Sorry, name taken.
:
: I think we're actually *encouraging* problems by allowing long, clashing
: names. Pretty soon all DBI modules will have to start with
:
:use DBI:TIMB;
:
: Because JEFFSTER decided to upload his DBI (Derivative Binary Index)
: module.
:
: I think it will have the opposite effect of what we're trying to avoid.
I think there can be some kind of community metainformation that sets
defaults appropriately. And if not, the site/project can certainly
establish defaults. On the other hand, a lot of projects do simply
want to specify the version and author explicitly eveyr time,
and they'd rather tweak it by hand (or by script) if they want to
change it, since then at least they know when they need to rerun the
regression tests.
But we put the author last partly because we want to encourage people
not to use that if they don't need to. And the community may choose
to just stick with version numbers and names, and then author gets
retargeted as any kind of differentiator you need for occasional but
not regular use.
: : Not trying to rant (really), but one thing that is starting to bother me
: : about Perl 6 is that there's lots of changes that require special syntax
: : for one specific instance. It's making it really really difficult to
: : remember or generalize, two things that I thought we were trying to
: improve.
:
: Well, you're painting with kind of a broad brush here. If you can
: point to other areas where we could usefully generalize without
: getting too abstract for newbies, I'd be delighted to hear them.
:
: The method syntax is starting to make my head spin, for one.
You mean the pattern matching characters on the dispatcher? Or the
method declaration syntax? Which part is making your head spin?
: Many things, as a longtime Perl 4/5 programmer and CPAN goon, are
: problematic because we're reusing established operators for completely
: different ideas. From a design standpoint, I feel it's going to hamper
: adoption of the language. People don't have the time (or interest) to
: re-learn that much language, when Perl 5 works fantastic for 95% of
: the cases.
But now you're changing your complaint. If we apply your previous
complaint to this, in many cases we're doing that redesign *precisely*
to fix the thing you're complaining about--too many special cases for
one instance...only it's Perl 5 that's the culprit here, not Perl 6.
In Perl 6 we've greatly regularized the special cases and reserved
most of the special syntax for common cases. Or more precisely, for
what we *suspect* will be common cases in the future, not necessarily
the common cases in the past.
Larry
Announcing Amber for Parrot 0.3.0 (Struggle)
I have released Amber for Parrot version 0.3.0 (Struggle): Downloads: http://xamber.org/download.html Release history: http://xamber.org/history.html Project home page: http://xamber.org/index.html Amber for Parrot is an Eiffel-like scripting language for the Parrot Virtual Machine. Changes since version 0.2.3a: - include directive allows functionality to be included from Parrot Intermediate Representation (*.pir) files - load directive allows functionality to be loaded from Parrot Bytecode (*.pbc) files - Iterator 'each_line' of class FILE now smoothly handles a file with no newline at the end of the last line - The can't find feature error message now shows the source location of the failing call - Added kernel class CCLASS which enumerates character classes that can be searched for within strings (uppercase, lowercase, alphabetic, hexadecimal, whitespace, punctuation, etc) - Slurpy arguments implemented, which allows the caller of a routine to pass a variable number of arguments, which are collected (slurped) into the final formal argument if it is followed by elipsis (...) - Routine bodies may be marked external parrot which means that the implementation will be dynamically loaded from some Parrot Bytecode or Parrot Dynclasses library. - Added feature 'type_id' to class ANY - Renamed feature 'isa' to 'is_a' in class ANY - Added conversions between INTEGER, CHARACTER, BOOLEAN, STRING - Added and reorganised many kernel class features as part of testing three alternative kernel class implementations. - Capitalised 'Current', 'Result', 'Void', 'True' and 'False' to make SmartEiffel 2.2 beta 3 happy - Various bug fixes - Estimated progress towards release 1.0: language constructs 42%, libraries 3%, documentation 3%, robustness 3% The three alternative kernel class implementations referred to above are: (1) Wrapper around the standard Parrot PMC classes, (2) Custom Amber PMC classes, and (3) Custom Amber PIR classes. The default kernel for this release is still (1). However, my experimentation showed that (2) provides advantages in terms of performance and functionality. Up to now the kernel library was really just a stub to interact with the Parrot runtime and get things working. The major development focus for the next release of Amber for Parrot will be to implement enhanced kernel libraries as Custom Amber PMC classes. Roger Browne
new sigil
I don't know how long this EuroOSCON net is going to stay up, so I'll be
brief. I think we're having a new class sigil. Where we've been
writing ::T, that will revert to meaning an existing class T that
we just might not see the declaration of for dynamic reasons. Instead,
the new sigil is the cent sign, so ::T is now written ¢T instead.
In addition, it doesn't automatically bind to T like we were making ::T
do, so you have to use it consistently:
sub sametype (¢T $x, ¢T $y) {...}
Within a larger scope, you can always alias, though:
::T := ¢T;
Larry
Re: new sigil
Larry Wall skribis 2005-10-20 7:56 (-0700): the new sigil is the cent sign, so ::T is now written ¢T instead. 1. What does it look like? I've never used a cent sign, and have seen several. 2. How can it be typed with X character composition, vim's digraphs and major international keyboards? 3. What is the ASCII equivalent? 4. Why not ^, which is available? 5. Why is the sigil needed? Pairs do well without, too. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: new sigil
Juerd skribis 2005-10-20 17:03 (+0200): 3. What is the ASCII equivalent? Suggestion: 1c 'c' is an invalid character in numbers, and currently only numbers can begin with a digit. 1cFoo The 1 provides an extra visual hint of the cheapness of the class. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: new sigil
Juerd skribis 2005-10-20 17:03 (+0200): 4. Why not ^, which is available? Or the euro symbol, which also has a C in it. It doesn't always have to be American ;) It's in iso-8859-15, which is compatible enough with iso-8859-1 to support ¥ and both « and ». (I hope those turn out as Y, and 's pretty equivalents.) Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: new sigil
On Thu, Oct 20, 2005 at 07:56:09AM -0700, Larry Wall wrote: I don't know how long this EuroOSCON net is going to stay up, so I'll be brief. I think we're having a new class sigil. Where we've been writing ::T, that will revert to meaning an existing class T that we just might not see the declaration of for dynamic reasons. Instead, the new sigil is the cent sign, so ::T is now written ¢T instead. Looking at my U.S. English keyboard, I don't have a cent sign. I don't think a sigil that can't be typed (or easily typed) is something that should be used. Steve Peters [EMAIL PROTECTED]
Re: new sigil
On 10/20/05 10:56 AM, Larry Wall wrote: I don't know how long this EuroOSCON net is going to stay up, so I'll be brief. I think we're having a new class sigil. Where we've been writing ::T, that will revert to meaning an existing class T that we just might not see the declaration of for dynamic reasons. Instead, the new sigil is the cent sign, so ::T is now written ¢T instead. How about an ASCII version and/or a class() built-in that means the same thing? ¢T == class(T) == ?T ^ | Dunno what to put there -John
Re: new sigil
On Thu, Oct 20, 2005 at 05:17:57PM +0200, Juerd wrote: Juerd skribis 2005-10-20 17:03 (+0200): 4. Why not ^, which is available? Or the euro symbol, which also has a C in it. It doesn't always have to be American ;) It's in iso-8859-15, which is compatible enough with iso-8859-1 to support ¥ and both « and ». (I hope those turn out as Y, and 's pretty equivalents.) I think that you can type the above characters on some systems, but others, like the one I'm using right now, I can't even copy and paste those characters in. I also know that on Windows, those characters may be available, but, for the typical user, these characters are annoyingly impossible to write. For example to type the yen symbol, its an ALT-0165 and requires the numeric keypad. The idea of punishing programmers who choose to use certain operating system or locales just doesn't seem right to me. Steve Peters [EMAIL PROTECTED]
Re: new sigil
On Thu, Oct 20, 2005 at 10:21:53AM -0500, Steve Peters wrote: : On Thu, Oct 20, 2005 at 07:56:09AM -0700, Larry Wall wrote: : I don't know how long this EuroOSCON net is going to stay up, so I'll be : brief. I think we're having a new class sigil. Where we've been : writing ::T, that will revert to meaning an existing class T that : we just might not see the declaration of for dynamic reasons. Instead, : the new sigil is the cent sign, so ::T is now written ¢T instead. : : Looking at my U.S. English keyboard, I don't have a cent sign. I don't : think a sigil that can't be typed (or easily typed) is something that : should be used. Part of the reason for picking it is that we want to discourage people from using it unless they're experts. But it's in Latin-1, so it's not going to be any harder than the other Latin-1 characters we've used to type. Larry
Re: new sigil
Steve Peters skribis 2005-10-20 10:32 (-0500): The idea of punishing programmers who choose to use certain operating system or locales just doesn't seem right to me. All non-ASCII operators have ASCII equivalents: ¥ Y « » I'm sure ¢ will have its equivalent too. (It's ^KCt in vim, btw) Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: new sigil
On Thu, Oct 20, 2005 at 10:32:14AM -0500, Steve Peters wrote: : The idea of punishing programmers who choose to use certain operating system : or locales just doesn't seem right to me. That's why we provide ugly ASCII workarounds for all of them. We just haven't decided what the appropriate ugly ASCII workaround for ¢ should be. Larry
Re: new sigil
More info. ¢T is a scalar variable just like $T, but enforces a class view, so you can use it as a class parameter, and pass any object to it, but only access the classish aspects of the object. The only other big difference is that you can use it in the class syntactic slot, so it's legal to say ¢T $x where it would be illegal to say $T $x. Larry
Re: new sigil
On 10/20/05 11:37 AM, Larry Wall wrote: On Thu, Oct 20, 2005 at 10:32:14AM -0500, Steve Peters wrote: : The idea of punishing programmers who choose to use certain operating system : or locales just doesn't seem right to me. That's why we provide ugly ASCII workarounds for all of them. We just haven't decided what the appropriate ugly ASCII workaround for ¢ should be. So...no joy on the class(T) builtin/macro/whatever? Does it look too much like a cast? -John
Re: new sigil
On Thu, Oct 20, 2005 at 08:45:25AM -0700, Larry Wall wrote: : More info. ¢T is a scalar variable just like $T, but enforces a : class view, so you can use it as a class parameter, and pass any : object to it, but only access the classish aspects of the object. And a nice side effect of that is that declaring the invocant ¢T doesn't commit to whether you are thinking in a class-based or prototype-based model. And you wouldn't care until you got down to a .clone or a .bless. Larry
Re: new sigil
On Thu, Oct 20, 2005 at 11:46:30AM -0400, John Siracusa wrote: : On 10/20/05 11:37 AM, Larry Wall wrote: : On Thu, Oct 20, 2005 at 10:32:14AM -0500, Steve Peters wrote: : : The idea of punishing programmers who choose to use certain operating system : : or locales just doesn't seem right to me. : : That's why we provide ugly ASCII workarounds for all of them. We just : haven't decided what the appropriate ugly ASCII workaround for ¢ should be. : : So...no joy on the class(T) builtin/macro/whatever? Does it look too much : like a cast? It looks too much like a class declaration, and we're not declaring a class. We're just declaring a variable that holds something that does class. Larry
Re: new sigil
Larry Wall skribis 2005-10-20 8:46 (-0700):
On Thu, Oct 20, 2005 at 05:35:10PM +0200, Juerd wrote:
: I'm sure ¢ will have its equivalent too.
c| or C| maybe.
But
sub c { ... }
sub d { ... }
if $foo eq c|d { ... }
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: new sigil
On 10/20/05, Larry Wall [EMAIL PROTECTED] wrote:
Another thing I didn't mention is that that binds both the variable
and its class. But the $ variable is of course optional after the
type, so you could just write that
sub sametype (¢T, ¢T) {...}
if you don't actually care about $x and $y. Basically, ¢T captures
the type of the associated scalar in any lvalue or declarative context,
whether or not hte scalar itself is captured.
So it's a type position thing if it can be. Good. (I wonder if,
since it's allowed in term position, we will come up with ambiguities)
How about this:
sub foo(c|T $x) {
my sub util (c|T $in) {...}
util($x)
}
Is that c|T in util() a new, free type variable, or am I asserting
that the type of util()'s argument must be the same type as $x?
Luke
Re: new sigil
Schneelocke skribis 2005-10-20 18:00 (+0200): Would c! be an option? In current Perl 6: Yes, because infix ! does not exist. But several people want ! to be a chainy none() constructor, and this would destroy a dream. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: new sigil
On Thu, Oct 20, 2005 at 05:35:10PM +0200, Juerd wrote: : I'm sure ¢ will have its equivalent too. c| or C| maybe. Larry
Re: new sigil
On 10/20/05, Juerd [EMAIL PROTECTED] wrote: Schneelocke skribis 2005-10-20 18:00 (+0200): Would c! be an option? In current Perl 6: Yes, because infix ! does not exist. But several people want ! to be a chainy none() constructor, and this would destroy a dream. You seem to be forgetting that we do have the longest token rule. So, the only way this destroys a dream (and likewise, the only way c| doesn't work), is if you have the poor package or class name c and you insist on writing c|d or c!d without spaces. Still, if you'd like to make a suggestion instead of just telling us why our ideas don't work in very specific circumstances, feel free. Luke
Re: new sigil
On Thu, Oct 20, 2005 at 08:55:46AM -0700, Larry Wall wrote:
On Thu, Oct 20, 2005 at 05:53:00PM +0200, Juerd wrote:
: Larry Wall skribis 2005-10-20 8:46 (-0700):
: On Thu, Oct 20, 2005 at 05:35:10PM +0200, Juerd wrote:
: : I'm sure ¢ will have its equivalent too.
: c| or C| maybe.
:
: But
:
: sub c { ... }
: sub d { ... }
:
: if $foo eq c|d { ... }
Other suggestions welcome.
I don't know ... since we're still using ::T for classy things, I'd
kind of like to see something with a : in it. I also get the feeling
that these are type/class placeholders, so I wouldn't mind a ^ either.
Here are some suggestions:
:$T
:^T
^^T
:T
$::T
$:T
[T] # these next 3 don't evoke variable as much as
T # parametric type (ala C++)
(T)
And yes, I know several of those are already taken. I'm suggesting
that we at least think about reassigning them.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: syntax for accessing multiple versions of a module
Larry Wall wrote: I think there can be some kind of community metainformation that sets defaults appropriately. And if not, the site/project can certainly establish defaults. On the other hand, a lot of projects do simply want to specify the version and author explicitly eveyr time, and they'd rather tweak it by hand (or by script) if they want to change it, since then at least they know when they need to rerun the regression tests. I think it's a laudable idea in theory, but not necessarily application. I've done quite alot of Perl programming, and I've never run into this personally. Who has? (Really, I'm being serious.) Are there really multiple modules sharing interchangeable interfaces? Or instances where we want to allow the same name to mean different concepts depending on the author? There's no logical difference between: use DBI:TIMB use DBI:JEFFSTER And: use TIMB::DBI use JEFFSTER::DBI Anyways, I don't like the idea of people being able to upload identically named modules to CPAN. I think that's a very bad idea. See Rob Kinyon's message. You mean the pattern matching characters on the dispatcher? Or the method declaration syntax? Which part is making your head spin? Yes. :-) But now you're changing your complaint. If we apply your previous complaint to this, in many cases we're doing that redesign *precisely* to fix the thing you're complaining about--too many special cases for one instance...only it's Perl 5 that's the culprit here, not Perl 6. In Perl 6 we've greatly regularized the special cases and reserved most of the special syntax for common cases. Or more precisely, for what we *suspect* will be common cases in the future, not necessarily the common cases in the past. And I think that's actually my problem right now. Back when Perl 6 design started in 1999/2000 (and we wrote all the original RFC's), we were careful not to throw the entire enchilada out. Perl 5 is enormously successful because is solves *actual* problems, not *suspected* problems. And, it shares alot with other languages people know and use. Right now the design is going towards something that's very very un-Perlish from a syntax standpoint. Sure, the philosophy's there, but there are fewer and fewer things Perl 6 shares with Perl 5 (or other widely-used languages). And there are many superflous changes, such as using $0 as the first match, where every other accepted regex engine/program on the planet uses 1. Anyways, I'm not trying to rant or be obstructive (really); I am simply trying to provide a slightly different perspective on a few things. -Nate
Y [was: Re: new sigil]
On Thu, 20 Oct 2005, Juerd wrote: All non-ASCII operators have ASCII equivalents: ¥ Y « » Speaking of which the advantage of, say, « over is that the former is _one_ charachter. But Y, compared to ¥, is one charachter only as well, and is even more visually distinctive with most fonts I know of, afaict, so is there any good reason to keep the latter as the official one?!? Michele -- Commander Helena Braddock: So, where is everybody? Melanie Ballard: Yeah, Friday night, the whole place should be packed. A whole twelve hours before sun up and there's money to burn, whores to fuck and drugs to take. - Gosts of Mars (2001)
Re: new sigil
On Thu, 20 Oct 2005, Larry Wall wrote:
: c| or C| maybe.
[snip]
: if $foo eq c|d { ... }
Other suggestions welcome.
| maybe? And what will we make | do?
Michele
--
Se non te ne frega nulla e lo consideri un motore usa e getta, vai
pure di avviatore, ma e' un vero delitto. Un po' come vedere un
cavallo che sodomizza un criceto!!!
- Cesare/edizioni modellismo sas in it.hobby.modellismo
Re: new sigil
What about something like:
c\
Then you get
sub sametype (c\T $x, c\T $y) {...}
Not exactly pretty though. c\T
Actualy i think ^ might be my favorite so far.
sub sametype (^T $x, ^T $y) {...}
--
Eric
Re: new sigil
On Thu, 2005-10-20 at 10:32 -0500, Steve Peters wrote: The idea of punishing programmers who choose to use certain operating system or locales just doesn't seem right to me. Haven't they already acclimated to the punishment of those operating systems already? -- c
Re: syntax for accessing multiple versions of a module
On 10/20/05, Nate Wiger [EMAIL PROTECTED] wrote: Larry Wall wrote: I think there can be some kind of community metainformation that sets defaults appropriately. And if not, the site/project can certainly establish defaults. On the other hand, a lot of projects do simply want to specify the version and author explicitly eveyr time, and they'd rather tweak it by hand (or by script) if they want to change it, since then at least they know when they need to rerun the regression tests. I think it's a laudable idea in theory, but not necessarily application. I've done quite alot of Perl programming, and I've never run into this personally. Who has? (Really, I'm being serious.) Are there really multiple modules sharing interchangeable interfaces? Or instances where we want to allow the same name to mean different concepts depending on the author? Please see http://www.perlmonks.org/?node_id=501496 for more on the issue of names. My Tree module and Schwern's Tree distro have almost zero interface compatibility. They both represent N-ary trees, except mine exposes the tree interface and Schwern's is just a OO interface for a hash implemented as a tree. My module is descended from Tree::Simple, except ::Simple almost never is. The same thing goes for my version of Tree::Binary and Stevan Little's. Two completely different interfaces, but here we're solving the same problem. The major difference between mine and his is that mine inherits from my Tree whereas his is an independent module. This means that adding transparent persistence (which is what my rewrite does) to his module is a bit of a bear. Hence, you might want to use RKINYON's Tree::Binary over STEVAN's Tree::Binary. Or, what should I call mine? (This is a real question - if you have any suggestions, please let me know!) There's no logical difference between: use DBI:TIMB use DBI:JEFFSTER And: use TIMB::DBI use JEFFSTER::DBI No, this isn't any good, either. I took over DFERRANCE's PDF::Template implementation. He has nothing to do with it anymore. So, DFERRANCE::PDF::Template now becomes RKINYON::PDF::Template? Or, does RKINYON now maintain something in the DFERRANCE namespace? What on earth does the name DFERRANCE provide, except for an additional layer of confusion. Anyways, I don't like the idea of people being able to upload identically named modules to CPAN. I think that's a very bad idea. See Rob Kinyon's message. I think you misinterpreted my message. My point is that uploading things with the same name is a good plan, but it has to be thought through, especially given the points I raised. But, I very much agree that it should happen. I'd like to propose a slight shift in emphasis. I think that more focus needs to be made in project-wide or namespace-wide disambiguation and module aliasing. If I was able to say in my CP6AN distro that I depend on DBI:2.05-:cpan-TIMB and that I'm going to call it DBI, then all the files in my distro should automatically have that alias built in. This means that anyone wanting to use DBI:cpan-JRANDOM in their code can alias it as DBI on a project-wide basis, yet still be able to use my distro and everything be ok. The important thing here, I think, is that while aliasing package names is a lexical action, there can be a larger lexical scope. It may be that we need the concept of a Project, along with Module, Package, Class, and Role. This way, the Project states Whenever you load a file that matches the criteria below, apply the following lexical _stuff_. Rob
[perl #37455] make hello fails
[EMAIL PROTECTED] - Di 18. Okt 2005, 02:51:18]: This bug is a regression, 'make hello' works with release 0.3.0 (r9297). Just some observations. When running 'make test' the command ./parrot -o examples/pasm/hello.o examples/pasm/hello.pbc fails to create examples/pasm/hello.o. Instead a file with the name 'exex_output.o' is generated. It looks like the name of the output file is expected to be in REG_STR(0), but isn't. So the default file 'exec_output.o' is used. Sell line 116 of src/exec.c. Whem copying 'exec_output.o' to 'examples/pasm/hello.o' manually, then 'make test' produces 'examples/pasm/hello'. However when trying to execute that executable, I get a segmentation fault. CU, Bernhard -- /* [EMAIL PROTECTED] */
Re: new sigil
Speaking briefly, Unicode is the way of the future, and even many modern systems have strong support for it. Perl 6 is a language of the future plus present, not of the past, and shouldn't be limited by things that are only issues for older systems while even then being easy to work-around on them. I say that we should exploit all the Unicode characters reasonably possible to make for a more elegant language, and any tools currently behind will catch up before long. In this case, I support the use of any international currency symbol for use as Perl sigils and/or operators as appropriate. Eg, we already use $ (dollar; unicode=0024; utf8=24) and ¥ (yen; unicode=00A5; utf8=C2A5), and I suggest that the next best one to exploit is ¤ (euro; unicode=20AC; utf8=E282AC), and the next best is £ (pound; unicode=00A3; utf8=C2A3). In my experience, the ¢ (cent; unicode=00A3; utf8=C2A3) is no harder to type than either of those. In some cases, typing a ¢ is easier than most of those characters. On a Macintosh keyboard, typing opt-4 will get a ¢ as shift-4 gets a $. For that matter, Macintosh keyboards and their 'option' key allows one to type twice as many characters without entering special codes or using an input palette as other keyboards having only a 'shift' key do. So in that respect, if you want a sigil that is meant to be discouraged due to being harder to type, then ¢ may be a worse choice than some other options. On the other hand, if you want to use the ¢ due to its being conceptually tied to $, that they are different units of currency meant to be used together, then the ¢ is fine. All this being said, if you explicitly want to have ASCII alternatives for all Unicode characters being used, then I suggest it is best to keep the use of Unicode characters mainly in operators, because those are always surrounded by whitespace and can easily be substituted for latin words. Whereas, because sigils are always right next to ordinary word characters, I suggest that they should always be ASCII characters, or that the ASCII equivalent should not contain any word characters. My impression is that sigils containing alphanumerics just look wrong. Perhaps a solution here for an ASCII equivalent is something combining the $ and something else. How about this twigil, which combines '::' and '$': :$: Does that conflict with anything? -- Darren Duncan
Re: [svn ci] Debug segment updates
Jonathan Worthington [EMAIL PROTECTED] wrote: What's left? Making this work for when you .include files in PIR. Which means monkeying with the lexer and IMCC. shudder I've done it and it's available to play with. I'll admit now that, despite having covered quite a bit of the IMCC codebase while working out the best way to do this, I'm still no expert on how it works so this may not be perfect. Anyway, an example of the kinda thing that now works:- $ cat crash1.pir # Example .sub main :main _test() .end .include crash2.pir .sub _test2 _does_not_exist() .end $ cat crash2.pir .sub _test _test2() .end $ parrot crash1.pir Name '_does_not_exist' not found current instr.: '_test2' pc 24 (crash1.pir:9) called from Sub '_test' pc 17 (crash2.pir:2) called from Sub 'main' pc 7 (crash1.pir:3) Note how the correct files are named in the backtrace now; before it would always say crash1.pir no matter what file it was in. Also fixed some warnings, plus a bug that pre-dated my debug seg work that meant sometimes a file didn't get a debug segment added to it.. Happy debugging, Jonathan
Re: $1 change issues [was Re: syntax for accessing multiple versions of a module]
On 10/20/05, Nate Wiger [EMAIL PROTECTED] wrote: Luke Palmer wrote: Okay, I may still be missing your point, so let me try to summarize just to be sure we're on the same page: You say that the thing that is going to hinder migration to Perl 6 is the fact that it's different from Perl 5. Intentionally trite oversimplification. Oh, sorry. I was going to expand on that, but then the direction of my message changed and I forgot to. Sorry for my overall hostile tone. I'll try to conduct myself civilly for the rest of the argument. Our target audience is only somewhat from a Perl 5 background. People from Java, from Python, from C, and even just starting to program will be learning Perl 6, and they would rather have all the language be zero-based, rather than most of it being zero-based except for $1, $2, etc. (you were complaining about special exceptions if I recall). Every regex engine in every language uses $1 or \1. This includes Java, JavaScript, C, PHP, Python, awk, sed, the GNU regex libs, etc. Somehow other languages seem ok with this, because it's a widely-used convention. Yeah, well, every other regex engine on the planet uses [] for character classes, no other regex engine uses for subrules, no other regex engine uses a match object or nested capture numbering. Perl 6's patterns are _not_ regexes anymore. But I doubt that we won't be imitated, because the new regexes are way better than the old ones. Breaking cruft for a reason and all that. And you don't have to answer, but have you actually programmed in Java or Python? You seem to be speaking for alot of programmers. Yes, yes. You seem to be speaking for a lot of programmers, too. We have to, for if we didn't try, we probably wouldn't be good language designers. The reason I'm dismissing you as a complainer is because of your broad field of attack. You say that the method syntax is starting to make [your] head spin. Well, what about it is making your head spin? The method: infix:+ stuff makes no sense to me, but I don't want to dwell on it. Ahh, grammatical categories. You may already know this, but let me try to explain. The category:symbol stuff is our way of letting the user hook into the parser in common ways without them having to go and explicitly change the grammar of the language. Generally, that syntax has nothing to do with it being a method. Whatever you see inside the quoter after the category is always introducing (or defining an additional meaning for) a token, which I guess is why it's quoted. The fact that we use . instead of - (like every other language on the planet)? You're using my argument for me - thanks. See above. Huh? So you want to go back to Perl 5's arrow? *Anybody* coming to Perl 6 from some non-Perl 5 language is going to be more comfortable with dot. [1] Which will be, what, eight hours for a Perl 5 programmer? Have you ever spent a month trying to learn, oh, say, Haskell? Because people do that, too. There are more components to this that just the learning time for one person. There are project teams, sustaining engineering for existing projects, etc. And that's not even counting management tape. Real-world, profitable computing is a big, ugly, nasty beast. Which is why we're going to great lengths to make sure that your Perl 5 code and your Perl 6 code can run together. use perl5:DBI; The transition to Perl 6 doesn't mean that /usr/bin/perl is going to change to version six under your feet and all your code will break. If Perl 6 is going to be successful, this means it must change the fewest key things with the most benefits. This may mean some things that aren't quite perfect still don't get changed. (It also means lots of new stuff can still be added - I'm just talking change.) It sounds like you want a backwards-compatible change. From the outset we knew that this wasn't our goal. Perl 5 is full to the brim with syntax, and there's pretty much nowhere we can add anything, and there's tons of cruft that we had to get rid of. Consider Perl 6 to be a derivative, not an extension, of Perl 5. Luke
Re: syntax for accessing multiple versions of a module
On 10/20/05, John Adams [EMAIL PROTECTED] wrote: Then the target audience is specifically not people coming from a shell scripting background, who are quite used to the idea that $0 is different from $1 in a way in which $1 is not different from $2. Correct? But $1 in Perl 5 wasn't the same as $1 in a shell script. The shell scripters seemed to be able to substitute $ARGV[0] for $1 pretty well nonetheless. Luke
Re: syntax for accessing multiple versions of a module
From: Luke Palmer [EMAIL PROTECTED] But $1 in Perl 5 wasn't the same as $1 in a shell script. Sure--but that's not what I said. I'm all for breaking things that need breaking, which is why I keep my mouth shut most of the time--either I see the reason or I suspect (that is, take on faith, which is okay by me) there's a reason I don't see or fully understand. I'm just not seeing a compelling reason for this one, and a pretty good reason not to do it: I'm not aware offhand of any other place where $0 is used in regex matching, and several of the languages which you point out are zero-based in other places are not zero-based in regex matching.
Re: new sigil
On Thu, Oct 20, 2005 at 05:03:27PM -0400, Rob Kinyon wrote: On 10/20/05, Steve Peters [EMAIL PROTECTED] wrote: I have some serious concerns about using Latin-1 sigils within Perl 6 and the ASCII multi-character aliases. Am I not understanding something that I should see this as an advantage? I had the same concern a few months back. I've come to see the light in this fashion: 1) more and more Perl programmers come from non-English countries. Heck, the Pugs effort is at least 50% non-US, if not more. None of the are on US soil and very few of the leaders are US citizens. Surely you aren't suggesting that these non-English speakers do not have access to the ASCII (or EBCDIC) character sets for their editors, are you? 2) More and more of us are programming with internationalization (i18n) in mind. Just recently, I had to edit french text within the templates of an app I work on. If you haven't already, you will be doing so in the near future, within the next 3 years. I have worked on an app that needed to work with English (US and GB), German, and Japanese. I do not, however, remember having to write my code in anything but ASCII. 3) Every editor (with very few exceptions) can display Latin-1 and, with a few more exceptions, can input Latin-1. If your favorite editor cannot, then that's something to bring up with the authors. As I mentioned earlier, most programmers in a corporate environment have limited access to system settings. Changing them in some cases can cause reprimands or dismissal. Systems are often set up with the bare minimum of locales and character sets necessary to do the job. Also, you have to deal with the situations where programmers are connecting to *nix servers through a variety of Windows-based XWindows servers (Exceed, Cygwin, etc.) complicates what character sets are available immensely. Also, what settings changes do I need to make to get Latin-1 on enter any operating system or editor here? Welcome to your documentation nightmare! In Perl 5, we have a nearly impossible time keeping track of where Microsoft has put their free compiler tools. Now multiply that by the number of Linux distributions, BSD distributions, and various other operating systems. Don't forget different versions will do it differently, and have documentation in different places. Some of the documentation won't even be available on the Internet, so Perl 6 would need to reference it in some way. Are you beginning to get the magnitude of the documentation problem? Windows ... yeah. As you pointed out, the old joke goes Doctor, it hurts when I use Windows . . . then, don't use Windows! Well over 95% of the desktop computers in a corporate environment are using Windows. If you are suggesting Perl 6 ignores Windows, then we should all start writing Perl 6's obituary. This sort of attitude does nothing to advance Perl 6. With the availability of dual-booting into FreeBSD/Linux (given the near-complete migration of all the necessary Office products) and both gvim and emacs having been successfully ported to WIn32, there is a way to do it. gvim on WinXP will do all Latin-1 charset with the vim keys. (I don't know about emacs, but I'd be shocked if it didn't.) If your IT department's policy is rigid, a quick discussion with your manager's manager will solve that problem immediately. Or, the cost of a few lunches with your favorite IT person will exempt your computer from the nightly audit. ($50 goes a long way ...) Again, I'd prefer not to be fired. Everything you have written above is not an option for the majority of the programmers out there. Also, not to helpful if you write your programs in TSO on an IBM mainframe. Personally, I plan on using every single Latin-1 operator I am given access to. All the cool kids will ... Famous last words have never been more finely spoken. Ignoring Windows and other environments without ready access to Latin-1 seems like a horrible mistake to me. While the cool kids are playing with their Latin-1 sigils, programmers in corporate environments where Latin-1 isn't available will start writing their new systems in Java, Ruby, or .NET. Steve Peters [EMAIL PROTECTED]
Re: new sigil
On 10/20/05, Steve Peters [EMAIL PROTECTED] wrote: As I mentioned earlier, most programmers in a corporate environment have limited access to system settings. And in those kinds of corporate environments, you're not going to be working with any code but code written in-house. Which means that nobody is going to be using Latin-1, and everyone will be using the ASCII synonyms. What's the problem? Please, just use the ASCII synonyms. We've argued over the unicodity of Perl 6 many times; you're certainly not the first with this concern. The result every time is: Unicode will be in Perl 6, nobody is forcing you to use it. Luke
Re: new sigil
Schneelocke skribis 2005-10-21 1:07 (+0200): I think the reason why Larry proposed the ¢ is much simpler - it looks a bit like a c, which one could associate with class, similar to how $ looks like S (scalar) and @ looks like a (array). :) And how % looks like h (hash). I dislike things like $calar and @rray, and now some people will use ¢lass in examples. Please let that the sigil looks like a certain leter not be a reason. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: new sigil
On Thu, Oct 20, 2005 at 04:23:44PM -0600, Luke Palmer wrote: On 10/20/05, Steve Peters [EMAIL PROTECTED] wrote: Like the old joke goes Doctor, Doctor, it hurts when I try to type a Latin-1 character. So don't try to type Latin-1 characters! Instead, many programmers will to use the ASCII equivolents that will require additional keystrokes. You mean additional keystroke. We haven't yet developed any ASCII equivalent that takes more than two characters. For most cases, the ASCII equivalents are easier to type than the Latin-1 versions. However, being a Perl 6 programmer myself, I still use the Latin-1 versions because I like how they look and feel better. But nobody is forcing you to do the same. But I may have to support your code. That's the issue. The one thing you have to worry about is if you use an editor that doesn't support Latin-1 to read somebody else's code. However, many many popular editors are capable of doing this, and any editor that doesn't probably will soon. We've been over this and over this. I'd say a lot more editors support ASCII than Latin-1. Also, you are also assuming that programmers have control over what tools they have available, and have the ability to upgrade whenever they wish. I've found this to be very far from reality. I understand that the ability to process the code as Unicode is an important feature of Perl 6. There is a big difference between allowing it and requiring it. Writing off a large number of editors, and even operating systems, seems like a big shot in the foot. My biggest concern, however, relates to advocacy. There will need to be books, magazine articles, tutorials, etc. written to announce the arrival of Perl 6. If the code uses Latin-1 characters, and people are unable to look at the example code in their favorite editor or type in some of the example code, we'll lose that person to Perl 6. The other alternative is to preface every article with the explanation of the separate ASCII/Latin-1 sigils. That doesn't sound practical, and cannot be policed or enforced. Also, don't think of the class sigil as a sigil. You won't be writing it very often. Just think of it as an operator. My final point: we don't introduce unicode characters lightly. We do so when we think it is the best symbol for the job, optimizing, for once, for readability rather than writability. As you mentioned above, readibility is a big issue. If I can't tell one sigil from another, or cannot even see it, how can I support the code? If you don't think the class sigil should be a unicode character, come up with a better one. We're not going to say You're right, Steve. No more unicode sigils! until wee see a good alternative to the unicode sigil that we have. ~ seems to be available for a sigil, if my reading of S02 is correct, and the cent sign is replacing :: in all cases. If not (that is $::foo is still the global variable named foo) then * may also be available. Steve Peters [EMAIL PROTECTED]
Re: new sigil
Surely you aren't suggesting that these non-English speakers do not have access to the ASCII (or EBCDIC) character sets for their editors, are you? Surely you aren't suggesting that your editor doesn't have access to the Latin-1 charset, are you? Let's take a look at popular editors: vi - check emacs - check eclipse - check mutt - check (http://www.rano.org/mutt.html) Notepad - check A bazillion other editors - check (http://www.alanwood.net/unicode/utilities_editors.html) I have worked on an app that needed to work with English (US and GB), German, and Japanese. I do not, however, remember having to write my code in anything but ASCII. No, I had to edit my -templates- and -data files- that included French text. Some of them could use HTML entities, but the datafiles intended for the DB couldn't. As I mentioned earlier, most programmers in a corporate environment have limited access to system settings. Changing them in some cases can cause reprimands or dismissal. Systems are often set up with the bare minimum of locales and character sets necessary to do the job. Also, you have to deal with the situations where programmers are connecting to *nix servers through a variety of Windows-based XWindows servers (Exceed, Cygwin, etc.) complicates what character sets are available immensely. I have worked as a contractor in almost a dozen settings, most of them corporate lockdowns, and I've always been able to go to my manager and say To be more productive, I need this tool and it would be loaded the next day. The few times I've had to talk to an IT person to explain the tool, I'd do it over lunch (my treat) and it would be on my desktop the next morning. Saying you cannot get a tool you need loaded on your machine is, essentially, saying that you cannot play corporate politics. I'm assuming you can, which means this is a straw man. Rob
Re: new sigil
Please let that the sigil looks like a certain leter not be a reason. Juerd They make for good mnemonics, which isn't necessarily a bad thing for people coming from languages without them or with fewer - sebastian
Re: $1 change issues [was Re: syntax for accessing multiple versions of a module]
On Thu, Oct 20, 2005 at 05:12:32PM -0700, Nate Wiger wrote: Every regex engine in every language uses $1 or \1. This includes Java, JavaScript, C, PHP, Python, awk, sed, the GNU regex libs, etc. Somehow other languages seem ok with this, because it's a widely-used convention. This quibbling over $0 and $1 seems like rampant bikeshedding to me. Given that @Larry has said that $0, $1, etc. correspond to $/[0], $/[1], etc, if you want to keep $1 as the first parenthesized part, then come up with a compelling, concrete proposal for what to do with $/[0] (and $0) keeping in mind that @array = /(foo)(bar)(baz)/; has to do the right thing. That's not my wish; just that it's time to take another look at the list of changes to see where the real-world benefit is. IMHO, self consistency is far and away more important than consistency with perl5. If Perl 6 is going to be successful, this means it must change the fewest key things with the most benefits. This may mean some things that aren't quite perfect still don't get changed. (It also means lots of new stuff can still be added - I'm just talking change.) I don't understand this. Change the fewest key things relative to what? Perl5? If so, why? Is it not enough that perl5 programs will still compile and run under perl6? Just food for thought... maybe I'm wrong... I don't know about wrong, but you're certainly entering the game a little late. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: new sigil
On Thu, Oct 20, 2005 at 10:40:44PM -0400, Rob Kinyon wrote: Surely you aren't suggesting that these non-English speakers do not have access to the ASCII (or EBCDIC) character sets for their editors, are you? Surely you aren't suggesting that your editor doesn't have access to the Latin-1 charset, are you? Let's take a look at popular editors: vi - check emacs - check eclipse - check mutt - check (http://www.rano.org/mutt.html) Notepad - check A bazillion other editors - check (http://www.alanwood.net/unicode/utilities_editors.html) Not every installed version of the above can handle Latin-1 by default. Since many programmers have little control over their installed software, this remains an issue. Also, the ability to do this within the application is not well documented within many editors. Finally, most will of the above allow you to paste in Latin-1 or even UTF-8 data, but the ability to actually enter it from a keyboard using the editor is a completely different issue. As I mentioned earlier, most programmers in a corporate environment have limited access to system settings. Changing them in some cases can cause reprimands or dismissal. Systems are often set up with the bare minimum of locales and character sets necessary to do the job. Also, you have to deal with the situations where programmers are connecting to *nix servers through a variety of Windows-based XWindows servers (Exceed, Cygwin, etc.) complicates what character sets are available immensely. I have worked as a contractor in almost a dozen settings, most of them corporate lockdowns, and I've always been able to go to my manager and say To be more productive, I need this tool and it would be loaded the next day. The few times I've had to talk to an IT person to explain the tool, I'd do it over lunch (my treat) and it would be on my desktop the next morning. Saying you cannot get a tool you need loaded on your machine is, essentially, saying that you cannot play corporate politics. I'm assuming you can, which means this is a straw man. I don't think a programmer's skill (or lack thereof) in corporate politics should be a prerequisite to experimenting in Perl 6. My bigger point is about system settings which are typically locked down and not usually sweet-talkable. Also, getting new software purchased can be a painfully slow depending on the bureaucracy involved, and generally requires lots of beers and lunches, or the right catastrophe, which could have been prevented and/or repaired with the tool you want, to speed up the process. Steve Peters [EMAIL PROTECTED]
Re: new sigil
Steve Peters [EMAIL PROTECTED] wrote:
~ seems to be available for a sigil, if my reading of S02 is correct, and
the cent sign is replacing :: in all cases. If not (that is $::foo is
still the global variable named foo) then * may also be available.
Sigils can't conflict with unary operators (like, say, the
stringification and flattening operators, ~ and *) and ideally
shouldn't conflict with binary ops either (although % breaks this
rule).
This has been done before several times on p6l, but I'll do it again:
Chr TermOperator
===
~ Stringify Concatenate
` Reserved for user Reserved for user
! Not
@ Array sigil Array sigil
# Comment Comment
$ Scalar sigilScalar sigil
% Hash sigil Hash sigil, modulo
^ (Not sure) one() junction
Subroutine sigilall() junction
* Unary splat Multiplication
( Open paren Subroutine call
) (technically unused)Close paren
- Negate Subtract
_ Identifier (technically unused)
= Iteration Assign
+ Numify Add
\ Take reference
| any() junction
[ Anonymous array Array index
{ Block Hash index
] (technically unused)Close square bracket
} (technically unused)Close curly bracket
; (technically unused)Statement delimiter, anonymous array
: Pairsuper comma
' Single quotes (technically unused)
Double quotes (technically unused)
, (technically unused)List items
quote words Less than
. Method call on topicMethod call
(technically unused)Greater than
/ Anonymous rule Divide
? Boolify
There are very few unary operators available, and none (besides the
user-defined backticks operator) unused in both term and operator
context.
--
Brent 'Dax' Royal-Gordon [EMAIL PROTECTED]
Perl and Parrot hacker
