Re: RFC 85 - VMS Style Error coding
As a casual VMS user, I've always liked the way that VMS coded its error
messages. Perhaps a similar technique could be adopted for perl.
Each message has 4 parts:
Facility:
This is the thing that is reporting the error
Severity:
This is a severity ranking (I=informational, W=warning,
E=error, F=fatal)
Message-Code:
This is a single word abbreviation of the 'gist' of the message
Text Message:
This is a human readable message giving more details.
For example, an message which may occur when using VMS may be:
%APPEND-I-CREATED, TEST.OUT;1 created.
This is an informational message from append informing us a file was created.
A VMS-like perl message may look like:
%EVAL-E-SYNTAX, syntax error at (eval 1) line 2, at EOF
Since the facility, severity, and message code are clearly separate parts of
the message, they can easily be tested with a regex:
if($@=~m/-E-/) {
# an error of some sort has occurred
}
Maybe it doesn't need all the shouting, and maybe the format could be
rearranged to make it friendlier, but it should be pretty extensible so
anything can "throw" its own error messages and still be easily caught
by regexes. It should also allow for easy localization.
Brian Wheeler
[EMAIL PROTECTED]
Re: implied pascal-like "with" or "express"
I've usually been lurking, but I have a few thoughts
>
> On Thu, 17 Aug 2000, Jonathan Scott Duff wrote:
>
> > BTW, if we define C to map keys of a hash to named place holders
> > in a curried expression, this might be a good thing:
> >
> > with %person {
> > print "Howdy, ", ^firstname, " ", ^lastname;
> > }
> >
> > # becomes
> > sub {
> > print "Howdy, ", $person{$_[0]}, " ", $person{$_[1]};
> > }->('firstname', 'lastname');
> >
> > # becomes
> > print "Howdy, ", $person{'firstname'}, " ", $person{'lastname'};
> >
> > (If that's what people meant, I didn't see anyone actually say it).
>
>
> Well, so far, I like this best of everything that's been proposed
> for how "with" will work. I am still passionately against the keyword
> "with", since (IMHO) it conveys no sense of what it does. I think any
> of the following keywords would be better:
> express, alias, in, within
>
> The following words could also be overloaded for this purpose:
> map, use
"Using" might be an interesting alternative, and it reads well: "using this
hash, eval this block." Of course, with 'with', perl poetry might be
more interesting:
with %this_ring {
$i->wed($thee);
}
:)
>
> In any case, if I'm tracking correctly, all of the following
> should be legit using the new syntax (forgive me for trying a new keyword):
>
> within %person {
> &calc_letter_grade(^name, \^letter_grade);
> print "^first_name is ^age\n";
> print "^{first_name}'s numerical grade is ^num_grade\n";
> ^num_grade = 0 unless ^never_missed_class;
> if ( ^num_grade > 60 ) { print "^name passed!\n"; }
> @temp = (^name, ^age);
> };
>
>
> This would translate to the following:
> &calc_letter_grade($person{name}, \$person{letter_grade});
> print "$person{first_name} is $person{age}\n";
> print "$person{first_name}'s numerical grade is
> $person{num_grade}\n";
> $person{num_grade} = 0 unless $person{never_missed_class};
> if ( $person{num_grade} > 60 ) { print "$person{name}
> passed!\n"; }
> @temp = ($person{name}, $person{age});
>
>
> Dave
>
What if the hash keys we want to use are not valid scalar names? For example,
I've had keys like "total - female" as keys, but using the ^ syntax
would fail on this...
Brian Wheeler
[EMAIL PROTECTED]
Re: Larry's Apocalypse 1
I normally just lurk, but... > > Dan Sugalski <[EMAIL PROTECTED]> writes: > > Why? We don't ask this of any other compiler, so why ask it of perl? > > (You won't find this in a C, or Fortran, or Ada compiler...) > > Yes, but my compiled C binaries in /usr/bin don't break when I upgrade > gcc. A binary is largely independent of its compiler once it is > compiled and installed, interpreted programs do not have this luxury. > > Think of it this way... what would happen if Borne Shell suddenly > decided it was going to introduce fundemental incompatibilities? (I'm > sure they already have...) This is why when you call bash as /bin/sh, it behaves like the original Bourne shell. Name tricks are ugly, but useful. Perhaps the best solution would be to call the new interpreter perl6. If it finds itself being called 'perl' or 'perl5' then it should assume perl 5 code unless there's something that triggers it to assume otherwise (I.e. the module keyword) Brian Wheeler [EMAIL PROTECTED]
Re: Math functions? (Particularly transcendental ones)
On Sat, 2001-09-08 at 11:00, Dan Sugalski wrote: > Okay, I'm whipping together the "fancy math" section of the interpreter > assembly language. I've got: > > sin, cos, tan : Plain ones > asin, acos, atan : arc-whatevers > shinh, cosh, tanh : Hyperbolic whatevers > log2, log10, log : Base 2, base 10, and explicit base logarithms > pow : Raise x to the y power > > Can anyone think of things I've forgotten? It's been a while since I've > done numeric work. > > Dan > While not math, per se, there are bitops (and, or, not, xor, eqv) and shifts (though they can be simulated by "mul tx,ty,(2^bits)" and "div tx,ty,(2^bits)") I doubt rolls would be useful :) Are there going to be string ops as well, or would add and mul work on string registers? Brian
Re: Perl6 Operator List, TAKE 4
On Mon, 2002-10-28 at 16:25, Michael Lazzaro wrote: > explicit radix specifications for integers: > 0123- decimal >2:0110- binary [also b:0110?] >8:123 - octal [also o:123?] >16:123- hex[also h:123?] >256:192.168.1.0 - base 256 >(...etc...) > I've got to admit that I've not paid alot of attention to this thread...but does that mean 0x1234 and 01234 (octal) go away or is this an omission? Brian Wheeler [EMAIL PROTECTED] > > other uncategorized: > >my our - [declar] >mapgrep >sqrt log sin cos tan (etc...) - math >lc lcfirst uc ucfirst >intord oct hex bin > > > MikeL
Re: Perl6 Operator List, TAKE 4
On Mon, 2002-10-28 at 16:44, Mark J. Reed wrote: > On 2002-10-28 at 16:39:10, brian wheeler wrote: > > [The below is actually from Larry, not Michael] > > > explicit radix specifications for integers: > > > 0123- decimal > > >2:0110- binary [also b:0110?] > > >8:123 - octal [also o:123?] > > >16:123- hex[also h:123?] > > >256:192.168.1.0 - base 256 > > >(...etc...) > The post that started this thread was a complaint about > leading 0 meaning octal - which is counterintuitive to everyone the > first time they come across it in C or Perl or Java or wherever. > So yes, as indicated by the first line above, if > this proposal were to be adopted (and again, it's just Larry thinking out > loud), 0123 would be 123 decimal, not 123 octal = 83 decimal. > That's fair..especially since the only place most people use octal is mkdir and chmod. > However I don't see any reason not to allow 0x as a synonym for > 16: (or 16# or whatever the radix syntax would be). That's probably a good idea to make it a synonym since hex notation is used much more often than octal. Thanks for the clarification! Brian > > -- > Mark REED| CNN Internet Technology > 1 CNN Center Rm SW0831G | [EMAIL PROTECTED] > Atlanta, GA 30348 USA | +1 404 827 4754
Re: [RFC] Perl6 Operator List, Take 5
On Thu, 2002-10-31 at 04:02, Iain 'Spoon' Truskett wrote: > * Dyck, David ([EMAIL PROTECTED]) [31 Oct 2002 19:21]: > > [...] > > You could use the Character Map accessory to put > > the character into the clipboard, or > > press the alt and hold the alt key while typing 0171 (or 0187) > > < alt+0171 > > > alt+0187 > > To be honest, as easy as it is to type ^a^v<< or ^k<<,[1] it's still > typing an awful lot just to get a character. Surely the Perl operator > Huffman encoding should take into account the length of time it takes to > type the darn thing. > > Personally, I'm against non US-ascii chars being part of the core > language. It's fine if people want their Unicode identifiers, or import > modules to change operators, but I'd like to think I can at least read > and write my own code in non-Latin-1 environments. I agree considering, this isn't APL and the problems people have had mailing examples (let alone creating them!). I've got to admit all of these operators are scaring me. Seems alot like Brooks' second-system effect. Brian Wheeler [EMAIL PROTECTED]
Re: [RFC] Perl6 Operator List, Take 5
On Thu, 2002-10-31 at 12:15, Larry Wall wrote:
> On 31 Oct 2002, brian wheeler wrote:
> : I agree considering, this isn't APL and the problems people have had
> : mailing examples (let alone creating them!).
>
> Nevertheless, it has already been decreed that Perl 6 programs are
> written in Unicode. That's not gonna change...
>
Fair enough. However it seems the world isn't ready for unicode
operators. Ok, maybe its me that's not ready. Being a boring American
from the midwest I don't need no stinking French quotes! :) The fries
are good, though.
Anyway, I think that this is a good discussion (despite there being too
many threads to try to follow) and an important one. However,
considering I've spent the last 45 minutes trying to figure a quick way
to enter french quotes into my mailer and editor without them both being
very different and without resorting to cutting and pasting is showing
me that there are big problems with my environment (redhat 8, emacs,
evolution) and I suspect I'm not the only one. Displaying the glyphs
has been ok, for the most part, but its been hit and miss, depending on
other people's configuration. Some tables of operators have had lots of
holes.
It seems that to write effective perl using the new features requires me
to change not only how I think in the language, but also how I use my
computer. I think this might be too big of a leap for some. Unless
there's a compromise. Which brings up a question I hesitate to ask:
will there be the equivalent of trigraphs to cover the non-ascii
characters used? While ??< is a terrible substitute for {, it did get
the job done when people weren't able to press the '{' key. It gave
some visual clue as to what was going on, and was fairly easy to
remember. It doesn't bother me if someone wants to use @StraÃe for an
array, but it gets bad if when instructing others I have to pull some
voodoo key sequence (especially one which is different for each platform
and/or program being used) in order to get the job done. Explaining
emacs' M-x was bad enough for some of the non-programmers in my
organization.
I'm going to go back to lurking now, because I do trust (most) of you.
Though Dan is pretty odd sometimes. :) I know that all of this will get
resolved in a (hopefully) sane fashion. I just wanted to voice my
concerns.
> : I've got to admit all of these operators are scaring me. Seems alot
> : like Brooks' second-system effect.
>
> But that's our slogan:
>
> Perl 6 is second-system effect done right.
>
> :-)
>
But, doesn't *everyone* say that? :)
Brian
> Larry
