Hi, you clearly have a lot of ideas for things that programming languages could do!
I'd like to clarify that V8's project goal is to implement an ECMAScript (a.k.a. JavaScript) and WebAssembly engine. It sounds like "Script 7" would be a new language, and as such would need a new engine. At this time, we don't intend to add a new language as one of V8's goals, and we also don't intend to implement any non-standard language extensions. Of course, you can start a new project to implement "Script 7", and you can start it with a modified copy of V8, if you think that's helpful. Also, I would like to encourage you to take another look at WebAssembly, as there seems to be some misunderstanding there. Wasm gets very close to your idea of wanting to encode specific machine instructions (e.g. for multiplying two registers), and it does so in a platform-independent manner, which addresses the issue you point out int your last paragraph: there are many different hardware architectures out there, and part of what's attractive about high-level languages is that the code you write is independent from the CPU architecture on which it might run later. Good luck! On Thu, Nov 26, 2020 at 11:28 PM Juraj Dobrik <[email protected]> wrote: > > Greetings my fellow scriptwriters and script developers. I didn't used > word JavaScript intentionally, because as HTML5 tags says, it's just > script, the default mode. > > Back to the origin, we want fast, dynamically typed, or non typed language > for browser and back-end that drastically reduces work force required to > create simple applications on demand, so highly specialized developers can > do something more fascinating than validate emails in C++. Even the need > for simple user to be able to use it and understand at first look is > important. > > I suggest to drop sinking ship that's called Java back on Java island, and > start something like "Script 7", 7 in symbolic is for god's number, and > we'll give user of this glorious epiphany that "Script 7" is going to be a > power of profound creation. > > I managed to make some ergonomic adjustments in concept of JavaScript, > that I advise you to be considered and used. > > https://es.discourse.group/t/deep-creation-of-object/230 > https://es.discourse.group/t/defined/253 > https://es.discourse.group/t/f-x-interface/243/2 > https://es.discourse.group/t/arrays/231 > // There's a error in comments, last one is shift. > https://es.discourse.group/t/for-loop-changes/239 > // Or call for just "w" > > https://es.discourse.group/t/ability-of-function-to-not-be-generator-and-then-execute-after-return/247 > https://es.discourse.group/t/object-accessor-class-interface/244 > https://es.discourse.group/t/automatic-variable-declaration/245 > // Still throws errors somewhere like this, so I am afraid to use it > https://es.discourse.group/t/for-of-with-index/238 > // or "w", notice how v is looped in w, or word loop for oo > https://es.discourse.group/t/prototype-constructor-override/237 > https://es.discourse.group/t/better-proxies/229/5 > // Also original variable should not get proxified, just proxy should > return proxyfied variable, mistake first done somewhere in this makes you > escape to access original variable like the doomed goat. > > This is not just brief intro. This is something Java won't have so soon, > therefore it should be script no. 7, simply as that, called in HTML5 with > <script v=7> tags. There's no even need for "" for integers in HTML, but I > guess you know. > > We don't only deserve new looks on surface internet codings, we need it. > We should maybe reiinitiate wave, with no spammy users, to correctly > exchange all possible information about new possible forms of internet > codings. WASM can make things faster, but it's still somehow feels like > being a function pointer orientated, which bloats processors with > unnecessary crunching. Web it selfs call for a new paradigm, and in my not > so humble opinion, we should get somethings close to machine, and use more > abstraction. > > The one possible approach is to add NASM to javascript, where you'd access > registries by r[0] or so, and normally supports syntax like mul r[0] > javascriptvariable. Without further feeding to some parsing engine, I would > suggest that those things could naturally stand in code. Just (ASM > expression). It could even support data segment and jump to instruction > stack for whole *java*script array of opcodes, which would suggest we > will have opcode type which can can be denoted as variable = ~`sub > ${time()} r[0]` . All of those expressions are completely parsable and > programatically deducible to be different type of token and token. > > This can be either interpreted as I think WASM is, I didn't studied it's > implementation, or even more virtualized version, where we could access > registry variable, like normally implemented script array. There comes the > final boss of this possible decade shift in distributed computing, the core > of all this magic. We would need to analyze code and deduce from what's > used, if we can use it as normal stack, or we'll use it as array, but it's > really similar structure, and I really can see the magic of somebody doing > lambda calculus in plain javascript. > > After boss we've got a pretty much decent fast scripting of any serialized > data. But there are corners of this verticle of a software we haven't > considered. Paraller processing. First frontiers of paraller processing > ware multicore processors. We can paraller code in two, where their states > doesn't affect each other. In array.map, to replace OP code, which is > exactly the technique we can use to change registers from core app > registers maliciously used in script to control host machine, to another > free space when we put o. code in instruction stack. > > OP code is type consisting of all binary op code variables like flag etc, > that is a object, if used as variable and not native, which have functions > to change any part of OP code, like changing the OP code or it's > arguments, probably best option would be to throw error if OP codes doesn't > get same callstack. Forgive me, I have some troubles about terminology, > because I cannot read anywhere the proper terms for processing situations > like this and I have just to assume. So if it have different amount of > registers put into it, it throws an error of uncompatible OP code. > > With this we could code = ~`mul ra rb rc` which is another way to describe > registers, because it should be NASM compatible... Just more way to do one > thing. We can use functions like code.div() to change multiplications to > divisions, having all this different OP codes variables listed in > code.mutations, so we can create combination of all possible > programatically easily and aestheticalhy. Or code[1] = rx to replace stack > provided by the OP codes. > > So many options to give a one result, or same program with same computable > states, in this level of free form, would mean, that we don't memorize > computers, but computer memorize us. > > type/ out(register.mul(register1)), I hope you get how fast it can trully > be. Or even with totally most awesome method, that ever came into my mind,. > Possibilities will be endless and which universality of this solution, even > another programmers would possibly understand everything, because it's so > intuitive. > > in((data)=>{console.log(data)}) > out(data) > > Are also two very important aspects of normal coding with this, as you can > assume it's reference to STDIN and STDOUT and even web browser have this > two pipes. And, it's not related much to ASM, but it's verry better > compared to console.log or process.stdin used in node, and what I really > want to do with this is system programing. > > There can be another type, compared to function, and that would be stream > processor. Stream processors have also those two mentioned function in/out, > but we can pipe them in a program like. > > pipeable foo => { > in((x)=>{out(x*x)}) > } > > pipable bar => { > in((x)=>{out(sqrt(x))}) > } > > Then we come to another improvable tendency, and that is streams, now we > have buffers, but I think that having buffer type stream of objects, or > stream of [ ] is suitable as well. Another type for buffer, can be type > pixel. We can have type pixel, for using on another range of parallel > processing where location of pixel doesn't have to be stored in pixel, but > could be used in iteration. For default, we would iterate from left to > right from down to up ( terminals always in our hearts ). Pixel can have > type of colour and colour which could be changed by function on pixel. > > Another thing is this pixels could be accessed even in nth dimensions for > finite elements physics simulation, and we would have type array. There a > new coordinate technique to get a exact location of 4D array that could be > used for future idiot and quantum proof cryptography could be > tessract[23;78;7;42] to access it in way of how arrays are nested. > > Basic initializations of nested arrays like that and their filling with > computed noise or data and it's slicing is trivial and should be subject of > more perspectives agreed on that, preferably having multiple ways to slice > same array or rotate a subcube in it. tesseract[10-24; 16-24; 14-26; > 99-150].rotate(0;1;2) which is number of how many faces shift in said > direction. Demonstration of this programming language shouldn't be > fibonnaci sequence, but atleast 3D rubic cube being solved in animation. > But that cannot be done only by rotating an array. Therefore I would like > to introduce .on.rotate and on.change with those type nested array or slice > of nested array, which is copy on write. > > There is maybe some specific niche program, that needs for change of > rotating subjects maintain the change of original value to current > position. Therefore it could be rotate(3 keepPointers) > > I didn't mentioned this before but parameters to functions, which are > binary flags should be ascii words that if present in arguments returns > true, because in deeply parametrized functions, which takes a lot of binary > flags, it's easier to not remember order but keyword. > > There should be a way to retrieve mixed object and array ( object with > numbered properties that are iterable only numbered not stringed ) one > could retrieve object like this in function example by ...args, to keep it > as object, because there will be many other parameters. But it should be > always returned whole not just rest as bunch of good jargon. Maybe this is > already implemented, but developers doesn't foobar every piece of > functionality they develop beyond their personal blogs, so I don't use it > that often. > > Back to cube, we have finite element simulation, navigating our warp space > ship trough hyper space and we want to compute an array... > > First frontier of pararellization as I mentioned is CPU, when with > multithreading, we can slice a code into segments, and if value from above > isn't assigned on bottom, we can parallel those two tasks. If there''s a > two start points that have merge at the end, we can use future pointer, and > merge threads just before it's required automatically. > > That's using proc code parsing. We create graph of variables assignment > and trees of their possible states with dependencies between those and we > can put unnecessary computation away. > > But now we aren't C++ fast, but ASM fast, because we do it for proc code > too, because of possible replacing sorts or searches, or some unnecessary > variable assign with strict copy or replace just on write and get a > pointers to that if used twice stuff like things, to optimize it to highest > level. It's probably not necessary, but after optimalization it would feel > maybe even better. Some array structures would shift pointer jugling tought > multiple levels to one adress shift exactly to final state, and that's all. > > I don't even know if it's necessary, but it can help, and being optimized > by processor instead of programmer can be huge help to programmer to > maintain ergonomic code while maintaining highest level of optimization. > > But there's another frontier of paraller processing, the GPU, with script > we could have GPU waiting there for any array map to do parallel or to do > iteration trough finite element simulation out automatically, just by shape > of operation and possible allocated memory. Graphic hardware is normal > computer. GL is used a lot on shaders, maybe it's faster with them, but > graphics also use CL, which is suitable for parallelization of stuff, in > totally normal language with w and loop loops, I would let both accept the > for, for in, for of, while, notation, and use them for different types of > semantical loops. That you dont have to w(;true;) but just w(true) is > deducible from amount of stuff inside. > > We can e.g. then make GL shader by piping pipeable pixel streams, creating > maybe new level of abstraction compared standard GL... Spliting and > remerging pipable streams trough some split and merge functions that > support multiple streams. > > Possible effect of this are that it'll become systems programming > language, because as I don't know if I mentioned before, it should get op > codes from server, string on demand, string should validate into same op > code or server would be marked security threat, compiled and optimized op > code into assembly instruction stack. Web pages or computing frames for > distributed computing could be runned as sub loop of browser or > computer(you run computers on your hypercomputer just to have more > recurssion in distributed computing, or in reverse order. We should call > some competent kids to give it proper names, it's for them, we have most of > our lives computed anyway) . Processing unit... How do you call kernel that > is responsible for running multiple paralleled computations wich subunits > that performs task specific computation? > > So, it does the infamous(spectre bug) instruction on x86 instruction that > never been taught of while writting C compilers, because processors until > x86 probably didn''t have it and so on... > > So we just parse javascript, or future script v7 shortened scr or script, > into self optimalizing assembly, optimize that and put raw assembly op > codes into the machine. > > Speed better than C of runtime, smart segmented caching of under > developement or changing scripts could increase even launch time > efficiency, simplicity of monkey language, integrated tensor calculus, > geometric functions for calculating 3D geometry as snippets in >non > microsoft< text editor, which can already spew up whole pipelined pipeables > that compiles into graphic shaders, massive automatic parallelization when > execution time in number of operations and their computative lenght would > determine if subroutine will be parallelized for finite elements > computation. Good set theory optimizations and groups as members of sets. > Abstract algebra types, that would support ring algebra, whole number > guessing from modulus convergence and modulus itself resulting in group. > > Objects should have {<*> (multiplier) {}, } and similar types, even for > non yet specified operands with possibility to insert a unicode characters. > That could be useful for statistics, if somebody would want to % operator > and not modulus, or tensor calculus. > > Another type now. > > type realspace > Could be 3D or 2D and would have real points defined by defined precision > of float in space and be able to calculate distance between points or make > geometric shapes from them and calculate their properties. > > Maybe nth dimensions would be generally good for some pipedream > mathematics experiments. Not just points, but set of points like ball. > Defined trough set of points, being stored as object with e.g. distance > from point. Those set of points should have boolean functions and color > blending options with opacity or math function as beta values in color > assuming set of real points, this real points being possible to be path of > mathematical function across the graph being skewed or literally > transformed. > > I know that's not how computers graphics works, but maybe if we have > languages like this that supports nth dimensional real space and curves in > it renderable. That when sorted array from point of perspective is even GL > computable, some polygon point placement algo's would be necessary... > > Doesn't matter, the last part is not that important, but maybe GPU > manufacturers could make better chips. Most important aspect of this > verbally overflowed thing is script that compiles to asm op codes. > > Maybe latter the script itself could evolve into system lang with async > system.on.boot() function written on it. > > Maybe it would require some more security overhead, but it's my pipedream. > Literally. It could remove java from planet by it's simplicity, be droid os > default language, and with proper modeling of function graph. > > New era of reboot of mobile phone application, with easy access to graphic > acceleration functions you wouldn't have to read thick book to use. Easy, > ASIC pipable support even for ML applications that would fit tensor code > specification, just easily written in one baseline language with simple > syntax of javascript. > > Future generations could be better people if they use less abstract syntax > unit of language per thing they want to describe. Programmers could know > bigger part of code like that naturally. > > And as I don't again know if I mentioned before, the later version can be > written in itself, therefore it'll be really system, but still easily > defined language, because we'll have both, processor op codes and op codes > for parsing with debugging, therefore even error reporting. > > Sorry for long post. > > Feel free. > > p.s. type can be deduced from road of variable in kernel, and input is > always string or defined binary. > > I am sorry I couldn't deliver it personally, but I just really... > > It just need good documentation and also flowchart of how it whole does > work that fits a wall people could hang on computer labs and memorize that > boils down to processor op code. > > There are 5 kind of processors that could run it, and that's like 5 times > writing what multiply is but no really a big problem if you can inspire > yourself by modern open source cross compilers. > > -- > -- > v8-dev mailing list > [email protected] > http://groups.google.com/group/v8-dev > --- > You received this message because you are subscribed to the Google Groups > "v8-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/v8-dev/964d04b0-692b-4188-9940-3a52c302091en%40googlegroups.com > <https://groups.google.com/d/msgid/v8-dev/964d04b0-692b-4188-9940-3a52c302091en%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev --- You received this message because you are subscribed to the Google Groups "v8-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/v8-dev/CAKSzg3TEUw6pphB3-DmAKn_%2BOmvqPBJttqTFBPZ_tVHNVAjVyQ%40mail.gmail.com.
