Hello!
On Fri, Nov 20, 2009 at 09:39:13AM +0100, pugs-comm...@feather.perl6.nl wrote:
> -constant Dog $fido .= new; # okay: a constant Dog object
> -constant Dog $fido = Dog.new; # same thing
> -constant Dog $fido = $fido.new; # wrong: invalid self-reference
> -constant (Dog
Hello Pugs developers!
I tried to compile Pugs 6.0.10 with ghc 6.4 and got some error
messages. Fortunately they were not hard to resolve. I had to
do the following:
- remove getEnvironment from src/Posix.hs (it collided with
System.Environment.getEnvironment).
- not import the ful
Luke Palmer <[EMAIL PROTECTED]> writes:
> @A »+« @B # One-at-a-time
> @A «+» @B # Outer product
>
> Or something. Hmm, then both:
>
> @A »+ $b
> @A «+ $b
There is a page you may find inspiring:
http://www.ritsumei.ac.jp/~akitaoka/index-e.html
Sorry, I could n
Simon Cozens <[EMAIL PROTECTED]> writes:
> it was addressing a problem at too low a level. This could be because I'm a
> grouchy old-timer, and I carry over a Perl 5 design principle that says that
> changes should be made in as general a way as possible.
It's a very good principle, I think.
One
Simon Cozens <[EMAIL PROTECTED]> writes:
> % grep printf cvs/modules/**/*pm | wc -l
> 15
> % grep -v printf cvs/modules/**/*pm | wc -l
> 15360
>
> Well, 0.1% agreed, anyway.
Could also mean the current printf syntax is not too popular.
Reusable code is also less likely to use it than the
Austin Hastings <[EMAIL PROTECTED]> writes:
> Now, if you want to talk about the cool amazing formatting syntax
> you've conceived for sprintf replacement, that's fine. But I'm getting
> that warm cozeny feeling that this is burning unnecessary listmips.
Well, it's a bike shed. But it is a bike s
Edwin Steiner <[EMAIL PROTECTED]> writes:
> The rule could be like:
>
> \\F
After-afterthought:
We know: Everything between the \F and the next funny character is the
format specifier. This allows extensions to the printf-specifiers:
(These extension and more could al
Edwin Steiner <[EMAIL PROTECTED]> writes:
> Disallowing interpolated formats on \F has the additional advantage of
> making the {} unnecessary in the most common cases (also removing the
> 'force to string').
As an afterthought: This suggests getting rid of the {} ent
Luke Palmer <[EMAIL PROTECTED]> writes:
> As far as the syntax, the () and {} don't make a lot of sense with
> regard to the rest of the language. We could either utilize the
> string/numeric context distinction that already exists in {} and []
> for subscripting, or we could always use () in ana
Edwin Steiner <[EMAIL PROTECTED]> writes:
> "Leave some --\Fs60{space for this $interpolates string}--."
I'm sorry, this should be:
> "Leave some --\F60s{space for this $interpolates string}--."
Hello!
Recently I was coding Perl 5 and quite often I had to change
interpolated strings or C to C or .
I began to wonder, if qq strings couldn't allow sprintf-like
formatting directly.
I could imagine an \F escape sequence with the following syntax:
:'\F' printf-format-without-% '(' expr
If you think the ideas expressed in my previous post are sensible, I
can go through my "MakeMake" and put together a design document, about
what to seek and what to avoid, as far as I can tell.
Additional issues (not mentioned in my post) would be:
* usage of the front-end
* dire
Simon Cozens <[EMAIL PROTECTED]> writes:
> On Thu, Oct 11, 2001 at 03:24:31PM -0400, Dan Sugalski wrote:
> > 1) Build minimal perl 6 with default parameters using platform build tool
>
> But "platform build tool" is going to be 'make' - the alternative is
> that we maintain and ship every flavou
[EMAIL PROTECTED] (Simon Cozens) writes:
> =head2 C
>
> This field is, as its name suggests, unused; however, it can be used to
> hold a pointer to the correct vtable for foreign strings.
Wouldn't it be better to put a vtable * directly inside struct
parrot_string instead of the 'encoding' enum
Dan Sugalski wrote:
>
> At 11:57 AM 2/8/2001 +0100, Edwin Steiner wrote:
> >Dan Sugalski wrote:
> > > At 04:02 PM 2/7/2001 +, David Mitchell wrote:
> > > > > >Please see my previous post on the subject. As I pointed there,
> > > > imple
Dan Sugalski wrote:
> At 04:02 PM 2/7/2001 +, David Mitchell wrote:
> > > >Please see my previous post on the subject. As I pointed there,
> > implementing
> > > >|| and && like that breaks short-circuits.
> > >
> > > No, it doesn't. Just because you pass in two PMCs doesn't mean that they
>
Edwin Steiner wrote:
>
> Dan Sugalski wrote:
> [snip]
> > That's OK, since my example was wrong. (D'oh! Chalk it up to remnants of
> > the martian death flu, along with too much blood in my caffeine stream) The
> > example
> >
> >
Dan Sugalski wrote:
[snip]
> That's OK, since my example was wrong. (D'oh! Chalk it up to remnants of
> the martian death flu, along with too much blood in my caffeine stream) The
> example
>
> $foo{bar} = $baz + $xyzzy[42];
>
> turns into
>
>baz->vtable->add[NATIVE](foo, baz, xyzzy, key)
Branden wrote:
[...]
> Edwin Steiner wrote:
[...]
> > Different pointer types also make coding harder when there is no
> > need to make a difference between object types. (When you just pass
> > something on, for example.)
> >
>
> I actually see it as strong t
Branden wrote:
>
> Edwin Steiner wrote:
> > Branden wrote:
> > [...]
> > >
> > > I also don't see how it wouldn't bang badly if we get an incorrect PMC.
> How
> > > would we extract the 5th element of a scalar? And how would we read
Branden wrote:
[...]
>
> I also don't see how it wouldn't bang badly if we get an incorrect PMC. How
> would we extract the 5th element of a scalar? And how would we read one line
> out of an array? Sum two hashes? I think having only one vtable for all
> would only put a burden on who implements
Dan Sugalski wrote:
>
> At 05:02 PM 2/3/2001 +0100, Edwin Steiner wrote:
> >Might this be madness? (BRAINSTORMS AHEAD!):
>
> Generally, yes. :)
>
> The vtable stuff won't be exposed outside the core. This means embedding
> programs and extensions will *not*
Might this be madness? (BRAINSTORMS AHEAD!):
The API of the Perl data types could be specified
in the following way:
*) a class hierarchy (hopefully not a deep one).
eg.
AnyV (XV?)
|
-
| | | |
SV
Matthew Cline wrote:
>
> We might want to have a member/method by which we can tell what type of
> variable we're dealing with, so that a function can be passed an arbitrary
> XV, and treat it differently if it's an SV, AV, and so on.
>
> For SVs, we might want to have a method to determine what
Filipe Brandenburger wrote:
[...]
> struct sv {
> vtable_sv * ptr_to_vtable;
> void * ptr_to_data;
> void * gc_data;
> };
[...]
> I don't think I can get further from here. Note that, in all examples,
> I didn't write the `this' pointer that every funct
25 matches
Mail list logo
