Forum libero

Scritto da: ::1
> http://readwrite.com/2014/11/12/node-js-joyent-pos...

Come le scissioni di Rifondazione.

> http://readwrite.com/2014/11/12/node-js-joyent-pos...

ummm... boh, non specifica esattamente quali sarebbero i punti della discordia. Comunque, non sono particolarmente infastidio dall'idea di un fork. Probabilmente propendero` per usare la versione open slegata da joyent, se un fork ci sara`, ma l'unico mio "prodotto" che si basa su nodeJS e` il miniserver Mary Lou, che al momento e` coinvolto solo in L.in.oleum 4. Casomai, dover apportare qualche modifica non sarebbe per niente traumatico.

Interessanti le varie considerazioni sui benevolent dictators for life. E` in definitiva un ruolo che non vorrei ricoprire con Lino4: mi limitero` a dare dei suggerimenti (anche piuttosto ovvi) nei commenti in cima al compilatore, ma senza proibire esplicitamente alcunche`. Al momento i commenti suggeriscono cosi`:

        L.in.oleum 4.00
        Kickstart Compiler 14.11.14 pre-A
        =========================================
        Copyright (c) 2014 by Alessandro Ghignola




        LICENSE TERMS (GPL v3)

        This program is free software: you can redistribute it and/or modify
        it under the terms of the GNU General Public License as published by
        the Free Software Foundation, either version 3 of the License, or
        (at your option) any later version.

        This program is distributed in the hope that it will be useful,
        but WITHOUT ANY WARRANTY; without even the implied warranty of
        MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
        GNU General Public License for more details.

        You should have received a copy of the GNU General Public License
        along with this program.  If not, see <http://www.gnu.org/licenses/>.




        PRE-ALPHA WARNING

        This is a pre-alpha version. It means it is still incomplete even with
        respect to its baseline design features. In particular, this version
        lacks the possibility of inserting native machine-language code strings
        into source code to obtain features outside the restricted instruction
        set envisioned by L.in.oleum's portability conventions. It also means
        it is FRESH PAINT: it may have bugs and completely untested parts that
        may cause compiled software to malfunction even where the source code
        of the software in question is, in theory, correctly written.




        DESIGN PHYSOLOSPHY:
        KEEP AN EYE ON WILD CHANGES

        Additionally, despite the license allows making changes to this script,
        and redistributing the changed version, users and developers of versions
        of this script other than as downloaded from site http://anynowhere.com
        are pleased not to mess with the language's essential syntax or otherwise
        affect backward compatibility with existing L.in.oleum 4.00 source code.

        I mean, think to it: this is the kickstart compiler (the compiler that
        comes before the self-compiler i.e. the version of it written in its own
        language) of a programming language, and it's not supposed to be changed
        often and lightly. Think to what'd happen if someone changed C's syntax,
        all of a sudden producing a new C dialect which is incompatible with any
        source code files written to that date.



        DESIGN PHYSOLOSPHY:
        CARE FOR WHAT'S OUT OF REACH, BUT LEAVE THE REST TO THE HUMAN BRAIN

        Aside from such radical, incompatible changes, users and developers are
        also advised to avoid randomly "polluting" the language's syntax in order
        to add features which usefulness is questionable. The design phylosophy
        should tend to keep in the language only a number of features that might
        be the reasonable minimum to permit abilities that could not be obtained
        easily in other ways: as an example of what one might ask him/herself
        when thinking about something to add to the compiler, "do we really need
        FOR loops where we already have DO, REPEAT, TIMES and EACH?". Or even "will
        we recognize conditional jump threading (as opposed to the unconditional
        occurrences outside the reach of the programmer) and other such trivial
        optimizations where a well-trained programmer's mind might do MUCH BETTER
        than the compiler itself?"...




        DESIGN PHYSOLOSPHY:
        IF SOMETHING SEEMS POSSIBLE ON CPU X, WILL IT STILL BE POSSIBLE ON CPU Y?

        As well, please remember there might be reasons why the compiler doesn't
        allow source code to do certain things that may look harmless at a first
        glance, e.g. if you try to break a floating-point calculation by placing
        calls, conditional statements, and/or jump-like statements (e.g. "break"
        and "continue" in a loop), the compiler will refuse to do so. The reason
        for that is that an ideal floating-point unit, in L.in.oleum's paradigm,
        follows a strict stack model: if the source is meant to be portable, and
        the target architecture features a register-based FPU (e.g. ARM does) it
        could become from hard to impossible to emulate the stack model there in
        case the code breaks sequences of FPU instructions in ways that couldn't
        be tracked by static source code analysis.