Larry Wall wrote:
> "Sure, you can download the object code for this 5 line Perl program
> into your toaster...but you'll also have to download this 5 gigabyte
> regex interpreter before it'll run."
>
> That's a scenario I'd love to avoid. And if we can manage to store
> regex opcodes and
Jarkko Hietaniemi wrote:
> Err...a regex that isn't a regex, is this a Zen koan...? Ahhh, you
> want to emulate the state machine in Pure Perl. Okay... next thing
> you want to do is to write symbolic assembler in C...? :-)
I have my reasons :)
Actually, I want to write a c into perl compile
Graham Barr wrote:
> I think there are a lot of benefits to the re engine not to be
> separate from the core perl ops.
So does it start with a split(//,$bound_thing) or does it use
substr(...) with explicit offsets?
Dan Sugalski wrote:
>
> I've been
> assuming that an Anything->Unicode translation will be lossless, but this
> makes me wonder whether that assumption is correct.
I seem to recall from reading articles on this issue that the issue is
encoding of arrangement: Even with an unlimited number of g
Russ Allbery wrote:
>
> a caseless character wouldn't show up in
> either IsLower or IsUpper.
maybe an IsCaseless is warrented -- or Is[Upper|Lower]
could return UNKNOWN instead of TRUE|FALSE, if the
extended boolean attributes allow transbinary truth values.
Dan Sugalski wrote:
> Hong Zhang wrote:
>
> > I don't see the core should support language/locale in this detail.
> > I deal a lot of mix chinese/english text file. There is no way to represent
> > it using plain string, unless you want to make string be rich-format-text
> > -buffer. Current local
Dan Sugalski wrote:
> >If the internal string API is a tree instead of a contiguous memory block,
> >the tagging could be done at the node or branch level.
> >
> >Besides, you get nondestructive inserts.
>
> Yup. The only problem is that it makes the string data significantly more
> complex. I d
Dave Mitchell wrote:
> some sort of clone method
With tree strings, at clone time they get reorged into minimal number
of nodes: back to one big block if they are all the same type, or
back to one block for each type transition if it is tagged data.
Having the basic string type support arbi
Benjamin Stuhl wrote:
> (eg. I solemnly swear to never use symbolic
> references, count on specific op patterns, or
> use any number large enough to require
> bignums.)
These are things (aside from the number limit, but overflow catching
is need
Dan Sugalski wrote:
> The C structure that represents a bigint is:
>
>struct bigint {
> void *buffer;
> UV length;
> IV exponent;
> UV flags;
>}
>
> =begin question
>
> Should we scrap the buffer pointer and just tack the buffer on the end
> of the structure? Saves
Dan Sugalski wrote:
>
> At 12:51 PM 7/6/2001 -0500, David L. Nicol wrote:
> >Benjamin Stuhl wrote:
> >
> > > (eg. I solemnly swear to never use symbolic
> > > references, count on specific op patterns, or
> > >
Dan Sugalski wrote:
>
> At 01:59 PM 7/6/2001 -0500, David L. Nicol wrote:
> in-code pragmata instead of compiler switches?
>
> Lexically scoped optimization hints seem like rather a tricky thing to deal
> with.
I know I'm naive but here's how I see it:
->
Dan Sugalski wrote:
[... massive sniping snippage ...]
> The problem I was talking about was those cases where we have a good but
> not perfect match at compile time. In the case you gave, we assume that @A
> are full of fish, so dispatch to the "multiple fish parameter" version of
> list_medica
http://cobolforgcc.sourceforge.net/cobol_14.html
Hildo Biersma quoted RFC 62 and then went on thusly:
> > C is an excellent medium for sharing the glory of the internals
> > of Perl with the C programming community. It is hoped that the
> > interface deescribed herein will become an excellent medium for
> > sharing the glory of the internals o
http://dev.perl.org/rfc/37.pod
And if we adopt complex data structures (how complex? just
wrappers for C structs, into very fast hashes) as suggested in
rfc 61, we could return those special, limited pseudohashes
with only the relevant names, resolvable into offsets at
compile time, instead of t
Dan Sugalski wrote:
>
> On Tue, 8 Aug 2000, Nick Ing-Simmons wrote:
> >
> > this list is _only_ concerned with implementation details.
>
> Well, assuming you consider API definitions implementation details. :)
>
> Dan
I thought from the example RFC that
Dan Sugalski wrote:
> >ways to link C functions other than C (or any other external
> >binary with a specifiable linkage) directly into Perl, so that
> >not only do I not have to fire up a sub process, I don't even have to
> >select the blade of my fancy pocket knife with a command line option:
The other advantage of typed languages is that the run-time can
be faster, and the storage streamlined.
> There is a drawback: exceptions raised ("That's not an integer!" *croak*)
> are made at run-time, rather than compile-time (as would be more useful).
> As a result you have to test all c
Two fields.
First is type, which is 0 for a double-precision FP
1 for a string and higher than that for a defined type in the
defined type table.
Second is the number, for type 0, and a pointer to
the beginning of the object for everything else. Objects will
fit in contiguous memory or wi
"Bryan C. Warnock" wrote:
>
> On Thu, 10 Aug 2000, David L. Nicol wrote:
> > Within a perl instance, every object type must register itself on
> > loading. At registration, a number is assigned, the jump table
> > of common functions that that object type o
Dan Sugalski wrote:
>
> On Thu, 10 Aug 2000, David L. Nicol wrote:
>
> > Two fields.
> >
>
> This'll cause issues both with GC and thread synchronization. (Besides,
> don't skimp on fields in the base variable structure. Memory's reasonably
> c
Dan Sugalski wrote:
> Strong typing and sparse arrays are orthogonal--no reason we shouldn't use
> them if someone does:
>
>$foo[time]
>
> or something of the sort. (People like huge arrays with few scalars in
> them too... :)
>
> Dan
And for the i
Graham Barr wrote:
>
> On Thu, Aug 10, 2000 at 06:26:24PM -0400, Chaim Frenkel wrote:
> > > "NI" == Nick Ing-Simmons <[EMAIL PROTECTED]> writes:
> >
> > NI> You just re-invented "look up the name in a hash table" ;-)
> >
> > I thought I was saving the constant search along the @ISA, do it onl
Dan Sugalski wrote:
not work.
>
> I think we're going to have to have a doubly-linked list going for @ISA, so
> when a parent package changes the child packages get changed too. It'll
> make updates to @ISA more expensive, but if you do that then you ought to
> be prepared to take a hit.
>
>
Michael Fowler wrote:
> > > Which then raises a few more problems (whew): how do you coax user input
> > > (which is an SV) into a value $foo can accept with very-strict on?
> >
> > You run it through an explicit conversion process, like using C in
> > a C program
>
> Unfortunately, this involv
Just in case I'm not the only one here who doesn't know what TIL means:
http://www.cs.cornell.edu/home/jgm/tilt.html
Larry Wall wrote:
> By the way, don't take this as a final design of string types either. :-)
If string types are a tree of partially full nodes of string data, the
representation of each sNode could be independent of the others.
The originial idea behind using partially full nodes is, you c
internally, how to do it:
ASSIGNMENT, as in, Change-my-values-w/o-changing-my-type,
is in the vtable for the object.
When an object becomes constant, its ASSIGNMENT function gets
replaced with
$heres_what_it_gets_replaced_with=sub{
throw "ERROR-ASSIGNMENT-TO-CONSTANT
I wrote a transaction-enabled database in perl 5, using fork()
for my multithreading and flock() for my mutexes. It continues
to work just fine.
Threading gives us mutexes. Are you just saying that
every variable should have its own mutex, and perl's = assignment
operator should implicitly se
512 byte pages, stored on a permanent device and paged
in as required, for everything
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
Does despair.com sell a discordian calendar?
We mostly can. This is really an echo of the "read-only, not constant"
idea from a while back. This way you can take references to them, for
instance. The compiler doesn't know where they will go.
Overloading the assign-to-me operator is faster than having a flag, you
never have to check it.
No, because each table lookup takes less time than comparing one
letter of a text string.
> sv->vtable->svpvx;
>
> Isn't this going to really, really hurt?
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
Does despair.com sell a discordia
>
> In perl 6 the keys and values functions should no longer use the
> same iterator as the each function - each use of keys and values
> should use it's own private iterator instead.
And a separate one for each thread, too -- can't forget that --
"David L. Nicol" wrote:
>
> >
> > In perl 6 the keys and values functions should no longer use the
> > same iterator as the each function - each use of keys and values
> > should use it's own private iterator instead.
we could put it in a variable a
> we could put it in a variable associated with the instance of the
> keyword. An associative array of threads to current-values.
or in the "global per-thread data area" keyed to some immutable-during-the-run
value.
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
Dan Sugalski wrote:
>
> Any variable that has a 'per-thread' component should be self-contained.
>
> Dan
We don't know how many instances of iteration happening in the
program there will be, or how many there can be. If each instance
of hash iteration
John Porter wrote:
>
> "All flow control will implemented as longjumps."
>
> --
> John Porter
# language description has a lot to do.
# this is a general, threaded, top-level loop.
# a no-brainer.
$rearrange = sub{ # so this can be redefinied
my $i, $t, $n;
for (my $i =
Imagine a combined hash/array CONTAINER type. The difference between
hashes and arrays becomes that arrays are restricted to non-negative integer
key values. @grumpy and %grumpy can even have the same head node in their
data structure, but the accessors will, unless told otherwise, only pick o
Nathan Torkington wrote:
>
> moving getprotobyname()
>to a module isn't the same as moving open().
And it can be transparent, if it isn't already. Why does perl
need to be monolithic? I thought I selcted to build as shared
libraries, splitting that into several shared libraries might
be e
You can make multidimensional containers in perl5 by settling
on a syntax for combining all the dimensions into a key value and
using that as the key in a hash.
If arrays as we know them implement by using a key space restricted to
integers, I think a reasonable way to get matrices would be to o
Dan Sugalski wrote:
> If it's decreed that fork is
> just there without having to do something special, then it will be no
> matter what magic needs to be done.
package refimpl::builtins;
sub fork {
$refimpl::threads::deepcopy_target = new refimpl::perprocglobal
perl5 sort of already has an C, in that DESTROY() methods
are called on any blessed lexicals when the scope closes. Taking
advantage of that for closing a file works if you hide your files
in an object class or equivalent chicanery.
Allowing user code into the list of things that perl does on s
list of functions
I've used very recently, or something like that. This
Nathan Torkington wrote:
>
> David L. Nicol writes:
> > If we use exceptions of some kind to handle
> > syntax, encountering an exception of type "unknown-keyword:Cmp" could
> &g
Nathan Torkington wrote:
>
> David L. Nicol writes:
> > Any subroutine declaration, for instance
> >
> > sub Cmp:infix($$){
> > return uc($_[0]) cmp uc($_[1])
> > };
> >
> > implicitly sets up a "catch unknown-keywo
Well then. It is impossible to rearchitect it to make it shared
text? Perhaps the first instance of perl sets up some vast shared
memory segments and a way for the newcomers to link in to it and look
at the modules that have been loaded, somewhere on this system, and use
the common copy?
Sam Tregar wrote:
>
> On Tue, 29 Aug 2000, David L. Nicol wrote:
>
> > Well then. It is impossible to rearchitect it to make it shared
> > text? Perhaps the first instance of perl sets up some vast shared
> > memory segments and a way for the newcomers to link i
Nick Ing-Simmons wrote:
> We need to distinguish "module", "overlay", "loadable", ... if we are
> going to get into this type of discussion. Here is my 2ยข:
>
> Module - separately distributable Perl and/or C code. (e.g. Tk800.022.tar.gz)
> Loadable - OS loadable binary e.g. Tk.so or Tk.dll
>
Dan Sugalski wrote:
>
> Don't forget the fixup work that needs to be done afterwards. Loading the
> library into memory's only the first part--after that the loader needs to
> twiddle with transfer vectors and such so the unresolved calls into the
> routines in the newly loaded library get resol
Nick Ing-Simmons wrote:
>
> David L . Nicol <[EMAIL PROTECTED]> writes:
> >"overlay" is reminiscent of old IBM machines swapping parts of the
> >program out because there isn't enough core.
>
> Which is exactly why I chose it - the places these thin
Dan Sugalski wrote:
> >
> >Oh, and then they will be unloaded if we need the space for something
> >else. I understand now, thanks.
>
> Well, probably not, though that could be reasonable for a particular
> platform. It's only relevant for a persistent interpreter anyway--for ones
> fired up fr
Ken Fox wrote:
> Trolling?
No, I'm not, it's the direction that RFC 61 ends up if you let it
take you there.
fast perl6 becomes, as well as slicing, dicing and scratching your
back, a drop-in replacement for gcc.
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
Dan Sugalski wrote:
>
> Okay, here's a list of functions I think should go into variable vtables.
All the math functions are in here. Can the entries that my type does
not use be replaced with other functions that my type does use?
> Functions marked with a * will take an optional type offset
Ken Fox wrote:
> . The real problems of exception handling, closures, dynamic
> scoping, etc. are just not possible to solve using simple C code.
>
> - Ken
I'm not talking about translating perl to C code, I'm talking about
translating perl to machine language.
C is babytalk compared to Perl,
Dan Sugalski wrote:
> We're shooting for speed here. Any common operation that could be affected
> by the type of the variable should be represented so a custom function can
> be called that does exactly what needs to be done.
>
> Dan
so if I want to make
Dan Sugalski wrote:
> I do want to have a set of C/XS/whatever sources as part of the test suite
> as well--right now perl's test suite only tests the language, and I think
> we should also test the HLL interface we present, as it's just as
> important in some ways.
I want to see Perl become a f
David Corbin wrote:
> A C JIT is an interesting idea.
>
> I think that a project works best when it has a set of goals (I haven't
> seen one yet really for Perl 6). Unless this is one of the goals, I can
> easily see how this could become a serious distraction to what I
> perceive as the like
Dan Sugalski wrote:
> If anyone's got any arguments in a particular direction, now would be the
> time. Once we're done wrangling, we'll start in on the features we need to
> write into the PIL translator, and get implementation of that started.
>
> Dan
Dan Sugalski wrote:
> 1) How fast is the C (or whatever) code it emits likely to be?
The perl-in-perl interpreter would not be a deliverable. Speed would
not be its goal. It would be a reference implementation that would be
easier to break and repair. An internals tutorial, if you will.
So
Simon Cozens <[EMAIL PROTECTED]> formally RFC'd:
> I have no idea how to implement tail recursion elimination, and I'd
> dearly love to learn. Unrolling loops with constant indices shouldn't be
> too hard.
AIUI you trigger your destructors on the appearance
of the "return" keyword rather than
Michael G Schwern wrote:
> Also, just being able to tack flags onto a variable means each
> variable (that has a flag) would have to carry around a hash!
Or it could mean that every new flag is associated with a hash of
names of things for which it is set -- in which case
$something:at
Dan Sugalski wrote:
> If there's no hit, I'd love to have all perl functions callable from
> outside. I'm not sure that'll be the case, though I'm all for it...
With the 334 infrastructure, the -o option to generate a linkable object
from a perl program/library (RFC 121) will be most do-able: "s
Dan Sugalski wrote:
>
> At 08:57 PM 10/12/00 +0100, Simon Cozens wrote:
> >On Thu, Oct 12, 2000 at 03:43:07PM -0400, Dan Sugalski wrote:
> > > Doing this also means someone writing an app with an embedded perl
> > > interpreter can call into perl code the same way as they call into any C
> > > li
Simon Cozens wrote:
> This would have to take account of the fact that Perl's tokeniser is
> aware of what's going on in the rest of perl. Consider
>
> print foo;
>
> What should the tokeniser return for "foo"? Is it a bareword? Is it a
> subroutine call? Is it a class? Is it - heaven forbi
Steve Fink wrote:
> It's standard semantic analysis. Both your taintedness analysis and my
> reachability analyses can be fully described by specifying what things
> generate the characteristic you're analyzing, what things block (in the
> literature, "kill") it, and the transfer rules. It's ofte
Anyone remember when I posted the top level of a language
prototyping environment? Well, that system has now grown a
lexical parser that can understand arbitararily deep doublequotes,
and I'm working on a perl5 into perl5 capability for it.
Is there a way to determine if a word is defined a
Dan Sugalski wrote:
>
> At 10:14 AM 1/2/01 +, David Mitchell wrote:
> >Nick Ing-Simmons <[EMAIL PROTECTED]> wrote
> > > BigFloat could well build on BigInt for its "mantissa" and have another
> > > int-of-some-kind as its exponent. We don't need to pack it tightly
> > > so we should probably
http://www.eros-os.org/pipermail/eros-arch/2001-January/002683.html
Simon Cozens wrote:
>
> On Tue, Jan 16, 2001 at 08:49:57PM +, David L. Nicol wrote:
> > http://www.eros-os.org/pipermail/eros-arch/2001-January/002683.html
>
> Uhm. That's not *why* they're doing it, it's how they're doing it.
> Did you get th
"Deven T. Corzine" wrote:
>
> On Sat, 23 Dec 2000, Graham Barr wrote:
>
> > This has been discussed on p5p many many times. And many times
> > I have agreed with what you wrote. However one thing you did not mention,
> > but does need to be considered is
> >
> > func($x{1}{2}{3})
> >
> > at th
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 puller before the C preprocessor gets to
the code, or f
I think "defined" should be altered so that it only looks like a function,
but in effect alters the tests being made by the thing that is looking at it.
if (defined $x){ # slower than if ($x){ # or if($x or defined($x))
could be made faster by propagating the "defined" question up the
David Mitchell wrote:
> 4. Are we all agreed that in addition to anything else (eg rfc281), at
> least some of the standard commentary should appear actually within the
> src file itself?
s/at least some/most, if not all/
> 5. Do *all* these comments need to be extractable, or only ones related
Simply Hao wrote:
> > Douglas Adams does seem rather more appropriate a source of quotes
> > for software (anyone's, alas) than Pratchett.
>
> But Adams already has a software company.
And Sirius pioneered the GPP in Perl 6.
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
Bart Lateur wrote:
>
> Er... may I suggest ratio's as a data format? It won't work for sqrt(2)
> or PI, but it can easily store 1/3 as two (long) integers. You can
> postpone doing integer divisions until you need a result, at which time
^to stri
Uri Guttman wrote:
> i was looking at dan's PMC arena allocator struct and it reminded me of
> something an older language can do (which MJD has likened to an early
> perl :). ever heard of AREA in PL/I? it was a large chunk of ram
> dedicated to allocate memory from. what was special is that all
Dan Sugalski wrote:
> >2) Anyway, even resizing vtables we would need some more indirection to
> >determine in which position of the vtable is which operator.
>
> No. Each operator goes in a fixed position in the vtable, and it's the same
> for each table. Anything else is nasty, error prone, an
Dan Sugalski wrote:
> >What if the decision in-vtable or not-in-vtable is deferred?
>
> That's doable, I think, though I can see some issues.
how about a two-tiered vtable, where a single high bit, if set,
indicates extended handling, or at least consultation of
a different table.
I guess th
Dan Sugalski wrote:
> >
> >We don't have continuations yet...
>
> But there's nothing at the lowest levels of the interpreter that prevent
> that. You could, if you chose, get a stream of bytecode that would do you
> continuations. Slowly and awkwardly, perhaps, but still do them. (I'm all
> up f
Damien Neil wrote:
>
> sub foo {
> my Dog $spot = shift;
> my $fh = IO::File->new("file");
> $spot->eat_homework($fh);
> }
>
> Even with the object type declared, the compiler can make no
> assumptions about whether a reference to $fh will be held or not.
> Perhaps the Poodle sub
"David L. Nicol" wrote:
i'm swearing off sort-by-subject. Sorry.
82 matches
Mail list logo
