Damn this is annoying. Is it perl.org that's dropping mail or me?
- Forwarded message from Simon Cozens <[EMAIL PROTECTED]> -
On Sat, Dec 16, 2000 at 08:09:23PM +, David Grove wrote:
> Thinking of just the parser as a single entity seems to me to be headed into
> trouble unless we can
This is the fourth time I've sent this mail to perl6-internals-api-parser,
but it doesn't seem to be arriving. None of my other mail is affected, and
perl5-porters is, for once, behaving itself; why this list in particular?
- Forwarded message from Simon Cozens <[EMAIL PROTECTED]> -
Dam
On Sun, Dec 17, 2000 at 02:11:50PM -0700, Nathan Torkington wrote:
> Nicholas Clark writes:
> > Would it be sane to get the parser to return suitable information on the
> > source to let a syntax analyser (such as a highlighting editor) know that
> > character positions 5123 to 5146 are a qq() str
Simon Cozens <[EMAIL PROTECTED]>
> IMHO, the first thing we need to design and code is the API and runtime
> library, since everything else builds on top of that, and we can design other
> stuff in parallel with coding it. (A lot of it will be grunt work.)
Personally I feel that that string part
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 06:05 PM 12/12/00 +, David Mitchell wrote:
> >Also, some of the standard perumations would also need to do some
> >re-invoking, eg
> >($int - $num) would invoke Int->sub[NUM](sv1,sv2,0), which itself would
> >just fall
> >through to Num->sub[INT](
David Mitchell <[EMAIL PROTECTED]> writes:
>
>Personally I feel that that string part of the SV API should include most
>(if not all) string functions, including regex matching and substitution.
What are string functions in your view?
m//
s///
join()
substr
index
lc, lcfirst, ...
&
Simon Cozens <[EMAIL PROTECTED]> writes:
>
>So, before we start even thinking about what we need, it's time to look at the
>vexed question of string representation. How do we do Unicode without getting
>into the horrendous non-Latin1 cockups we're seeing on p5p right now?
Well - my theorist's an
Sam Tregar <[EMAIL PROTECTED]> wrote:
> On Sun, 17 Dec 2000, David Grove wrote:
>
> > Ok, my C's rather rusty, but are we interested in parsing that?
>
> Yes. I've heard people talk about a C frontend. Will it ever see the
> light? I don't know. Does it matter? I don't think so.
Sorr
Sam Tregar <[EMAIL PROTECTED]> wrote:
> possible, right? Are you saying you don't think we should make it
> possible for someone to write a C parser for Perl?
For the full language spec, I don't think it's attainable, and honestly
don't see the reason for it within the context of Perl. It do
On Sun, 17 Dec 2000, David Grove wrote:
> > "Little languages", on the other hand, are a somewhat different matter.
> > They will presumably be not-so-complex and hence won't require such
> deep
> > hooks, and some redundancy there won't be such a big problem.
>
> I'm not sure how this is inc
On Sun, 17 Dec 2000 14:11:50 -0700 (MST), Nathan Torkington wrote:
>I think the problems with this that were raised in the past are:
> * parsing partial source
> * does this mean that the parser has to reparse the whole sourcefile
> every time you type a character?
Hold it. I don't think that
On Sun, 17 Dec 2000, Dan Sugalski wrote:
> At 02:24 PM 12/17/00 -0500, Sam Tregar wrote:
> >It comes down to what is meant by "little language". When I hear that
> >term I immediately think Scheme and TCL.
> For my part, at least, I've been thinking of something either LISP-ish or
> very si
On Mon, Dec 18, 2000 at 10:30:53AM -0500, Philip Newton wrote:
> On Sat, 16 Dec 2000, Jarkko Hietaniemi wrote:
>
> > On Fri, Dec 15, 2000 at 03:10:16PM -0500, Dan Sugalski wrote:
> > > At 11:18 AM 12/15/00 -0600, Jarkko Hietaniemi wrote:
> > > >
> > > >As painful as it may sound (codingwise) I wo
On Fri, Dec 15, 2000 at 11:18:00AM -0600, Jarkko Hietaniemi wrote:
> As painful as it may sound (codingwise) I would urge to spare some
> thought to using (internally) UTF-32 for those encodings for which
> UTF-8 would be *longer* than the UTF-32 (mainly the Asian scripts).
most CPUs can load a
Nick Ing-Simmons <[EMAIL PROTECTED]> wrote:
> e.g.
>
>if (SvENCODING(sv_a) != SvENCODING(sv_b))
> {
> if (SvENCODING(sv_a)->is_superset_of(SvENCODING(sv_b))
> {
>sv_upgrade_to(sv_b,SvENCODING(sv_a));
> }
> elsif if (SvENCODING(sv_b)->is_superset_of(SvENCODIN
On Mon, Dec 18, 2000 at 02:43:14PM +, Nick Ing-Simmons wrote:
> David Mitchell <[EMAIL PROTECTED]> writes:
> >
> >Personally I feel that that string part of the SV API should include most
> >(if not all) string functions, including regex matching and substitution.
[list of potential string op
On Sat, 16 Dec 2000, Jarkko Hietaniemi wrote:
> On Fri, Dec 15, 2000 at 03:10:16PM -0500, Dan Sugalski wrote:
> > At 11:18 AM 12/15/00 -0600, Jarkko Hietaniemi wrote:
> > >
> > >As painful as it may sound (codingwise) I would urge to spare some
> > >thought to using (internally) UTF-32 for those
On Sun, 17 Dec 2000, Dan Sugalski wrote:
> I'm thinking for speed that binary and UTF-32 should be our internal
> representations, at least for the data that gets handed to the regex
> engine. Or at least we use a constant-width character that's 8 and 32 bits,
> if I'm misusing UTF-32. (UTF-8
Nick Ing-Simmons <[EMAIL PROTECTED]> wrote:
> What are string functions in your view?
> m//
> s///
> join()
> substr
> index
> lc, lcfirst, ...
> & | ~
> ++
> vec
> '.'
> '.='
>
> It rapidly gets out of hand.
Perhaps, but consider that somewhere within the perl internals
> "NC" == Nicholas Clark <[EMAIL PROTECTED]> writes:
NC> I'm assuming that for performance reasons a parser-beast written in C would
NC> have code to do this conditionally compiled (like the -DDEBUGGING stuff)
NC> so that serious production perl wouldn't have the slowdown, but the perl
NC> yo
Another point re: the parsing process. I think it should be possible
for any of the steps or extensions to be defined as C code or as Perl
code. We're already shooting to have C subs isomorphic with Perl subs
so this shouldn't be a problem, just something to keep in mind.
Nat
Everyone:
I'm sorry about the recent commotion over minor aspects of regex design and
implementation. I stumbled into being the most active participant in an
argument nobody wanted, myself included. I realized too late (and with the
help of a friend) that I had been arguing for a _declarative_
Here's a quote from Jim McCarthy's "Dynamics of Software Development"
that seems relevant given the recent fracas on perl6-language-regexp:
Someone once asked me, "What's the hardest thing about software
development?"
I didn't hesitate. "Getting people to think."
Believe it or not, most peopl
On Mon, Dec 18, 2000 at 11:30:09AM +, David Grove wrote:
>
> Bart Lateur <[EMAIL PROTECTED]> wrote:
> > But, the gist of this post is: we don't want to loose the usefulness of
> > the syntax highlighter, as soon as there is one syntax error in the
> > script, because this will be the norm
Andy Dougherty <[EMAIL PROTECTED]> wrote:
> > That sounds too complex for what seems like a more simple solution.
When
> > you say "turn simple 'languages' into perl", that's what Dan's told
me is
> > my source filter.
>
> Correct. perl-byacc is a source filter. It takes in yacc source an
Andy Dougherty <[EMAIL PROTECTED]> wrote:
> The issues of 'use Python' or 'use Pythonish' are a quite different
issue.
> I don't think anyone believes it ought to be easy to *write* the
Pythonish
> module.
I do.
That's the problem. This is a nearly ubiquitously desired objective
(writing th
Bart Lateur <[EMAIL PROTECTED]> wrote:
> On Sun, 17 Dec 2000 14:11:50 -0700 (MST), Nathan Torkington wrote:
>
> >I think the problems with this that were raised in the past are:
> > * parsing partial source
> > * does this mean that the parser has to reparse the whole sourcefile
> > ever
On Mon, 18 Dec 2000, David Grove wrote:
> For the full language spec, I don't think it's attainable, and honestly
> don't see the reason for it within the context of Perl.
I've got a simple reason for it - I think it's going to be part of the
Perl6 spec. Do I have any proof? Nope. We'll know
On Mon, Dec 18, 2000 at 03:21:05PM +, Nick Ing-Simmons wrote:
> Simon Cozens <[EMAIL PROTECTED]> writes:
> >
> >So, before we start even thinking about what we need, it's time to look at the
> >vexed question of string representation. How do we do Unicode without getting
> >into the horrendous
David Mitchell <[EMAIL PROTECTED]> writes:
>> Personally I would not use such a beast
>
>But with different encodings implemented by different SV types - each with their
>own vtable - surely most of this will "come out in the wash", by the correct
>method automatically being called. I thought tha
Nicholas Clark <[EMAIL PROTECTED]> writes:
>On Fri, Dec 15, 2000 at 11:18:00AM -0600, Jarkko Hietaniemi wrote:
>
>> As painful as it may sound (codingwise) I would urge to spare some
>> thought to using (internally) UTF-32 for those encodings for which
>> UTF-8 would be *longer* than the UTF-32 (m
I just got off the phone with Larry. He's been laid up for three
weeks with a trip to Japan followed by a virus from Japan. He's on
his feet again, and continuing to work through the RFCs.
He's changing the way he's doing it. Now he's going to try to find
clusters of RFCs on a particular topic
On Mon, Dec 18, 2000 at 11:33:36AM -0700, Nathan Torkington wrote:
> I just got off the phone with Larry. He's been laid up for three
> weeks with a trip to Japan followed by a virus from Japan. He's on
So Perl 6 will be...Ruby? :-)
--
$jhi++; # http://www.iki.fi/jhi/
# There is this
David Mitchell <[EMAIL PROTECTED]> writes:
>Nick Ing-Simmons <[EMAIL PROTECTED]> wrote:
>> What are string functions in your view?
>> m//
>> s///
>> join()
>> substr
>> index
>> lc, lcfirst, ...
>> & | ~
>> ++
>> vec
>> '.'
>> '.='
>>
>> It rapidly gets out of hand.
>
>Per
Nicholas Clark <[EMAIL PROTECTED]> wrote:
> On Mon, Dec 18, 2000 at 11:30:09AM +, David Grove wrote:
> >
> > Bart Lateur <[EMAIL PROTECTED]> wrote:
>
> > > But, the gist of this post is: we don't want to loose the
usefulness
> of
> > > the syntax highlighter, as soon as there is one
Sam Tregar <[EMAIL PROTECTED]> wrote:
> On Mon, 18 Dec 2000, David Grove wrote:
>
[snip]
> > _Perl_ _within_ _a_ _Perl_ _context_ _and_ _for_ _Perl_ _purposes_,
>
> Feeling a little hostile to the rest of the programming world? You're
> sounding almost nationalistic! We're not at war.
At 12:29 PM 12/18/00 +, David Grove wrote:
>Sam Tregar <[EMAIL PROTECTED]> wrote:
>
> > On Mon, 18 Dec 2000, David Grove wrote:
> >
>
>[snip]
>
> > > _Perl_ _within_ _a_ _Perl_ _context_ _and_ _for_ _Perl_ _purposes_,
> >
> > Feeling a little hostile to the rest of the programming world?
At 06:05 PM 12/18/00 +, Nicholas Clark wrote:
>On Mon, Dec 18, 2000 at 11:30:09AM +, David Grove wrote:
> >
> > Bart Lateur <[EMAIL PROTECTED]> wrote:
>
> > > But, the gist of this post is: we don't want to loose the usefulness of
> > > the syntax highlighter, as soon as there is one syn
Jarkko Hietaniemi <[EMAIL PROTECTED]> writes:
>On Mon, Dec 18, 2000 at 03:21:05PM +, Nick Ing-Simmons wrote:
>> Simon Cozens <[EMAIL PROTECTED]> writes:
>> >
>> >So, before we start even thinking about what we need, it's time to look at the
>> >vexed question of string representation. How do w
> At worst we have to write a "worst case" override entry for each op and
> then work what it needs back - this is exemplified by PerlIO_getpos()
> the "position" arg had to stop being an Fpos_t and become an SV *
> so that stdio could stuff an Fpos_t in it, but a transcoding layer
> could put th
> >> As I pointed out on p5p even EBCDIC machines can use that model - but
> >> the downside is that ord('A') == 65 which will breaks backward compatibility
> >> with EBCDIC scripts.
> >
> >Maybe we need $ENV{PERL_ENCODING} to control ord() and chr(), too?
>
> That was my suggestion last week
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 12:29 PM 12/18/00 +, David Grove wrote:
>
> >Sam Tregar <[EMAIL PROTECTED]> wrote:
> >
> > > On Mon, 18 Dec 2000, David Grove wrote:
> > >
> >
> >[snip]
> >
> > > > _Perl_ _within_ _a_ _Perl_ _context_ _and_ _for_ _Perl_
_purposes_,
[EMAIL PROTECTED] (Jarkko Hietaniemi) wrote on 15.12.00 in
<[EMAIL PROTECTED]>:
> On Fri, Dec 15, 2000 at 12:13:01PM +, Simon Cozens wrote:
> > IMHO, the first thing we need to design and code is the API and runtime
> > library, since everything else builds on top of that, and we can design
On Sun, 17 Dec 2000, Simon Cozens wrote:
> This is the fourth time I've sent this mail to perl6-internals-api-parser,
I've seen it on the list at least twice.
> but it doesn't seem to be arriving. None of my other mail is affected, and
> perl5-porters is, for once, behaving itself; why this lis
On Sun, Dec 17, 2000 at 11:28:49PM +1100, Jeremy Howard wrote:
> There's not necessarily any circular reference. The problem is that method
> references are frequently used to implement event callbacks. This would
> generally look something like this:
Hmmm... an object which contains a method re
Michael G Schwern wrote:
> Hmmm... an object which contains a method reference which contains a
> referent to itself.
>
Yup. I don't know why some people think that circular references are complex
;-)
>
> > Something like this would be nice in a class that creates method
> > references--it would s
46 matches
Mail list logo
