David L . Nicol <[EMAIL PROTECTED]> writes:
>Jarkko Hietaniemi wrote:
>
>> Some sort of simple markup embedded within the C comments. Hey, let's
>> extend pod! Hey, let's use XML! Hey, let's use SGML! Hey, let's use
>> XHTML! Hey, let's use lout! Hey, ...
>
>Either run pod through a pod pull
Simon Cozens wrote:
[...]
> I'm just not sure it's fair on Old World hackers. Will there be a way to stop
> Perl upgrading stuff to Unicode on the way in?
and I'm probably not the only Old World hacker that would
prefer a build option to simply eliminate Unicode support altogether...
Nick Ing-Simmons <[EMAIL PROTECTED]> opined:
> >Either run pod through a pod puller before the C preprocessor gets to
> >the code, or figure out a set of macros that can quote and ignore pod.
> >
> >The second is Yet Another Halting Problem so we go with the first?
> >
> >Which means a little prog
From: Dan Sugalski [mailto:[EMAIL PROTECTED]]
> At 11:09 PM 3/23/2001 +, Simon Cozens wrote:
> >
> > For instance, chr() will produce Unicode codepoints. But
> > you can pretend that they're ASCII codepoints, it's only
> > the EBCDIC folk that'll get hurt. I hope and suspect
> > there'll be an
At 09:09 AM 3/26/2001 -0600, Garrett Goebel wrote:
>Someone please clue me in. A pointer to an RFC which defines the use of
>colons in Perl6 among other things would help.
>
>Why not have subsequent uses of : on the same variable name perform a cast?
>Or perhaps better returned the casted value?
At 05:09 PM 3/23/2001 -0800, Damien Neil wrote:
>So the results of ord are dependent on a global setting for "current
>character set" or some such, not on the encoding of the string that
>is passed to it?
Nope, ord is dependent on the string it gets, as those strings know what
their encoding is.
At 02:58 PM 3/26/2001 +0100, Dave Mitchell wrote:
>Nick Ing-Simmons <[EMAIL PROTECTED]> opined:
> > Perhaps we could teach pod that /* was alias for =pod
> > and */ an alias for =cut ?
>
>or possibly
>
>/*=foo is an alias for =foo,
>and */ is an alias for =cut only after a /*= has been encountered
Dan Sugalski <[EMAIL PROTECTED]> writes:
>At 05:09 PM 3/23/2001 -0800, Damien Neil wrote:
>>So the results of ord are dependent on a global setting for "current
>>character set" or some such, not on the encoding of the string that
>>is passed to it?
>
>Nope, ord is dependent on the string it gets,
At 05:45 PM 3/26/2001 +, [EMAIL PROTECTED] wrote:
>Dan Sugalski <[EMAIL PROTECTED]> writes:
> >At 05:09 PM 3/23/2001 -0800, Damien Neil wrote:
> >>So the results of ord are dependent on a global setting for "current
> >>character set" or some such, not on the encoding of the string that
> >>is
On Mon, Mar 26, 2001 at 11:32:46AM -0500, Dan Sugalski wrote:
> At 05:09 PM 3/23/2001 -0800, Damien Neil wrote:
> >So the results of ord are dependent on a global setting for "current
> >character set" or some such, not on the encoding of the string that
> >is passed to it?
>
> Nope, ord is depen
At 04:34 PM 3/24/2001 -0800, Dave Storrs wrote:
> I'll just toss my 0.01 cents in...my thought here is that this
>thread has now tied up a lot of cycles from a lot of very smart, very
>experienced people without resulting in an answer that is clearly The
>Right Thing. Whatever we do, ther
Dan Sugalski <[EMAIL PROTECTED]> writes:
>>This the main pain with 5.7.*'s EBCDIC scheme - making
>>
>>ord('A') == 193
>>
>>true :-/
>
>That would be true if EBCDIC was the default encoding, otherwise false.
But what about
our $var;
{
use encoding 'US-ascii';
$var = 'A';
}
{use Encoding 'i
At 02:52 AM 3/25/2001 -0500, Philip Newton wrote:
>On Fri, 23 Mar 2001, Dan Sugalski wrote:
>
> > At 02:31 PM 3/23/2001 -0500, Bryan C. Warnock wrote:
> > >On Friday 23 March 2001 14:18, Dan Sugalski wrote:
> > > > At 01:30 PM 3/22/2001 -0800, Hong Zhang wrote:
> > > > >We need the character equiv
Damien Neil <[EMAIL PROTECTED]> writes:
>On Mon, Mar 26, 2001 at 11:32:46AM -0500, Dan Sugalski wrote:
>> At 05:09 PM 3/23/2001 -0800, Damien Neil wrote:
>> >So the results of ord are dependent on a global setting for "current
>> >character set" or some such, not on the encoding of the string that
Dan Sugalski <[EMAIL PROTECTED]> writes:
>
>For length, I'd as soon it returned the number of code points, but glyphs
>and bytes are also valid return values.
And that may be where it belongs - at the language level
chars($s) == 120
bytes($s) == 480
glyphs($s) == 360
length($
On Mon, Mar 26, 2001 at 06:16:00PM +, [EMAIL PROTECTED] wrote:
> Damien Neil <[EMAIL PROTECTED]> writes:
> >On Mon, Mar 26, 2001 at 11:32:46AM -0500, Dan Sugalski wrote:
> >> At 05:09 PM 3/23/2001 -0800, Damien Neil wrote:
> >> >So the results of ord are dependent on a global setting for "curr
From: Dan Sugalski [mailto:[EMAIL PROTECTED]]
> At 05:09 PM 3/23/2001 -0800, Damien Neil wrote:
> > So the results of ord are dependent on a global setting for
> > "current character set" or some such, not on the encoding
> > of the string that is passed to it?
>
> Nope, ord is dependent on the s
At 11:42 AM 3/26/2001 -0600, Garrett Goebel wrote:
>From: Dan Sugalski [mailto:[EMAIL PROTECTED]]
> > At 05:09 PM 3/23/2001 -0800, Damien Neil wrote:
> > > So the results of ord are dependent on a global setting for
> > > "current character set" or some such, not on the encoding
> > > of the strin
Nick Ing-Simmons wrote:
> Perhaps we could teach pod that /* was alias for =pod
> and */ an alias for =cut ?
that won't work because pod/cut is strictly line-based and C-style
comments are strictly stream-based.
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
He who sa
On Mon, Mar 26, 2001 at 01:23:36PM -0600, David L. Nicol wrote:
> Nick Ing-Simmons wrote:
> > Perhaps we could teach pod that /* was alias for =pod
> > and */ an alias for =cut ?
>
> that won't work because pod/cut is strictly line-based and C-style
> comments are strictly stream-based.
Damn. Co
Damien Neil <[EMAIL PROTECTED]> writes:
>> >So $c = chr(ord($c)) could change $c? That seems odd.
>>
>> It changes its _representation_ (e.g. from 0x45,ASCII to 0xC1,EBCDIC)
>> but not its "fundamental" 'LATIN CAPITAL LETTER A'-ness.
>> Then of course someone will want it to be the number 0x45 a
David L . Nicol <[EMAIL PROTECTED]> writes:
>Nick Ing-Simmons wrote:
>
>> Perhaps we could teach pod that /* was alias for =pod
>> and */ an alias for =cut ?
>
>that won't work because pod/cut is strictly line-based and C-style
>comments are strictly stream-based.
I was not suggesting we hunt dow
On Mon, Mar 26, 2001 at 08:37:05PM +, [EMAIL PROTECTED] wrote:
> >If ord is dependent on the encoding of the string it gets, as Dan
> >was saying, than ord($e) is 0x81,
>
> It it could still be 0x81 (from ebcdic) with the encoding carried
> along with the _number_ if we thought that worth t
From: Damien Neil [mailto:[EMAIL PROTECTED]]
> On Mon, Mar 26, 2001 at 08:37:05PM +, [EMAIL PROTECTED] wrote:
> > >
> > > If ord is dependent on the encoding of the string it gets, as Dan
> > > was saying, than ord($e) is 0x81,
> >
> > It it could still be 0x81 (from ebcdic) with the encodin
24 matches
Mail list logo
