prose-discuss Mailing List for PROSE Programming Language
Status: Pre-Alpha
Brought to you by:
cambridge
You can subscribe to this list here.
2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
|
Nov
|
Dec
|
---|
From: <Fre...@ao...> - 2004-09-12 11:45:28
|
John, It'll probably be clearer just how much BURS can help in the bytecode side of things once you see the kind of instructions that are available in PAL. When I have some more time I intend to start prototyping the instructions that I currently have in my head. The current examples at _http://prose.sourceforge.net/code.html_ (http://prose.sourceforge.net/code.html) are reasonably close to my vision but by no means final. You may be hitting upon a very interesting idea here, if we can convert both ways between PROSE and Java sources and bytecodes, we can instantly demonstrate the benefit of PROSE over Java and developers can painlessly translate from one to the other .... Hmm ... except while translating bytecode instructions is pretty simple, simulating the vast list of classes in the JRE is a whole big project in itself and not one I care to undertake. Unless we provide something like our own version of JNI that allows PROSE programmers to use Java classes ... that could be feasible. Yes Java has hierarchical namespaces, but there's the trick, namespaces plural. PROSE has one big namespace where you can get at everything. E.g. function test() { myvar = "test variable" myarray["key1"] = "test array element" // display contents of myvar print myvar // two ways of displaying the contents of the key1 element in myarray print myarray["key1"] print myarray.key1 } In the above example, the local variables can (if static variables) also be referenced as: prose.code.test.myvar prose.code.test.myarray["key1"] prose.code.test.myarray.key1 N.B. prose.code is just an arbitrary name at this time, I haven't settled on a final naming scheme yet (will probably include module name anyway). Also you'll set-up aliases so you don't have to list the fully-qualified path. Re your synchronisation question, it depends on the kind of operation and the kind of object. But my current idea is that PROSE should automatically synchronise where it is a no-brainer (e.g. multiple threads accessing the same object where at least one is writing), and otherwise use a keyword to force synchronous access to a particular function. I'm not sure allowing code blocks to force synchronous access helps anyone, and in my experience only creates a prime scenario for bugs that are much harder to track down. Have you had any more thoughts yourself? Regards, Mark. In a message dated 08/09/2004 23:34:59 GMT Daylight Time, JDMcMullin writes: Mark, Just logged in to pick up email. To reply:- 1) I need to check at sourceforge for the PROSE-Discuss mailing list on how to join. 2) BURS should be able to help with a JIT compile from "bytecode" to machine code. The fun is in creating the "grammar". I expect that the PROSE compiler to "bytecode" would use 1 BURS grammar and the JIT compiler ("bytecode" -> machine code would use a different BURS grammar. I suspect that each target machine would need its own individual BURS grammar. (Costs of re-write rules may be different for different machines). 3) Noting (2) means we don't need to exclude Java bytecode. As we could have a JIT from "bytecode" to Java bytecode! Remember, a single "bytecode" instruction will probably translate to a number of machine instructions (or even Java bytecodes) 4) I need to re-read the PROSE hierarchy explanation. Remember the package concept in Java is there for namespace hierarchy and object visibility. Your vision of the hierarchy having entities (variables, arrays, plug-ins + nodes on the network) is akin to the Java view about classloaders. They form a tree hierarchy as well, but based within a single JVM. Although the use of RMI (Remote Method Invocation) may extend this to JVM's on other nodes, (or even another JVM on the same node). Question - what about synchronisation of objects in the PROSE hierarchy when accessed from multiple nodes? I'm playing with the idea of implementing a BURS tool which generates PASCAL source code, it would then tie in with my parser generator (which generates PASCAL source). So PROSE + PAL would then be a good test for the two tools. All the best, John ----------------------------------------- Mark R.Bannister, Author, Programmer, I.T. Consultant and Musician. Email: ma...@fr... Website: www.freedomware.co.uk ----------------------------------------- |
From: <Fre...@ao...> - 2004-09-06 12:27:20
|
John, I've created a PROSE-Discuss mailing list, as I'd like these discussions to be archived for future reference. No one else is on the list except me right now, but feel free to subscribe if you like. Thanks for the further description of BURS, now I understand. I didn't realise anything existed that helped with the generation of machine code. Now this is where things get interesting with PROSE ... we have our own machine-independent bytecode. Ideally, in the long run, I'd like to do what Java does but with our own bytecode, i.e. a JIT-style compile to native machine code on-the-fly while interpreting the bytecode. Can BURS help with that? The reason we're not going to use Java bytecode is chiefly because the instructions are higher-level and quite different, they're used for traversing and maintaining an internal tree hierarchy and software plug-ins in different branches of the tree. The PROSE hierarchy is significantly more mature than the Java package structure. Everything in PROSE can be seen and manipulated hierarchically. Every function, every variable, every array, every plug-in, even other nodes on the network are attached to a large internal tree structure, and can be addressed as such. It is this addressing mechanism that I haven't discussed in the PROSE design specification, but which I probably won't be adding until I've run some POCs with the new prism assembler. Regards, Mark. In a message dated 05/09/2004 22:45:29 GMT Daylight Time, JDMcMullin writes: Mark, Lex + Yacc (or their equivalents flex, bison) are tools to assist with the front-end (ie lexical + syntax analysis). The grammar definition which is input to lex + yacc acts as a specification for the source code created which acts as the language recogniser. However no help is given (by Lex or Yacc) as to semantic analysis (ie type checking of entities in the language). Also, Lex + YACC give no help in the task of generating code for the target machine (ie Java Bytecode, Sparc, Intel Pentium or my favourite VAX). For a long time code generation in a compiler has depended on hand-crafted source code which was not easily portable/maintainable, due to instruction sets having many different instructions to do the same action. EG multiply by 2 Choice of 1- Left arithmetic shift by 1. 2 - use multipy instruction 3 - add same number to itself. Note, these methods for Multiply by 2 can have different costs (in register usage, machine cycles). BURS (Bottom Up Rewrite System) relates to this code generation phase within a compiler. That is the part where the machine code (or even bytecode) is generated from the AST (Abstract Syntax Tree). For a BURS code-generator, a grammar is defined which describes rewrite rules (akin to parser rewrite rules) BUT also include a cost for doing that rewrite. I recommend you look at the sourceforge pages for JBurg for more details. Hence, for the PROSE "compiler" you need to:- 1) recognise valid PROSE (as per its grammar) so use Lex + Yacc type tools to generate the recognise. 2) Then the "compiler" must validate the meaning of the PROSE (no tools here), 3) Finally the valid PROSE must be converted to "machine code" (this is the place for the BURS type tool). Moving on to your concerns over hierarchies. Do you want a hierarchy to be similar to the package concept in Java? So entities in the same package can have some visibility of each other. Is hierarchy there for limitations over visibility of objects and functions? I need to read up the latest spec re-your concerns over typeset -d for defaults. I'll read up when I get time - expect delay of at least a fortnight. As an aside I joined the mailing list All the best, John ----------------------------------------- Mark R.Bannister, Author, Programmer, I.T. Consultant and Musician. Email: ma...@fr... Website: www.freedomware.co.uk ----------------------------------------- |