DP6

Perl Compiler Toolkit

2008-01-03T12:40:00.000-06:00

I have been following the development of Perl6, and I think I may be able to use parts of the Perl Compiler Toolkit to implement my ideas for DP6.

One Input Many Outputs

2007-05-28T17:16:00.001-05:00

I want the design of the language to be designed in a way that would allow you to include one file to output in one format, and another to output in another format.

I also want it to work in such a way that an Enum can be made to generate a Value -> NameStr subroutine, or NameStr -> Value subroutine easily.

I think I will wait to try to create an implementation

2007-04-13T09:02:00.001-05:00

Perhaps it is too early in the design process to try to come up with an actual implementation. I still haven't decide on all of what will be included.

I am currently trying to create a layer over Nasm

2006-09-26T14:38:00.000-05:00

I have decided that my first attempt, at creating a workable programming language, will be to create something similar to a translator. This hopefully will allow me more freedom to create, and redesign the language, in a rather short period of time. As a side note I would request any suggestions, for creating a compiler, or designing a language.

New Idea

2006-02-24T15:35:00.000-06:00

What the plan is now for DP6 is for it to be aimed for the assembly type of solutions, but with enhancements from other languages. One idea I have is for the ability of modifying most of the supported sub-languages while the current program is compiling. This of course is an idea copied from Perl. I also want to create macros that will work in almost all sub-languages. Planned sub-languages may include Python, Perl, and a dirivitave of D.

I also want to be able to have most of the languages to support a common scanner, perhaps it could be an event based scanner. If the sub-languages support the same scanner, it will be easier to build.

Basically DP6 will become more of a glue language of different languages, in a hopefully transparent way.

DP6 listed on Langa List's reader sites

2006-02-24T15:25:00.000-06:00

Full List

Random Reader Site
<

For all of you who don't know The Langa List is an e-newsletter sent out by Fred Langa.

Reason for DP6

2006-01-17T15:11:00.000-06:00

I have been interested in programming, and computers since I was about 12. At first it was batch programming. Then I found a better language contained inside MS Word for Windows, called "Visual Basic For Applications"(VBA). Sure it was fairly simple, but it was a better language than batch programming. Soon after I learned that I found out about a programming language called Perl. I realized quickly that it could easily do almost everything that VBA could do, and there was something that VBA could not easily do that Perl could easily do, Regular Expression.

Now I realize that some people don't like the way that Perl5 looks, but I think most of that will all but disappear when Perl6 gets fully implemented.

I also liked digging into the heart of systems, be it hardware or software, so I wanted to learn more about how real machine-coded programs were developed. Well since C/C++ is the language that is used most for this, I started to learn about how to program in that language. It didn't take me long to realize just how complicated a language it had become since it was created, near the end of the 60's (I think). I wasn't even born until 1982.

I don't remember how I found out about "D", but it certainly seems to be a step in the right direction when compared to C/C++. Since I had learned Perl before I learned "D", I kept trying to do programming idioms that I have become familiar to doing in Perl.

When I read about Perl6, and how it was going to be designed. I decided that I wanted to try creating a programming language that was low level like C, but had some of the useful features from Perl and "D".

I hope that this turns out to be useful enough, that it could be used for Operating System programming, as well as be a fairly easy programming language to learn.

data revisited

2006-01-17T14:44:00.000-06:00

Ok I admit it I don't know an easy way to specify a data format easily. So for now at least forget all about "data".

Plus it's possible it could be done through a macro (Perl6 macro).

"data" Structures

2006-01-01T15:14:00.000-06:00

Please note the following is just a starting point of the design process.

alias D_Static_Array(char,3) to char[3];
alias D_Static_Array(char,3,4) to char[3][4];

# this will catch all char[3] char[3][4]
# brings out the aliases from inside of the data template
import D_Static_Array( 'char', / char [ \[ $d := (\d+) \] ]+ / );

# this will catch all static array types
import D_Static_Array( / [ \[ (\d+) \] ]+ / );

# please note that increasing the value of .length at runtime
# won't allocate more memory it will just make the program think it
# has more data to work with. So it wouldn't be a good idea to do
# that in most cases.
data D_Static_Array(type $ident,uint $size = 0){

# uint{0} refers to a uint starting at byte offset 0

# readonly means that only this and anything
# that subclasses this can change it (could also be spelled "r").
readonly uint{0} .length = $size;

# you could also spell ".length" as "->length" if you prefer Perl5
# that would mean you would have to rename all instances of ".length".
# the reason you can do this is because all you need is a word boundary
# to be created between the "data" and ".length"

# ".data" will grow and shrink depending on what
# the value of ".length" is at the time you ask for it
# because of the bind ":=" in the definition.

# This also won't allow you to change the length of ".data"
# outside of this class because ".data.length" is bound to ".length".
rw $ident[ _ := .length ]{.length.sizeof} .data;

# this is for retrieving the value at $index
INDEX(uint $index){

uint $pos = $index * $ident.sizeof + length.sizeof;
return $ident[$pos];

}
# this is for determining out of bounds errors
SIZE{

# the size grows and shrink depending on
return (.length + .length.sizeof) * $ident.sizeof;
# or
return (uint{0} + uint.sizeof) * $ident.sizeof;

}

}

data D_Static_Array($ident,@sizes){

# note this "data" will keep another variable around
# to know how long the array ".length" is.

readonly uint[@sizes.length]{0} .length = @sizes;

# note the bind goes recursively through mult because
# it is a keyword.
uint .data_size := mult( @{.length} );

# ".data_size" needs to be bound because the variable it depends
# on can be changed, and there should be a way to propogate it on
# to ".data", it is not enforced, but highly recommended.

readwrite $ident[ _ := .data_size ]{ _ := .length.sizeof } .data;
INDEX( ){

}
SIZE{

return .length.sizeof + .data_size;

}

}

this is what it would do

# array of four arrays of 3 char each.
D_Static_Array(char,3,4)
{

.length = [4,3];
.data = [char,char,char, char,char,char, char,char,char, char,char,char];

}

Potential Issues with compilation

2005-12-01T09:31:00.000-06:00

I have been thinking about how the language will handle object files. Since the language will allow significant parts of the language to be figured out at the point at which it is used. I think that the source files may be required to be included with library files.

It also may be possible that whole projects get compiled all at once. I know that it won't take extreme excess of time to compile whole projects, as it doesn't take D very long to compile whole projects at once.

One thing I would like to be able to do is have programs that will work, on say Linux and Win32, without recompiling. Or barring that, at least be able to have it use advanced features of the current processor, but still be able to run correctly on less sophisticated processors.

Subroutines / Functions

2005-11-02T02:16:00.000-06:00

NOTE: I am not sure how functions/subroutines will be defined, as the following will show. So the actual design may, or may not, resemble anything in this post.

Functions/subroutines will probably be very different than what most people would be used to.

For example, I want to be able to define two functions that return two different types of data, but have the same parameters.

int main(){ return 0; }
char main(){ return "0"; }

I always like being able to have two different things returned depending on the context, when working in Perl5.

There will be times where it would be impossible to do this, but mainly it would only be when calling functions from libraries, or when implementing outside.

I also want to be able to have subroutines that don't have any particular return type, but that would automatically be converted the way you think it would.

sub main(){ return 0; }

char c = main();
int i = main();

The arguments for these functions will also come in several different flavors. There of course be functions that take only certain types of values, and also some that take in a varying number of arguments that are all of the same type, and still others that will take varying types.
sub main( int i ){...}
sub main( @int args ){...}
sub main( @ args ){...}

String Management

2005-11-02T01:36:00.000-06:00

I plan on having the ability to work with strings without necessarily knowing how they are encoded, and I want to be able to easily convert between different encodings.

The way this could be handled may be similar in design to the way Parrot handles strings. It probably should have a way to implement this functionality in a pluggable way.

It might need to be integrated with IO handling, which I also plan on having higher level constructs.

I hope that it would be simple to read in different encodings and slmost never having to dealing with the minor details.

Module naming scheme

2005-10-26T23:19:00.000-05:00

I have been trying to create an interpreter for DP6 in D, and one of the annoying things I have found, is that you can't have a module with the name io, and one with the name io.file. There is a good reason for it, since if you have a class with the name file, in the module io that would cause name collisions.

So what I'm planning fo DP6 is that the module heirarchy will use double colons like Perl. Then io and io::file couldn't possibly have name collisions, because the class file in the module io will be addressed by io.file.

I also like the way you can switch modules in Perl. So I am conidering allowing a module switch packages. It really depends on whether that could cause a bunch of headache when writing a compiler.

Struct will have members

2005-10-22T13:51:00.000-05:00

I like the idea of having structs that act in a similar way to that of normal objects, similar to the D way.

struct Test{
int $a;
sub a( $this, int $new ){
$a = $new;
}
}

Test test;
# following are equivalent
test.a(5);
test.a = 5;

The way that Perl6 handles public/private data, will also be included.

class Test{
$a is readonly;
$b is rw;
}

Perl6 style macros

2005-10-22T13:42:00.000-05:00

There will Perl6 syle macros to allow the language to be modified to suit the users needs.

This would require that at least some of the code has to be runnable before it gets completely compiled. I would suspect that the compile time code will run at a much lower speed. I think that this would allow D style version( ) statements to be able to be included, without hard coding it into the parser.

I find that there are times were I want to change how the program is parsed, so that I can do the same thing to different types of data, without retypeing it. D does to some extent, provide these facilities, but I want to take it farther.

Garbage Collector

2005-10-13T09:21:00.000-05:00

All Modules will be able to turn on or off the Garbage Collector for itself, and be able to suspend the Garbage collector on behalf any module, or even globally.

Modules will also be able to select which Garbage Collector gets used for objects that it generates.

The Garbage Collector will be turned on by default for every package, but no Garbage Collector in particular will be selected.
use GC;
use GC 'any';

If the program selects a particular GC to use, it will be used by any modules that doesn't specify which GC it will use.
use GC 'system';
use GC GC::system;

A module will be able to turn off all GC's, for itself. The reason for this is that a programmer could then write a GC as a module.
no GC;
Doing a no GC; inside of a block will turn it off for that block

All GC's will be required to handle self referencial data structures correctly.

Whenever the GC is turned off the compiler will make sure an object is deleted when the block is exited. The programmer may put a delete in the block so that the object gets deleted early. If the programmer is giving a reference to some other subroutine, there will be some way of preventing the object from being deleted, how this will work I'm not sure.

Note: the way I have designed the way GC's are used there will have to be some way of using an object with more than one GC at a time, again I am unsure of how this will be accomplished, but I am confident that it can be done.