regrettably this project must be postponed until atleast the new year and probably summer due to my limited knowledge of asm - yes i said assembler.
for the next step i had originally thought that i could rewrite in c the runtime for a faster implementation and access to a more diverse toolchain, however that method is inherently limited. to be able to utilize to the fullest extent the capabilities of syntax driven programming it has to start from scratch.... for now. if you've analyzed in depth the past releases you'll see something of a blind attempt at automating the design and implementation of a programming language by use of a modular syntax tree. if you've read atleast the release notes there are outlined in some a start at the meta-grammar for the compilation process. by using this method of automating language design and development i believe it is most practical to start from the ground up and incorporate as much salvagable code as possible starting from the lowest level. although c has obvious value as a cross-platform-ish language with a wealth of libraries, it would be a mess to try and incorporate a paradigm designed for amorphic interpretation with compiler tools designed for ad-hoc compilations. that's why i originally pursued a fully abstracted script but ultimately it all boils down to the same opcodes and i'd just be fooling myself otherwise. soOoOOoo as it stands
i can't continue the project until i learn how a computer works, haha. in the meantime if anyone else is well versed in compiler construction and enjoys migraines, frustration, and utter bewilderment be my guest. if anyone is interested in this project at all and can't get past the complete lack of documentation post something or email me. believe me there IS method to this madness, gomenne
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
--edit-- the compiler will still remain abstracted from the code produced. i may or may not eventually make a streamlined version for my own purposes but that has no place here
top level grammar has been finalized. I'm going with an atomic structure to simplify things and remove all the ambiguities that would happen otherwise. the atom feed will still be delegated but atom to atom rather than letter to letter. there will be no direct support for multi-char operators but they can be built from the backend pretty easily. this removes the ambiguous interpretation of a=+b as a.=+ b or a.= +b.
operators from the standard charset will be given secondhand status like in python where 'bandc' does not evaluate to 'b and c'
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
hmm guess i forgot to talk about 'more widespread applications' in this thread, so i'll try to explain my small understanding of what this project is.
this project is an experiment in flexible grammars.
why does a(a) have to send itself as an argument?
the goal of this project is to provide a means for a programmer to change the compiler behaviour on a small scale to for example allow a(a) to use the argument as it stands in string form to print 'a'. a more practical example is to manipulate the fully delegated portions of code (..)[..] and {..}
to create small-scale language features designed for that purpose alone.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
regrettably this project must be postponed until atleast the new year and probably summer due to my limited knowledge of asm - yes i said assembler.
for the next step i had originally thought that i could rewrite in c the runtime for a faster implementation and access to a more diverse toolchain, however that method is inherently limited. to be able to utilize to the fullest extent the capabilities of syntax driven programming it has to start from scratch.... for now. if you've analyzed in depth the past releases you'll see something of a blind attempt at automating the design and implementation of a programming language by use of a modular syntax tree. if you've read atleast the release notes there are outlined in some a start at the meta-grammar for the compilation process. by using this method of automating language design and development i believe it is most practical to start from the ground up and incorporate as much salvagable code as possible starting from the lowest level. although c has obvious value as a cross-platform-ish language with a wealth of libraries, it would be a mess to try and incorporate a paradigm designed for amorphic interpretation with compiler tools designed for ad-hoc compilations. that's why i originally pursued a fully abstracted script but ultimately it all boils down to the same opcodes and i'd just be fooling myself otherwise. soOoOOoo as it stands
i can't continue the project until i learn how a computer works, haha. in the meantime if anyone else is well versed in compiler construction and enjoys migraines, frustration, and utter bewilderment be my guest. if anyone is interested in this project at all and can't get past the complete lack of documentation post something or email me. believe me there IS method to this madness, gomenne
--edit-- the compiler will still remain abstracted from the code produced. i may or may not eventually make a streamlined version for my own purposes but that has no place here
top level grammar has been finalized. I'm going with an atomic structure to simplify things and remove all the ambiguities that would happen otherwise. the atom feed will still be delegated but atom to atom rather than letter to letter. there will be no direct support for multi-char operators but they can be built from the backend pretty easily. this removes the ambiguous interpretation of a=+b as a.=+ b or a.= +b.
operators from the standard charset will be given secondhand status like in python where 'bandc' does not evaluate to 'b and c'
hmm guess i forgot to talk about 'more widespread applications' in this thread, so i'll try to explain my small understanding of what this project is.
this project is an experiment in flexible grammars.
why does a(a) have to send itself as an argument?
the goal of this project is to provide a means for a programmer to change the compiler behaviour on a small scale to for example allow a(a) to use the argument as it stands in string form to print 'a'. a more practical example is to manipulate the fully delegated portions of code (..)[..] and {..}
to create small-scale language features designed for that purpose alone.