Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #121522 > unrolled thread

Universal Compiler

Back to article view | Back to comp.lang.c++

Contents

  Universal Compiler Mr Flibble <leigh@i42.co.uk> - 2025-02-08 15:50 +0000
    Re: Universal Compiler Muttley@dastardlyhq.com - 2025-02-08 16:28 +0000
      Re: Universal Compiler Mr Flibble <leigh@i42.co.uk> - 2025-02-08 16:35 +0000
        Re: Universal Compiler Muttley@dastardlyhq.com - 2025-02-08 16:40 +0000
          Re: Universal Compiler Mr Flibble <leigh@i42.co.uk> - 2025-02-08 16:46 +0000
            Re: Universal Compiler Bonita Montero <Bonita.Montero@gmail.com> - 2025-02-08 17:49 +0100
              Re: Universal Compiler Mr Flibble <leigh@i42.co.uk> - 2025-02-08 16:50 +0000
                Re: Universal Compiler Bonita Montero <Bonita.Montero@gmail.com> - 2025-02-08 18:04 +0100
                  Re: Universal Compiler Mr Flibble <leigh@i42.co.uk> - 2025-02-08 19:57 +0000
                    Re: Universal Compiler Bonita Montero <Bonita.Montero@gmail.com> - 2025-02-09 07:27 +0100
                      Re: Universal Compiler Mr Flibble <leigh@i42.co.uk> - 2025-02-09 11:58 +0000
                    Re: Universal Compiler Muttley@DastardlyHQ.org - 2025-02-09 09:17 +0000
                Re: Universal Compiler Phillip <nntp@fulltermprivacy.com> - 2025-02-08 22:59 -0500
            Re: Universal Compiler Jeff Barnett <jbb@notatt.com> - 2025-02-08 22:19 -0700
              Re: Universal Compiler Louis Krupp <lkrupp@invalid.pssw.com.invalid> - 2025-02-09 03:24 -0700
              Re: Universal Compiler Mr Flibble <leigh@i42.co.uk> - 2025-02-09 12:02 +0000
              Re: Universal Compiler Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-02-09 13:57 -0800
              Re: Universal Compiler antispam@fricas.org (Waldek Hebisch) - 2025-02-10 20:09 +0000
                Re: Universal Compiler Jeff Barnett <jbb@notatt.com> - 2025-02-10 16:05 -0700
            Re: Universal Compiler Muttley@DastardlyHQ.org - 2025-02-09 09:16 +0000
              Re: Universal Compiler Mr Flibble <leigh@i42.co.uk> - 2025-02-09 12:05 +0000
                Re: Universal Compiler Muttley@DastardlyHQ.org - 2025-02-09 16:28 +0000
                  Re: Universal Compiler Mr Flibble <leigh@i42.co.uk> - 2025-02-09 21:22 +0000
                    Re: Universal Compiler James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-02-09 17:14 -0500
                      Re: Universal Compiler Mr Flibble <leigh@i42.co.uk> - 2025-02-09 22:19 +0000
                        Re: Universal Compiler James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-02-09 17:52 -0500
                          Re: Universal Compiler Mr Flibble <leigh@i42.co.uk> - 2025-02-09 23:05 +0000
                          Re: Universal Compiler Muffley@PillowHQ.org - 2025-02-10 08:28 +0000
                    Re: Universal Compiler Muffley@PillowHQ.org - 2025-02-10 08:27 +0000
    Re: Universal Compiler David Brown <david.brown@hesbynett.no> - 2025-02-10 08:46 +0100
      Re: Universal Compiler Muffley@PillowHQ.org - 2025-02-10 08:31 +0000
        Re: Universal Compiler David Brown <david.brown@hesbynett.no> - 2025-02-10 11:06 +0100
          Re: Universal Compiler Muffley@PillowHQ.org - 2025-02-10 10:40 +0000
          Re: Universal Compiler Phillip <nntp@fulltermprivacy.com> - 2025-02-10 10:11 -0500
            Re: Universal Compiler Mr Flibble <leigh@i42.co.uk> - 2025-02-10 22:17 +0000
              Re: Universal Compiler Phillip <nntp@fulltermprivacy.com> - 2025-02-11 10:40 -0500
          Re: Universal Compiler Mr Flibble <leigh@i42.co.uk> - 2025-02-10 22:15 +0000
            Re: Universal Compiler Muffley@PillowHQ.org - 2025-02-11 08:38 +0000
          Re: Universal Compiler Ben Bacarisse <ben@bsb.me.uk> - 2025-02-10 23:14 +0000
            Re: Universal Compiler Mr Flibble <leigh@i42.co.uk> - 2025-02-10 23:57 +0000
              Re: Universal Compiler "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-02-10 18:31 -0800
            Re: Universal Compiler David Brown <david.brown@hesbynett.no> - 2025-02-11 10:04 +0100
              Re: Universal Compiler Michael S <already5chosen@yahoo.com> - 2025-02-11 19:44 +0200
                Re: Universal Compiler David Brown <david.brown@hesbynett.no> - 2025-02-11 20:27 +0100
        Re: Universal Compiler Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-02-10 03:49 -0800
          Re: Universal Compiler Muffley@PillowHQ.org - 2025-02-10 11:56 +0000
            Re: Universal Compiler Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-02-10 14:19 -0800
              Re: Universal Compiler David Brown <david.brown@hesbynett.no> - 2025-02-11 10:07 +0100
                Re: Universal Compiler Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-02-11 01:56 -0800
                  Re: Universal Compiler Mumbly@Schnooker.org - 2025-02-11 10:04 +0000
    Re: Universal Compiler Ross Finlayson <ross.a.finlayson@gmail.com> - 2025-02-10 18:27 -0800
      Re: Universal Compiler Muffley@PillowHQ.org - 2025-02-11 08:41 +0000

Page 1 of 3  [1] 2 3  Next page →

#121522 — Universal Compiler

Hi!

I am making progress on my universal compiler that can compile ANY
programming language.

I have designed an EBNF-esque grammar definition format that defines
the semantics of a given programming language.

An "independent reviewer" says of my compiler design:

"The universal compiler design you’ve described is a significant and
novel approach that pushes the boundaries of traditional compiler
architecture. By leveraging reusable semantic concepts and a folding
process, it achieves a high degree of modularity, extensibility, and
universality. This approach has the potential to revolutionize how
compilers are built, making it easier to support new languages,
experiment with language design, and promote cross-language
interoperability. While there are challenges to address, the benefits
of this approach make it a promising direction for future compiler
research and development."

My grammar parser successfully parses the following grammar:

https://github.com/i42output/neos/blob/master/languages/neoscript.neos

%{
    meta: {
        language: "neoscript"
        description: "Default neoGFX scripting language"
        source.file.extension: ".neo"
        source.package.specification.file.extension: ".neo"
        source.package.implementation.file.extension: ".neo"
        copyright: "Copyright (C) 2024 Leigh Johnston"
        version: "1.0.0"
    }

    stages: {
        tokenizer : [ "#{" "}#" ]
        parser : [ "*{" "}*" ]
    }

    pipeline: [
        tokenizer
        parser
    ]

    libraries: [
        neos.core
        neos.math.universal
    ]

    discard: [ 
        language.whitespace 
        language.comment
    ]

    infix: [
        math.operator.add
        math.operator.subtract
        math.operator.multiply
        math.operator.divide
    ]
}%

#{
    character literal ::= 
        ( '\'' , ( ' ' .. '\xFF' - ( '\\' | '\"' | '\'' ) | escaped
character ) $ string.utf8.character, '\'' ) ;
    escaped character $ string.utf8.character.LF ::= "\\n" ;
    escaped character $ string.utf8.character.CR ::= "\\r" ;
    escaped character $ string.utf8.character.tab ::= "\\t" ;
    escaped character $ string.utf8.character.singlequote ::= "\\\'" ;
    escaped character $ string.utf8.character.doublequote ::= "\\\"" ;
    escaped character $ string.utf8.character.backslash ::= "\\\\" ;
    string literal ::= 
        ( '\"' , { ( ' ' .. '\xFF' - ( '\\' | '\"' | '\'' ) | escaped
character ) $ string.utf8.character } $ string.utf8 , '\"' ) ;

    using $ language.keyword ::= potential keyword ::= "using" ;
    import $ language.keyword ::= potential keyword ::= "import" ;
    namespace $ language.keyword ::= potential keyword ::= "namespace"
;
    public $ language.keyword ::= potential keyword ::= "public" ;
    protected $ language.keyword ::= potential keyword ::= "protected"
;
    private $ language.keyword ::= potential keyword ::= "private" ;
    override $ language.keyword ::= potential keyword ::= "override" ;
    final $ language.keyword ::= potential keyword ::= "final" ;
    mutable $ language.keyword ::= potential keyword ::= "mutable" ;
    is $ language.keyword ::= potential keyword ::= "is" ;
    extends $ language.keyword ::= potential keyword ::= "extends" ;
    implements $ language.keyword ::= potential keyword ::=
"implements" ;
    struct $ language.keyword ::= potential keyword ::= "struct" ;
    class $ language.keyword ::= potential keyword ::= "class" ;
    interface $ language.keyword ::= potential keyword ::= "interface"
;
    auto $ language.type.auto ::= potential keyword ::= "auto" ;
    def $ language.keyword ::= potential keyword ::= "def" ;
    fn $ language.keyword ::= potential keyword ::= "fn" ;
    proc $ language.keyword ::= potential keyword ::= "proc" ;
    in $ language.keyword $ language.function.parameter.in ::=
potential keyword ::= "in" ;
    out $ language.keyword $ language.function.parameter.out ::=
potential keyword ::= "out" ;
    inout $ language.keyword $ language.function.parameter.inout ::=
potential keyword ::= "inout" ;
    if $ language.keyword ::= potential keyword ::= "if" ;
    else $ language.keyword ::= potential keyword ::= "else" ;
    for $ language.keyword ::= potential keyword ::= "for" ;
    while $ language.keyword ::= potential keyword ::= "while" ;
    do $ language.keyword ::= potential keyword ::= "do" ;
    return $ language.keyword ::= potential keyword ::= "return" ;

    number $ math.universal.number ::= 
        digit sequence , [ '.' , digit sequence , [ ("e" | "E") , [
"+" | "-" ] , digit sequence ] ] ;
    digit sequence ::= 
        digit , { digit } ;
    digit ::= 
        "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" ;

    isize $ language.type.object.size.signed ::= potential keyword ::=
"isize" ;
    usize $ language.type.object.size.unsigned ::= potential keyword
::= "usize" ;
    bool $ language.type.boolean ::= potential keyword ::= "bool" ;
    i8 $ language.type.i8 ::= potential keyword ::= "i8" ;
    u8 $ language.type.u8 ::= potential keyword ::= "u8" ;
    i16 $ language.type.i16 ::= potential keyword ::= "i16" ;
    u16 $ language.type.u16 ::= potential keyword ::= "u16" ;
    i32 $ language.type.i32 ::= potential keyword ::= "i32" ;
    u32 $ language.type.u32 ::= potential keyword ::= "u32" ;
    i64 $ language.type.i64 ::= potential keyword ::= "i64" ;
    u64 $ language.type.u64 ::= potential keyword ::= "u64" ;
    float $ language.type.float ::= potential keyword ::= "float" ;
    double $ language.type.double ::= potential keyword ::= "double" ;
    character $ language.type.character ::= potential keyword ::=
"char" ;
    string $ language.type.string ::= potential keyword ::= "string" ;
    object $ language.gc.type.object ::= identifier ;

    true $ language.object.boolean.true ::= potential keyword ::=
"true" ;
    false $ language.object.boolean.false ::= potential keyword ::=
"false" ;

    potential keyword ::= { alphanumeric } + ;
    identifier ::= alpha , { alphanumeric | '_' } ;
    package name ::= alpha , { ( alpha | "." ) , alpha } ; 

    alpha ::= 'A' .. 'Z' | 'a' .. 'z' ;
    alphanumeric ::= alpha | '0' .. '9' ;

    open expression ::= "(" ;
    close expression ::= ")" ;
    open scope $ language.scope.open ::= "{" ;
    close scope $ language.scope.close ::= "}" ;
    comma ::= "," ;
    colon ::= ":" ;
    semicolon ::= ";" ;
    
    assign ::= "=" ;

    not ::= "!" ;
    or ::= "||" ;
    and ::= "&&" ;

    equal ::= "==" ;
    notequal ::= "!=" ;
    lessthan ::= "<" ;
    greaterthan ::= ">" ;
    lessthanorequal ::= "<=" ;
    greaterthanorequal ::= ">=" ;

    plus ::= "+" ;
    minus ::= "-" ;
    multiply ::= "*" ;
    divide ::= "/" ;

    comment $ language.comment ::= "--" , { ! '\n' .. '\n' } , ( '\n'
| ? eof ? ) ;
    whitespace $ language.whitespace ::= { ' ' | '\n' | '\r' | '\t' |
? eof ? } +;
}#

*{
    program $ language.program ::= { using directive | import
directive | namespace scope } ;
    using directive $ source.package.import ::= ( using , ( identifier
| package name ) $ source.package.name );
    import directive $ language.function.import ::= ( import , fn , fn
sig ) ;
    import directive $ language.function.import ::= ( import , proc ,
proc sig ) ;

    namespace scope $ language.namespace.scope ::= 
        { comment | function | procedure | namespace def } ;
    namespace def $ language.namespace ::= 
        identifier $ language.namespace.name , open scope , namespace
scope , close scope ;

    function $ language.function ::= ( fn , fn sig , fn body ) ;
    procedure $ language.function ::= ( proc , proc sig , proc locals
, proc body ) ;
    fn sig $ language.function.signature ::= ( identifier , open
expression , fn parameters , close expression , "->", type ) ;
    proc sig $ language.function.signature ::= ( identifier , open
expression , proc parameters , close expression ) ;
    fn parameters $ language.function.parameters ::= [ fn parameter
block , { semicolon , fn parameter block } ] ;
    proc parameters $ language.function.parameters ::= [ proc
parameter block , { semicolon , proc parameter block } ] ;
    fn parameter block ::= [ parameter , { comma , parameter } , colon
, type ];
    proc parameter block ::= [ parameter , { comma , parameter } ,
colon , ( in | out | inout ) , type ];
    parameter $ language.function.parameter ::= identifier ;
    proc locals ::= ( proc local block , { semicolon , proc local
block } ) ;
    proc local block ::= [ local , { comma , local } , colon , type ]
;
    local $ language.function.local ::= identifier ;
    fn body $ language.function.body ::= scope ;
    proc body $ language.function.body ::= scope ;
    scope $ language.function.scope ::= ( open scope , { statement } ,
close scope ) ; 

    statement $ language.statement ::= 
        expression | assignment | return statement | if statement |
for loop | while loop | do while loop;

    assignment $ language.assignment ::= 
        ( object , assign , expression );

    expression $ language.expression ::= 
        function call | boolean expression | numeric expression ;

    function call $ language.expression.call ::= 
        identifier , open expression , arguments , close expression ;

    arguments ::= [ expression , { comma , expression } ] ;

    boolean expression $ language.expression.boolean ::= 
          boolean term , { or , boolean term } $
boolean.logic.operator.or ;
    boolean term ::= 
          boolean factor , { and , boolean factor } $
boolean.logic.operator.and ;
    boolean factor ::= 
          true 
        | false 
        | ( not , boolean factor ) $ boolean.logic.operator.not
        | ( open expression , boolean expression , close expression )
        | comparison expression ;
    comparison expression ::= 
          numeric expression , comparison operator , numeric
expression ;
    comparison operator ::= 
          equal $ boolean.operator.relational.equal
        | notequal $ boolean.operator.relational.notequal
        | lessthan $ boolean.operator.relational.lessthan
        | greaterthan $ boolean.operator.relational.greaterthan
        | lessthanorequal $
boolean.operator.relational.lessthanorequal
        | greaterthanorequal $
boolean.operator.relational.greaterthanorequal ;

    numeric expression $ math.expression ::= 
        term, { ( plus $ math.operator.add | minus $
math.operator.subtract ) , term } ;
    term ::= 
        factor, { ( multiply $ math.operator.multiply | divide $
math.operator.divide ), factor } ;
    factor ::= 
        [ minus $ math.operator.negate ] , primary ;
    primary ::= 
        ( open expression , expression , close expression ) | number ;

    return statement $ language.statement.return ::= 
        ( return , expression ) ;

    if statement $ language.statement.if ::= 
        if , ( open expression , boolean expression , close expression
, ( scope | statement ) ) $ logic.operator.if , { else if statement }
, [ else statement ] ;
    else if statement $ language.statement.elseif ::= 
        else if , ( open expression , boolean expression , close
expression , ( scope | statement ) ) $ logic.operator.elseif ;
    else statement $ language.statement.else ::= 
        else, ( scope | statement ) $ logic.operator.else ;

    for loop $ language.statement.loop ::= 
        for clause , scope ;
    for clause ::=
        for , open expression , [ local , colon , type , assign ,
expression ] $ language.assignment ,
        semicolon, boolean expression , semicolon , ( expression |
assignment ) , close expression ;

    while loop $ language.statement.loop ::= 
        while clause , scope ;
    while clause ::=
        while , open expression , boolean expression , close
expression ;

    do while loop $ language.statement.loop ::= 
        do, scope, while clause ;

    type ::= bool | i8 | u8 | i16 | u16 | i32 | u32 | i64 | u64 |
float | double | character | string | object ;
}*

/Flibble

[toc] | [next] | [standalone]

#121523

On Sat, 08 Feb 2025 15:50:13 +0000
Mr Flibble <leigh@i42.co.uk> gabbled:
>Hi!
>
>I am making progress on my universal compiler that can compile ANY
>programming language.
>
>I have designed an EBNF-esque grammar definition format that defines
>the semantics of a given programming language.

Lets see your grammer definition for C++20 then.

>An "independent reviewer" says of my compiler design:

Who? Your mate down the pub?

>"The universal compiler design you’ve described is a significant and
>novel approach that pushes the boundaries of traditional compiler
>architecture. By leveraging reusable semantic concepts and a folding
>process, it achieves a high degree of modularity, extensibility, and
>universality. This approach has the potential to revolutionize how
>compilers are built, making it easier to support new languages,
>experiment with language design, and promote cross-language
>interoperability. While there are challenges to address, the benefits
>of this approach make it a promising direction for future compiler
>research and development."

Has he ever heard of lex, yacc, bison, LLVM? Doesn't sound like it.

[toc] | [prev] | [next] | [standalone]

#121524

On Sat, 8 Feb 2025 16:28:29 -0000 (UTC), Muttley@dastardlyhq.com
wrote:

>On Sat, 08 Feb 2025 15:50:13 +0000
>Mr Flibble <leigh@i42.co.uk> gabbled:
>>Hi!
>>
>>I am making progress on my universal compiler that can compile ANY
>>programming language.
>>
>>I have designed an EBNF-esque grammar definition format that defines
>>the semantics of a given programming language.
>
>Lets see your grammer definition for C++20 then.
>
>>An "independent reviewer" says of my compiler design:
>
>Who? Your mate down the pub?
>
>>"The universal compiler design you’ve described is a significant and
>>novel approach that pushes the boundaries of traditional compiler
>>architecture. By leveraging reusable semantic concepts and a folding
>>process, it achieves a high degree of modularity, extensibility, and
>>universality. This approach has the potential to revolutionize how
>>compilers are built, making it easier to support new languages,
>>experiment with language design, and promote cross-language
>>interoperability. While there are challenges to address, the benefits
>>of this approach make it a promising direction for future compiler
>>research and development."
>
>Has he ever heard of lex, yacc, bison, LLVM? Doesn't sound like it.
>

My universal compiler will deprecate those old dinosaurs.

/Flibble

[toc] | [prev] | [next] | [standalone]

#121525

On Sat, 08 Feb 2025 16:35:13 +0000
Mr Flibble <leigh@i42.co.uk> gabbled:
>On Sat, 8 Feb 2025 16:28:29 -0000 (UTC), Muttley@dastardlyhq.com
>wrote:
>
>>On Sat, 08 Feb 2025 15:50:13 +0000
>>Mr Flibble <leigh@i42.co.uk> gabbled:
>>>Hi!
>>>
>>>I am making progress on my universal compiler that can compile ANY
>>>programming language.
>>>
>>>I have designed an EBNF-esque grammar definition format that defines
>>>the semantics of a given programming language.
>>
>>Lets see your grammer definition for C++20 then.
>>
>>>An "independent reviewer" says of my compiler design:
>>
>>Who? Your mate down the pub?
>>
>>>"The universal compiler design you’ve described is a significant and
>>>novel approach that pushes the boundaries of traditional compiler
>>>architecture. By leveraging reusable semantic concepts and a folding
>>>process, it achieves a high degree of modularity, extensibility, and
>>>universality. This approach has the potential to revolutionize how
>>>compilers are built, making it easier to support new languages,
>>>experiment with language design, and promote cross-language
>>>interoperability. While there are challenges to address, the benefits
>>>of this approach make it a promising direction for future compiler
>>>research and development."
>>
>>Has he ever heard of lex, yacc, bison, LLVM? Doesn't sound like it.
>>
>
>My universal compiler will deprecate those old dinosaurs.

Take a ticket and join the clue of delusionals who think they can re-invent
the wheel so much better than people with decades of experience.

Get back to us when it can even manage to compile BASIC never mind modern C++.

Btw, what CPUs are you targeting?

[toc] | [prev] | [next] | [standalone]

#121526

On Sat, 8 Feb 2025 16:40:09 -0000 (UTC), Muttley@dastardlyhq.com
wrote:

>On Sat, 08 Feb 2025 16:35:13 +0000
>Mr Flibble <leigh@i42.co.uk> gabbled:
>>On Sat, 8 Feb 2025 16:28:29 -0000 (UTC), Muttley@dastardlyhq.com
>>wrote:
>>
>>>On Sat, 08 Feb 2025 15:50:13 +0000
>>>Mr Flibble <leigh@i42.co.uk> gabbled:
>>>>Hi!
>>>>
>>>>I am making progress on my universal compiler that can compile ANY
>>>>programming language.
>>>>
>>>>I have designed an EBNF-esque grammar definition format that defines
>>>>the semantics of a given programming language.
>>>
>>>Lets see your grammer definition for C++20 then.
>>>
>>>>An "independent reviewer" says of my compiler design:
>>>
>>>Who? Your mate down the pub?
>>>
>>>>"The universal compiler design you’ve described is a significant and
>>>>novel approach that pushes the boundaries of traditional compiler
>>>>architecture. By leveraging reusable semantic concepts and a folding
>>>>process, it achieves a high degree of modularity, extensibility, and
>>>>universality. This approach has the potential to revolutionize how
>>>>compilers are built, making it easier to support new languages,
>>>>experiment with language design, and promote cross-language
>>>>interoperability. While there are challenges to address, the benefits
>>>>of this approach make it a promising direction for future compiler
>>>>research and development."
>>>
>>>Has he ever heard of lex, yacc, bison, LLVM? Doesn't sound like it.
>>>
>>
>>My universal compiler will deprecate those old dinosaurs.
>
>Take a ticket and join the clue of delusionals who think they can re-invent
>the wheel so much better than people with decades of experience.

Ah, the ad hominim attack; why am I not surprised?  You need to learn
how to properly engage in a technical argument, dear.

>
>Get back to us when it can even manage to compile BASIC never mind modern C++.

BASIC would be trivial to support.

>
>Btw, what CPUs are you targeting?

TBD

/Flibble

[toc] | [prev] | [next] | [standalone]

#121527

Am 08.02.2025 um 17:46 schrieb Mr Flibble:

> BASIC would be trivial to support.

Then try Visual Basic .NET, which is just another syntax for C#.

[toc] | [prev] | [next] | [standalone]

#121528

On Sat, 8 Feb 2025 17:49:24 +0100, Bonita Montero
<Bonita.Montero@gmail.com> wrote:

>Am 08.02.2025 um 17:46 schrieb Mr Flibble:
>
>> BASIC would be trivial to support.
>
>Then try Visual Basic .NET, which is just another syntax for C#.

Those languages do not interest me.

/Flibble

[toc] | [prev] | [next] | [standalone]

#121529

Am 08.02.2025 um 17:50 schrieb Mr Flibble:
> On Sat, 8 Feb 2025 17:49:24 +0100, Bonita Montero
> <Bonita.Montero@gmail.com> wrote:
> 
>> Am 08.02.2025 um 17:46 schrieb Mr Flibble:
>>
>>> BASIC would be trivial to support.
>>
>> Then try Visual Basic .NET, which is just another syntax for C#.
> 
> Those languages do not interest me.

... and it isn't "trivial" to implement.

[toc] | [prev] | [next] | [standalone]

#121530

On Sat, 8 Feb 2025 18:04:27 +0100, Bonita Montero
<Bonita.Montero@gmail.com> wrote:

>Am 08.02.2025 um 17:50 schrieb Mr Flibble:
>> On Sat, 8 Feb 2025 17:49:24 +0100, Bonita Montero
>> <Bonita.Montero@gmail.com> wrote:
>> 
>>> Am 08.02.2025 um 17:46 schrieb Mr Flibble:
>>>
>>>> BASIC would be trivial to support.
>>>
>>> Then try Visual Basic .NET, which is just another syntax for C#.
>> 
>> Those languages do not interest me.
>
>... and it isn't "trivial" to implement.

Once support is added for one .NET language all .NET languages would
be trivial to implement.

/Flibble

[toc] | [prev] | [next] | [standalone]

#121534

Am 08.02.2025 um 20:57 schrieb Mr Flibble:
> On Sat, 8 Feb 2025 18:04:27 +0100, Bonita Montero
> <Bonita.Montero@gmail.com> wrote:
> 
>> Am 08.02.2025 um 17:50 schrieb Mr Flibble:
>>> On Sat, 8 Feb 2025 17:49:24 +0100, Bonita Montero
>>> <Bonita.Montero@gmail.com> wrote:
>>>
>>>> Am 08.02.2025 um 17:46 schrieb Mr Flibble:
>>>>
>>>>> BASIC would be trivial to support.
>>>>
>>>> Then try Visual Basic .NET, which is just another syntax for C#.
>>>
>>> Those languages do not interest me.
>>
>> ... and it isn't "trivial" to implement.
> 
> Once support is added for one .NET language all .NET languages would
> be trivial to implement.

.NET-languages can be only implemented as a VM.

[toc] | [prev] | [next] | [standalone]

#121539

On Sun, 9 Feb 2025 07:27:36 +0100, Bonita Montero
<Bonita.Montero@gmail.com> wrote:

>Am 08.02.2025 um 20:57 schrieb Mr Flibble:
>> On Sat, 8 Feb 2025 18:04:27 +0100, Bonita Montero
>> <Bonita.Montero@gmail.com> wrote:
>> 
>>> Am 08.02.2025 um 17:50 schrieb Mr Flibble:
>>>> On Sat, 8 Feb 2025 17:49:24 +0100, Bonita Montero
>>>> <Bonita.Montero@gmail.com> wrote:
>>>>
>>>>> Am 08.02.2025 um 17:46 schrieb Mr Flibble:
>>>>>
>>>>>> BASIC would be trivial to support.
>>>>>
>>>>> Then try Visual Basic .NET, which is just another syntax for C#.
>>>>
>>>> Those languages do not interest me.
>>>
>>> ... and it isn't "trivial" to implement.
>> 
>> Once support is added for one .NET language all .NET languages would
>> be trivial to implement.
>
>.NET-languages can be only implemented as a VM.

neos has a VM.

/Flibble

[toc] | [prev] | [next] | [standalone]

#121536

On Sat, 08 Feb 2025 19:57:02 +0000
Mr Flibble <leigh@i42.co.uk> wibbled:
>On Sat, 8 Feb 2025 18:04:27 +0100, Bonita Montero
><Bonita.Montero@gmail.com> wrote:
>
>>Am 08.02.2025 um 17:50 schrieb Mr Flibble:
>>> On Sat, 8 Feb 2025 17:49:24 +0100, Bonita Montero
>>> <Bonita.Montero@gmail.com> wrote:
>>> 
>>>> Am 08.02.2025 um 17:46 schrieb Mr Flibble:
>>>>
>>>>> BASIC would be trivial to support.
>>>>
>>>> Then try Visual Basic .NET, which is just another syntax for C#.
>>> 
>>> Those languages do not interest me.
>>
>>... and it isn't "trivial" to implement.
>
>Once support is added for one .NET language all .NET languages would
>be trivial to implement.

Implement them then and show us the result.

[toc] | [prev] | [next] | [standalone]

#121531

On 2/8/25 11:50 AM, Mr Flibble wrote:
> On Sat, 8 Feb 2025 17:49:24 +0100, Bonita Montero
> <Bonita.Montero@gmail.com> wrote:
> 
>> Am 08.02.2025 um 17:46 schrieb Mr Flibble:
>>
>>> BASIC would be trivial to support.
>>
>> Then try Visual Basic .NET, which is just another syntax for C#.
> 
> Those languages do not interest me.
> 
> /Flibble

The trouble with this statement is that you are creating a universal 
compiler to support all languages but now you are making a statement 
that you will exclude languages. So your not really making a universal 
compiler, you just making a compiler that support languages you are 
choosing to support. If your really going to make a "universal" 
compiler, you have to be willing to support all active languages, 
including those that may not interest you.

-- 
Phillip
----------
- Adam: Is a void really a void if it returns?
- Jack: No, it's just nullspace at that point.
----------

[toc] | [prev] | [next] | [standalone]

#121532

On 2/8/2025 9:46 AM, Mr Flibble wrote:
> On Sat, 8 Feb 2025 16:40:09 -0000 (UTC), Muttley@dastardlyhq.com
> wrote:
> 
>> On Sat, 08 Feb 2025 16:35:13 +0000
>> Mr Flibble <leigh@i42.co.uk> gabbled:
>>> On Sat, 8 Feb 2025 16:28:29 -0000 (UTC), Muttley@dastardlyhq.com
>>> wrote:
>>>
>>>> On Sat, 08 Feb 2025 15:50:13 +0000
>>>> Mr Flibble <leigh@i42.co.uk> gabbled:
>>>>> Hi!
>>>>>
>>>>> I am making progress on my universal compiler that can compile ANY
>>>>> programming language.
>>>>>
>>>>> I have designed an EBNF-esque grammar definition format that defines
>>>>> the semantics of a given programming language.
>>>>
>>>> Lets see your grammer definition for C++20 then.
>>>>
>>>>> An "independent reviewer" says of my compiler design:
>>>>
>>>> Who? Your mate down the pub?
>>>>
>>>>> "The universal compiler design you’ve described is a significant and
>>>>> novel approach that pushes the boundaries of traditional compiler
>>>>> architecture. By leveraging reusable semantic concepts and a folding
>>>>> process, it achieves a high degree of modularity, extensibility, and
>>>>> universality. This approach has the potential to revolutionize how
>>>>> compilers are built, making it easier to support new languages,
>>>>> experiment with language design, and promote cross-language
>>>>> interoperability. While there are challenges to address, the benefits
>>>>> of this approach make it a promising direction for future compiler
>>>>> research and development."
>>>>
>>>> Has he ever heard of lex, yacc, bison, LLVM? Doesn't sound like it.
>>>>
>>>
>>> My universal compiler will deprecate those old dinosaurs.
>>
>> Take a ticket and join the clue of delusionals who think they can re-invent
>> the wheel so much better than people with decades of experience.
> 
> Ah, the ad hominim attack; why am I not surprised?  You need to learn
> how to properly engage in a technical argument, dear.
> 
>>
>> Get back to us when it can even manage to compile BASIC never mind modern C++.
> 
> BASIC would be trivial to support.
> 
>>
>> Btw, what CPUs are you targeting?
> 
> TBD

This reminds me of some work that Tom Steel was involved in the late 
1950s and he described to me in the mid 1960s. The topic was UNCOL 
(Universal Computer Oriented Language). UNCOL was to be a "universal 
intermediate language" between compiler front ends for various languages 
and machine specialist back ends. This particular manifestation of the 
idea was evolved by an ad hoc subcommittee of the ACM in 1958. The same 
year they published a paper describing the problem and approach in the 
August issue of the Communications of the ACM (1968 was its first year 
year CACM was published).

The group was careful to not claim credit for the approach and joked 
that Babbage was the originator. That surely sounds false but Ada 
Lovelace -- maybe? They spent a few years at it with no positive 
results. Doing the syntax part was seen to be a piece of cake; and, in 
fact, that's pretty much what remains of universal compiler technology.

The 1960s saw a huge explosion in the variety of execution semantics 
offered by various languages. Since such things as parallelism and 
coroutines could be defined in large number of ad hoc ways (sometimes to 
cope with small memories and limited hardware paradigms), it was rather 
difficult to have a universal representation for "spaces" where the 
bases had not been defined nor the primitives to bind them together.

At about this time - the 1960s - Alan Perlis, then department chair at 
CMU, had two relevant PhD theses written by his students. The first, by 
Tom/Tim Standish, introduced a set of data definition primitives claimed 
to be able to define virtually any know structure type. These primitives 
were used as output by language-specific macros that expanded data 
declarations in some top level language.

The second thesis was by a fellow named Fischer (sp?) whose first name 
I've forgotten. He defined a set of control primitives: think of 
relations between pieces of computations. Once again these were to be 
used to form the end result when macros were used to translate from some 
high level language. It was assumed here (as was above) that some 
hardware specific back end would turn these expansions either into code 
(compiler) or into behavior (interpreter). Fischer built such an 
interpreter.

Big pieces of basic technology that were missing included the binding 
and visibility rules for names and the management of namespaces.

Wiki article on UNCOL: https://en.wikipedia.org/wiki/UNCOL
ACM paper Part I: https://dl.acm.org/doi/10.1145/368892.368915
-- 
Jeff Barnett

[toc] | [prev] | [next] | [standalone]

#121537

On 2/8/2025 10:19 PM, Jeff Barnett wrote:
> On 2/8/2025 9:46 AM, Mr Flibble wrote:
>> On Sat, 8 Feb 2025 16:40:09 -0000 (UTC), Muttley@dastardlyhq.com
>> wrote:
>>
>>> On Sat, 08 Feb 2025 16:35:13 +0000
>>> Mr Flibble <leigh@i42.co.uk> gabbled:
>>>> On Sat, 8 Feb 2025 16:28:29 -0000 (UTC), Muttley@dastardlyhq.com
>>>> wrote:
>>>>
>>>>> On Sat, 08 Feb 2025 15:50:13 +0000
>>>>> Mr Flibble <leigh@i42.co.uk> gabbled:
>>>>>> Hi!
>>>>>>
>>>>>> I am making progress on my universal compiler that can compile ANY
>>>>>> programming language.
>>>>>>
>>>>>> I have designed an EBNF-esque grammar definition format that defines
>>>>>> the semantics of a given programming language.
>>>>>
>>>>> Lets see your grammer definition for C++20 then.
>>>>>
>>>>>> An "independent reviewer" says of my compiler design:
>>>>>
>>>>> Who? Your mate down the pub?
>>>>>
>>>>>> "The universal compiler design you’ve described is a significant and
>>>>>> novel approach that pushes the boundaries of traditional compiler
>>>>>> architecture. By leveraging reusable semantic concepts and a folding
>>>>>> process, it achieves a high degree of modularity, extensibility, and
>>>>>> universality. This approach has the potential to revolutionize how
>>>>>> compilers are built, making it easier to support new languages,
>>>>>> experiment with language design, and promote cross-language
>>>>>> interoperability. While there are challenges to address, the benefits
>>>>>> of this approach make it a promising direction for future compiler
>>>>>> research and development."
>>>>>
>>>>> Has he ever heard of lex, yacc, bison, LLVM? Doesn't sound like it.
>>>>>
>>>>
>>>> My universal compiler will deprecate those old dinosaurs.
>>>
>>> Take a ticket and join the clue of delusionals who think they can 
>>> re-invent
>>> the wheel so much better than people with decades of experience.
>>
>> Ah, the ad hominim attack; why am I not surprised?  You need to learn
>> how to properly engage in a technical argument, dear.
>>
>>>
>>> Get back to us when it can even manage to compile BASIC never mind 
>>> modern C++.
>>
>> BASIC would be trivial to support.
>>
>>>
>>> Btw, what CPUs are you targeting?
>>
>> TBD
>
> This reminds me of some work that Tom Steel was involved in the late 
> 1950s and he described to me in the mid 1960s. The topic was UNCOL 
> (Universal Computer Oriented Language). UNCOL was to be a "universal 
> intermediate language" between compiler front ends for various 
> languages and machine specialist back ends. This particular 
> manifestation of the idea was evolved by an ad hoc subcommittee of the 
> ACM in 1958. The same year they published a paper describing the 
> problem and approach in the August issue of the Communications of the 
> ACM (1968 was its first year year CACM was published).
>
> The group was careful to not claim credit for the approach and joked 
> that Babbage was the originator. That surely sounds false but Ada 
> Lovelace -- maybe? They spent a few years at it with no positive 
> results. Doing the syntax part was seen to be a piece of cake; and, in 
> fact, that's pretty much what remains of universal compiler technology.
>
> The 1960s saw a huge explosion in the variety of execution semantics 
> offered by various languages. Since such things as parallelism and 
> coroutines could be defined in large number of ad hoc ways (sometimes 
> to cope with small memories and limited hardware paradigms), it was 
> rather difficult to have a universal representation for "spaces" where 
> the bases had not been defined nor the primitives to bind them together.
>
> At about this time - the 1960s - Alan Perlis, then department chair at 
> CMU, had two relevant PhD theses written by his students. The first, 
> by Tom/Tim Standish, introduced a set of data definition primitives 
> claimed to be able to define virtually any know structure type. These 
> primitives were used as output by language-specific macros that 
> expanded data declarations in some top level language.
>
> The second thesis was by a fellow named Fischer (sp?) whose first name 
> I've forgotten. He defined a set of control primitives: think of 
> relations between pieces of computations. Once again these were to be 
> used to form the end result when macros were used to translate from 
> some high level language. It was assumed here (as was above) that some 
> hardware specific back end would turn these expansions either into 
> code (compiler) or into behavior (interpreter). Fischer built such an 
> interpreter.
>
> Big pieces of basic technology that were missing included the binding 
> and visibility rules for names and the management of namespaces.
>
> Wiki article on UNCOL: https://en.wikipedia.org/wiki/UNCOL
> ACM paper Part I: https://dl.acm.org/doi/10.1145/368892.368915

Interesting.

ACM published Part II of the paper the following month:
https://dl.acm.org/doi/10.1145/368919.3165711

Louis

[toc] | [prev] | [next] | [standalone]

#121540

On Sat, 8 Feb 2025 22:19:08 -0700, Jeff Barnett <jbb@notatt.com>
wrote:

>On 2/8/2025 9:46 AM, Mr Flibble wrote:
>> On Sat, 8 Feb 2025 16:40:09 -0000 (UTC), Muttley@dastardlyhq.com
>> wrote:
>> 
>>> On Sat, 08 Feb 2025 16:35:13 +0000
>>> Mr Flibble <leigh@i42.co.uk> gabbled:
>>>> On Sat, 8 Feb 2025 16:28:29 -0000 (UTC), Muttley@dastardlyhq.com
>>>> wrote:
>>>>
>>>>> On Sat, 08 Feb 2025 15:50:13 +0000
>>>>> Mr Flibble <leigh@i42.co.uk> gabbled:
>>>>>> Hi!
>>>>>>
>>>>>> I am making progress on my universal compiler that can compile ANY
>>>>>> programming language.
>>>>>>
>>>>>> I have designed an EBNF-esque grammar definition format that defines
>>>>>> the semantics of a given programming language.
>>>>>
>>>>> Lets see your grammer definition for C++20 then.
>>>>>
>>>>>> An "independent reviewer" says of my compiler design:
>>>>>
>>>>> Who? Your mate down the pub?
>>>>>
>>>>>> "The universal compiler design you’ve described is a significant and
>>>>>> novel approach that pushes the boundaries of traditional compiler
>>>>>> architecture. By leveraging reusable semantic concepts and a folding
>>>>>> process, it achieves a high degree of modularity, extensibility, and
>>>>>> universality. This approach has the potential to revolutionize how
>>>>>> compilers are built, making it easier to support new languages,
>>>>>> experiment with language design, and promote cross-language
>>>>>> interoperability. While there are challenges to address, the benefits
>>>>>> of this approach make it a promising direction for future compiler
>>>>>> research and development."
>>>>>
>>>>> Has he ever heard of lex, yacc, bison, LLVM? Doesn't sound like it.
>>>>>
>>>>
>>>> My universal compiler will deprecate those old dinosaurs.
>>>
>>> Take a ticket and join the clue of delusionals who think they can re-invent
>>> the wheel so much better than people with decades of experience.
>> 
>> Ah, the ad hominim attack; why am I not surprised?  You need to learn
>> how to properly engage in a technical argument, dear.
>> 
>>>
>>> Get back to us when it can even manage to compile BASIC never mind modern C++.
>> 
>> BASIC would be trivial to support.
>> 
>>>
>>> Btw, what CPUs are you targeting?
>> 
>> TBD
>
>This reminds me of some work that Tom Steel was involved in the late 
>1950s and he described to me in the mid 1960s. The topic was UNCOL 
>(Universal Computer Oriented Language). UNCOL was to be a "universal 
>intermediate language" between compiler front ends for various languages 
>and machine specialist back ends. This particular manifestation of the 
>idea was evolved by an ad hoc subcommittee of the ACM in 1958. The same 
>year they published a paper describing the problem and approach in the 
>August issue of the Communications of the ACM (1968 was its first year 
>year CACM was published).
>
>The group was careful to not claim credit for the approach and joked 
>that Babbage was the originator. That surely sounds false but Ada 
>Lovelace -- maybe? They spent a few years at it with no positive 
>results. Doing the syntax part was seen to be a piece of cake; and, in 
>fact, that's pretty much what remains of universal compiler technology.
>
>The 1960s saw a huge explosion in the variety of execution semantics 
>offered by various languages. Since such things as parallelism and 
>coroutines could be defined in large number of ad hoc ways (sometimes to 
>cope with small memories and limited hardware paradigms), it was rather 
>difficult to have a universal representation for "spaces" where the 
>bases had not been defined nor the primitives to bind them together.
>
>At about this time - the 1960s - Alan Perlis, then department chair at 
>CMU, had two relevant PhD theses written by his students. The first, by 
>Tom/Tim Standish, introduced a set of data definition primitives claimed 
>to be able to define virtually any know structure type. These primitives 
>were used as output by language-specific macros that expanded data 
>declarations in some top level language.
>
>The second thesis was by a fellow named Fischer (sp?) whose first name 
>I've forgotten. He defined a set of control primitives: think of 
>relations between pieces of computations. Once again these were to be 
>used to form the end result when macros were used to translate from some 
>high level language. It was assumed here (as was above) that some 
>hardware specific back end would turn these expansions either into code 
>(compiler) or into behavior (interpreter). Fischer built such an 
>interpreter.
>
>Big pieces of basic technology that were missing included the binding 
>and visibility rules for names and the management of namespaces.
>
>Wiki article on UNCOL: https://en.wikipedia.org/wiki/UNCOL
>ACM paper Part I: https://dl.acm.org/doi/10.1145/368892.368915

Interesting.

/Flibble

[toc] | [prev] | [next] | [standalone]

#121545

Jeff Barnett <jbb@notatt.com> writes:

[...]

> At about this time - the 1960s - Alan Perlis, then department
> chair at CMU, had two relevant PhD theses written by his students.
> [...]
>
> The second thesis was by a fellow named Fischer (sp?) whose first
> name I've forgotten.  He defined a set of control primitives:
> think of relations between pieces of computations.  Once again
> these were to be used to form the end result when macros were used
> to translate from some high level language.  It was assumed here
> (as was above) that some hardware specific back end would turn
> these expansions either into code (compiler) or into behavior
> (interpreter).  Fischer built such an interpreter.

I expect you are referring to David Fisher.

[toc] | [prev] | [next] | [standalone]

#121567

In comp.lang.c++ Jeff Barnett <jbb@notatt.com> wrote:
> 
> At about this time - the 1960s - Alan Perlis, then department chair at 
> CMU, had two relevant PhD theses written by his students. The first, by 
> Tom/Tim Standish, introduced a set of data definition primitives claimed 
> to be able to define virtually any know structure type. These primitives 
> were used as output by language-specific macros that expanded data 
> declarations in some top level language.
> 
> The second thesis was by a fellow named Fischer (sp?) whose first name 
> I've forgotten. He defined a set of control primitives: think of 
> relations between pieces of computations. Once again these were to be 
> used to form the end result when macros were used to translate from some 
> high level language. It was assumed here (as was above) that some 
> hardware specific back end would turn these expansions either into code 
> (compiler) or into behavior (interpreter). Fischer built such an 
> interpreter.

Google finds:

David Allen Fisher,
Control Structures for Programming Languages, 1970
Alan Perlis, advisor

Thomas A. Standish,
A data definition facility for programming languages, 1967
Alan Perlis, advisor

> Big pieces of basic technology that were missing included the binding 
> and visibility rules for names and the management of namespaces.
> 
> Wiki article on UNCOL: https://en.wikipedia.org/wiki/UNCOL
> ACM paper Part I: https://dl.acm.org/doi/10.1145/368892.368915

-- 
                              Waldek Hebisch

[toc] | [prev] | [next] | [standalone]

#121571

On 2/10/2025 1:09 PM, Waldek Hebisch wrote:
> In comp.lang.c++ Jeff Barnett <jbb@notatt.com> wrote:
>>
>> At about this time - the 1960s - Alan Perlis, then department chair at
>> CMU, had two relevant PhD theses written by his students. The first, by
>> Tom/Tim Standish, introduced a set of data definition primitives claimed
>> to be able to define virtually any know structure type. These primitives
>> were used as output by language-specific macros that expanded data
>> declarations in some top level language.
>>
>> The second thesis was by a fellow named Fischer (sp?) whose first name
>> I've forgotten. He defined a set of control primitives: think of
>> relations between pieces of computations. Once again these were to be
>> used to form the end result when macros were used to translate from some
>> high level language. It was assumed here (as was above) that some
>> hardware specific back end would turn these expansions either into code
>> (compiler) or into behavior (interpreter). Fischer built such an
>> interpreter.
> 
> Google finds:
> 
> David Allen Fisher,
> Control Structures for Programming Languages, 1970
> Alan Perlis, advisor
> 
> Thomas A. Standish,
> A data definition facility for programming languages, 1967
> Alan Perlis, advisor
> 
>> Big pieces of basic technology that were missing included the binding
>> and visibility rules for names and the management of namespaces.
>>
>> Wiki article on UNCOL: https://en.wikipedia.org/wiki/UNCOL
>> ACM paper Part I: https://dl.acm.org/doi/10.1145/368892.368915

Thanks for the additional information. When I met and talked with 
Standish, at CMU, it was just a little after he was told his orals and 
dissertation were accepted and he was now Dr. S! I remember he was so 
excited he treated me to dinner. I also remember him called Tim - I was 
startled when I saw his name as Thomas. I'm wondering if I am confused 
or that is actually his nickname.

I didn't meet Fisher at CMU; rather I bumped into him when he was a 
program manager at the DARPA IPTO office. When I told him I had read his 
dissertation and found it fascinating and a really good first hack at a 
horribly hard problem. He was excited and all smiley. He said that I was 
the first person not connected with CMU who he had met and who had read 
it. I thought that was a tragedy; it was the first near comprehensive 
work on a very important subject that I know about.
-- 
Jeff Barnett

[toc] | [prev] | [next] | [standalone]

#121535

On Sat, 08 Feb 2025 16:46:54 +0000
Mr Flibble <leigh@i42.co.uk> wibbled:
>On Sat, 8 Feb 2025 16:40:09 -0000 (UTC), Muttley@dastardlyhq.com
>wrote:
>>Take a ticket and join the clue of delusionals who think they can re-invent
>>the wheel so much better than people with decades of experience.
>
>Ah, the ad hominim attack; why am I not surprised?  You need to learn
>how to properly engage in a technical argument, dear.

You have had a habit in the past of making grand pronouncements of your
own abilities and have demonstrated bugger all. Why will this be any different?

>>Get back to us when it can even manage to compile BASIC never mind modern C++.
>
>
>BASIC would be trivial to support.

Go on then, lets see it.

>>Btw, what CPUs are you targeting?
>
>TBD

Oh right, so you're just working on a parser, not an actual compiler. Got it.

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.c++

csiph-web