ctuffli / close Goto Github PK

This code:
{{{
class POST::Compiler
    extends PCT::HllCompiler
    :phylum(P6object)
{
    # Class init code. (Should go into init_class_Compiler)

    POST::Compiler.language('POST');
    POST::Compiler.stages(split ' ', "pir evalpmc");
}}}

presents several "Compiler not defined in current scope" errors.
Apparently, the open-class-block code does not have the symbol definition
for POST::Compiler. 

Phylum processing needs to happen earlier, so the symbol can be added to
the global namespace.

What would you like added?

Some kind of optional-parameter sugar.


How should it work?

Either via builtin function, syntactic sugar, or predeclared parameter.

Pmc vars can contain 'Sub' pmcs, which are effectively function pointers.
There needs to be a way to invoke them, with an arglist.

Consider:

void f() {...}
pmc funcptr = asm {{ %r = get_hll_global 'f' }};

str a = "a";
int b = 1;
pmc c = new FileHandle;
pmc args = new ResizablePMCArray;
push args, a, b, c;

pmc result = asm(funcptr, args) {{ %r = funcptr(args :flat) }};

A similar scenario holds true for method and vtable calls.

Doing a lookup of the underlying PMC is pretty clearly the PVM equivalent
of the address-of operator. So:

void f() {...}
pmc funcptr = &f;

And then dereferencing the pointer is C-like:

pmc result = (*f)(a, b, c);

One issue is that there is not explicit * in the declaration of funcptr,
because pmc is a type that implies pointerness. OFW. The same is true for
arrays and hashes, as currently implemented. It might make sense later to
allow the function-pointer-declaration syntax to imply "Sub pmc"

What would you like added?

The standard C 'switch' statement, or something like it.

This is a "nice-to-have", so low priority. Anyone interested is welcome to
jump in.

How should it work?

    switch (i) {
    case 1:   say("one"); break;
    case 2:   say("two"); fallthru; # NOTE: Why not make it a keyword?
    default:  say("huh?");
    }


Please provide test cases, if possible.

Please use labels and text to provide additional information.

What steps will reproduce the problem?
This code does not get stored in the init_* block of either nsp or class.
{{{
class Foo ...
{
   extern int foo  = 0;
}
}}}

What would you like added?

Addresses, or second (or first)-class functions.

How should it work?
{{{
   pmc fp_list = [ test1, test2, test3 ];

   foreach (pmc fp : fp_list) {
      (*fp)();
   }
}}}

Please provide test cases, if possible.

Please use labels and text to provide additional information.

What would you like added?

PCT wants to look for, and if possible to call, methods based on hash keys.
{{{
foreach (str key : hash) {
   pmc method = find_method self, key;
   if (method) {
      call_method self, method, hash[key];
   }
}
}}}

How should it work?

See above.


Please provide test cases, if possible.

Please use labels and text to provide additional information.

It should be possible to put typed literals in line in Close code:
{{{
pmc a = {1, 1, 2, 3, 5, 8};
pmc foo = ResizableStringArray: { "foo", "bar" };
}}}

If a user-specified type is given, the correct construction is to create a
new object and then call a series of setters on it:

{{{
pmc foo = Klass: { a: 1, b: 2};

# Becomes...

pmc temp = Klass.new();
temp.a(1);
temp.b(2);
pmc foo = temp;
}}}

Because if the class could accept a hash/array constructor, the user could
code:
{{{
pmc foo = Klass.new( { a: 1, b: 2 } );
}}}
And the default-hash literal constructor would work fairly well.

What would you like added?

Array and hash indices should use Key pmcs to access.

How should it work?

arr[i, j, k] should build a PMC Key, then push the various expressions, then
call get_keyed (or exists, or delete, or whatever).

What would you like added?

The parser should insert local decls in the local-variables subnode at the
start of the block.

Variable initialization, which is currently handled as a viviself, should
be handled as a standard assignment/binding to the so-far-unused variable.

How should it work?

Please provide test cases, if possible.

Please use labels and text to provide additional information.

What would you like added?

The standard 3-part 'for' loop from C.

This is a "nice-to-have" item, so low priority. Anyone wanting to
contribute is welcome to jump in.

How should it work?

    for (int i = 0; i < 10; i++) {
        say(i);
    }


Please provide test cases, if possible.

Please use labels and text to provide additional information.

What steps will reproduce the problem?

From PCT::Node:

{{{
    pmc obj = self.HOW().parrotclass;
}}}

What is the expected output? What do you see instead?

Fails to compile - syntax muddle.

Please use labels and text to provide additional information.

Need 'clone' builtin to provide access to Parrot opcode.

{{{

   pmc org; pmc dup;

   dup = clone org;

}}}

What steps will reproduce the problem?
1. pmc obj = anything;
2. pmc obj = obj.HOW();


What is the expected output? What do you see instead?

Should error because redeclaring obj, but accepts.

Please use labels and text to provide additional information.

What steps will reproduce the problem?

    pmc f(pmc children ...) 
        :method
    {
        pmc foo;

        push foo, shift children;
    }

Change to:

    pmc f(pmc children ...)
        :method
    {
        push self, shift children;
    }

What is the expected output? What do you see instead?

Should reference automatically defined 'self' parameter. Doesn't recognize
it at all. Probably no entry in block symtable.


Please use labels and text to provide additional information.

What would you like added?

Tailcall builtin/keyword

How should it work?

{{{
    sub foo()
    {
        tailcall othersub(1);
    }
}}}

Please provide test cases, if possible.

Please use labels and text to provide additional information.

After having just typed the same test code six bajillion times for testing
various PCT methods, I really think some kind of template mechanism would
be sweet.

The obvious low-hanging fruit for this stuff is just the C preprocessor. If
the CPP in the languages/c99 project works for this, it might be a decent
starting point. (And in fact, some kind of #include is needed regardless.)

Beyond that, though, it would be nice to have a C++ -like templating system
for classes and for plain old code.

What steps will reproduce the problem?
1. extern [ :: '$?HLL' ] = new String;

What is the expected output? What do you see instead?

This should compile, etc, but throws an error immediately. I suspect that
long_ident is not handling this correctly.

Close supports declaring strangely named symbols, like "$!LINE" but it
would be nice if an alias could be declared ("line") so that it's easier to
type in code.

The 'isa' builtin just doesn't work right. I think maybe a new production,
"classname" or some such, is needed to get it straightened out.

Possibilities include:

  * isa var, Class::Name    # bareword
  * isa var, "Class::Name"  # in a string
  * isa var, other_var      # class object in a var
  * isa var, string_var     # string in a var

Revise wiki pages. 

Make closeintro more intro, less diatribe.

Create some how to code pages

What would you like added?

"global" code, like initializations, should have a defined order. Ideally,
one which somehow accounts for class initialization.

How should it work?

extern Some::Class::Name;
pmc Class_handle = Some::Class::Name; # SHould not be null.

Please provide test cases, if possible.

Please use labels and text to provide additional information.

What would you like added?

Need support for :flat, :named adverbs in function calls (expressions).

How should it work?

{{{
    obj.init(children :flat, adverbs :flat :named);
}}}

Please provide test cases, if possible.

Needed for PCT::Node

Please use labels and text to provide additional information.

Add/increase support for namespaces:

1. Closed namespaces don't inherit from underlying namespaces.

namespace Foo {
   int a;

   namespace Bar :closed {
      say(a);    # Error: 'a' undefined.
   }
}

2. Namespace aliases enable shortening paths:

namespace Foo::Bar::Baz { int z = 3; }

namespace Z = Foo::Bar::Baz;    # Create 'Z' alias for Foo::Bar::Baz

say(Z::z);   # 3

3. Anonymous namespaces are unique to the compilation & compilation unit,
but are consistent:

namespace { int x = 7; }

int x = 1;

namespace {
   say(x);   # 7, because "anonymous" namespace x masks ::x
}

Need a way to identify this namespace in code. Something like ":: ::x" maybe?

Node that in nested namespaces, the anonymous namespaces are unique
nesting-wise, but still the same if the path is the same:

namespace A {
   namespace {
      int x = 1;
   }
}
namespace B {
   namespace {
      int x = 2;
   }
}
namespace A {
   namespace {
      say(x); # 1
   }
}
namespace B {
   namespace {
      say(x); # 2
   }
}

It is open for discussion whether an anonymous namespace can be reopened at
a different time -- that is, if two namespace {} in two different files, or
the same file at different times, lead to the same block.

4. Create 'standard' namespaces:

Python has two standard modules 'sys' and '__builtin__'. C++ uses 'std' and
C# uses 'System'. Close should provide a similar set of things.

5. Add 'using' declaration for namespaces:

using namespace N;

Should add the N namespace to the current symbol search path (read-only).

using N::f;

Counts as an explicit declaration of 'f', rather than modifying the search
path. Creates an alias in the current block linked to the other symbol.
(Still need the other block, for the link, but it's not [necessarily] in
the search path.)

See also #13.

Close needs to be able to dynamically look up and call or instantiate type
or symbol names.

That is, 
{{{
str type = "Hash";
pmc object = new type;

str func = "main";
(*func)();

str varname = "foo";
int i = PCT::Var::(*varname);

str method = "bark";
pmc spot = new Dog;
spot.*method();
}}}

What would you like added?

On class declarations, support :phylum(...) to describe meta-object
protocol to use for creating class and instance objects. Known values
should include "close" (default), "P6object". Possible extra values
"Python" and "protoobject"

How should it work?

class Foo
    :phylum('P6object')
{...}

Please provide test cases, if possible.

PCT::Node rewrite needs this. 

Please use labels and text to provide additional information.

This may be syntactic sugar, or a builtin function, or a RTL function. It's
not clear what the right answer is.

But at runtime, be able to use a file name, or an abstract syntax
(Foo::Bar), or a filehandle, or a bytecode pmc.

FROM module-identifier IMPORT decl-name-pattern AS alias;

FROM module IMPORT *;

IMPORT module AS alias ;


Some of this has to depend on how the remote compiler works. But in
general, "import module" should get the default symbols -- the @EXPORTS or
whatever. While IMPORT * would get EXPORT_ALL. 

Alias mapping is into the current namespace, or into a namespace specified
via :namespace(foo) adverb. 

Since this is at runtime, and I'm not clear on how that's going to work,
this is kind of open-ended.

What would you like added?

PCT::Node needs to be able to extend Capture. 

How should it work?

class PCT::Node
    :parent(Capture)
    :phylum(P6object)
{...}

Please provide test cases, if possible.

Please use labels and text to provide additional information.

What steps will reproduce the problem?
1. Create a namespace Foo; block before a class decl
2. Add initializer, plus some executable statements (more initializers)
3. Breakage.

What is the expected output? What do you see instead?


Please use labels and text to provide additional information.

What would you like added?

The builtin 'new' keyword should support more than inline class names.

How should it work?

{{{
   new_object = new expression_returning_a_class_pmc_or_string_name();
}}}

Please provide test cases, if possible.

Please use labels and text to provide additional information.

{{{
class C {
  void greeting() :method { say("Hello, world"); }
}

void main() :main {
  pmc c = C.new();
  c.greeting();
}
}}}

This should print Hello world, but instead fails because 
  {{{
  Method 'greeting' not found for invocant of class 'C'
  }}}

Apparently, the P6object new_class doesn't do quite enough. There may
be a methods arg, or maybe I need to just generate addmethod calls either
on the class object or on the proto.

What would you like added?
Split builtin

How should it work?

arr = split '::', "Foo::Bar";

Please provide test cases, if possible.

Please use labels and text to provide additional information.