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

Groups > comp.programming > #419 > unrolled thread

Re: Time for a new language?

Back to article view | Back to comp.programming

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Time for a new language? tm <thomas.mertes@gmx.at> - 2011-06-07 01:17 -0700
    Re: Time for a new language? BGB <cr88192@hotmail.com> - 2011-06-07 03:07 -0700
      Re: Time for a new language? tm <thomas.mertes@gmx.at> - 2011-06-07 04:21 -0700
    Re: Time for a new language? "BartC" <bc@freeuk.com> - 2011-06-07 11:26 +0100
      Re: Time for a new language? pete <pfiland@mindspring.com> - 2011-06-07 07:45 -0400
        Re: Time for a new language? BGB <cr88192@hotmail.com> - 2011-06-07 13:02 -0700
      Re: Time for a new language? tm <thomas.mertes@gmx.at> - 2011-06-07 12:49 -0700
    Re: Time for a new language? gremnebulin <peterdjones@yahoo.com> - 2011-06-13 16:36 -0700
    Re: Time for a new language? Ian Collins <ian-news@hotmail.com> - 2011-06-17 10:25 +1200
      Re: Time for a new language? BGB <cr88192@hotmail.com> - 2011-06-16 23:11 -0700
        Re: Time for a new language? tm <thomas.mertes@gmx.at> - 2011-06-17 01:39 -0700
          Re: Time for a new language? "H.J. Sander Bruggink" <sander.bruggink@uni-due.de> - 2011-06-17 11:05 +0200
            Re: Time for a new language? tm <thomas.mertes@gmx.at> - 2011-06-17 02:54 -0700
          Re: Time for a new language? BGB <cr88192@hotmail.com> - 2011-06-17 10:55 -0700
      Re: Time for a new language? tm <thomas.mertes@gmx.at> - 2011-06-17 00:55 -0700

#419 — Re: Time for a new language?

On 6 Jun., 23:47, "Tony" <nos...@myisp.net> wrote:
> Nomen Nescio wrote:
> > "Tony" <nos...@myisp.net> wrote:
>
> >> Jacko wrote:
>
> >>> long arr = new long[256,-2]; should be more than sufficient,
>
> >> Of course it isn't. You are ignoring the fact that memory footprint
> >> and layout matters sometimes. Either that or you are making a very
> >> HLL, something above the level of C and C++, something at the level
> >> of scripting languages.
>
> > Since when are C or C++ HLLs? I think it goes approximately like this
>
> > microcode -> object code -> assembler -> c -> c++ -> HLL -> Java ->
> > scripting lang
>
> I have always understood and used "HLL" to mean "above assembly
> language". I put C and C++ at the same level. How could one not? That a
> language has more features than another does not put it at a different
> level. Assembly is the LLL and I don't have to worry about anything
> lower. Example:
>
> Low Level: Assembly Language
> High Level: C, C++, Java (but a different animal from C, C++)
> Higher Level: Scripting Languages

Sripting Languages is a coarse description of a goup of languages.
They tend to be interpreted and dynamically typed, but this is not
granted. The only thing that they really have in common is the name
"Scripting Language". There is no reason to consider all languages
with this label "Higher Level".

The term "Higher Level" often includes subjective feelings. People
tend to consider things they like "Higher Level" and things they
don't like "Lower Level". Because of such things an explanation is
needed to show why something is considered higher level.

I consider Seed7 higher level than Java and C++ because Seed7
defines things in libraries that Java and C++ have hard-coded in
their compilers. So I consider arrays defined with an abstract data
type as higher level than hard-coded arrays.

To see how hard-coded things work, look at the C conversions for
numeric values. Chapter A6 of ANSI-K&R distinguishes between:
  Intergral Promotion
  Integral Converions
  Integer and Floating
  Floating Types
  Arithmetic Conversions
  Pointers and Integers
The rules are not simple, and they changed between K&R-C and ANSI-C.
All this rules are hardcoded in every C compiler. Seed7 has no such
rules. There are just definitions of operators and functions for
numeric types. I consider that this simplification makes Seed7
(besides other things) higher level than C.

I consider things, that everybody can define, as higher level than
hard-coded do what I mean concepts (that only authors of compilers
and interpreters can change).


Greetings Thomas Mertes

--
Seed7 Homepage:  http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.

[toc] | [next] | [standalone]

#420

On 6/7/2011 1:17 AM, tm wrote:
> On 6 Jun., 23:47, "Tony"<nos...@myisp.net>  wrote:
>> Nomen Nescio wrote:
>>> "Tony"<nos...@myisp.net>  wrote:
>>
>>>> Jacko wrote:
>>
>>>>> long arr = new long[256,-2]; should be more than sufficient,
>>
>>>> Of course it isn't. You are ignoring the fact that memory footprint
>>>> and layout matters sometimes. Either that or you are making a very
>>>> HLL, something above the level of C and C++, something at the level
>>>> of scripting languages.
>>
>>> Since when are C or C++ HLLs? I think it goes approximately like this
>>
>>> microcode ->  object code ->  assembler ->  c ->  c++ ->  HLL ->  Java ->
>>> scripting lang
>>
>> I have always understood and used "HLL" to mean "above assembly
>> language". I put C and C++ at the same level. How could one not? That a
>> language has more features than another does not put it at a different
>> level. Assembly is the LLL and I don't have to worry about anything
>> lower. Example:
>>
>> Low Level: Assembly Language
>> High Level: C, C++, Java (but a different animal from C, C++)
>> Higher Level: Scripting Languages
>
> Sripting Languages is a coarse description of a goup of languages.
> They tend to be interpreted and dynamically typed, but this is not
> granted. The only thing that they really have in common is the name
> "Scripting Language". There is no reason to consider all languages
> with this label "Higher Level".
>
> The term "Higher Level" often includes subjective feelings. People
> tend to consider things they like "Higher Level" and things they
> don't like "Lower Level". Because of such things an explanation is
> needed to show why something is considered higher level.
>
> I consider Seed7 higher level than Java and C++ because Seed7
> defines things in libraries that Java and C++ have hard-coded in
> their compilers. So I consider arrays defined with an abstract data
> type as higher level than hard-coded arrays.
>
> To see how hard-coded things work, look at the C conversions for
> numeric values. Chapter A6 of ANSI-K&R distinguishes between:
>    Intergral Promotion
>    Integral Converions
>    Integer and Floating
>    Floating Types
>    Arithmetic Conversions
>    Pointers and Integers
> The rules are not simple, and they changed between K&R-C and ANSI-C.
> All this rules are hardcoded in every C compiler. Seed7 has no such
> rules. There are just definitions of operators and functions for
> numeric types. I consider that this simplification makes Seed7
> (besides other things) higher level than C.
>
> I consider things, that everybody can define, as higher level than
> hard-coded do what I mean concepts (that only authors of compilers
> and interpreters can change).
>

and, in my current scripting language, currently more stuff is 
hard-coded into the VM than in Java...


I disagree though that it makes it inherently lower-level though. just 
that the present main strategy is to implement things in C, and plug 
things into the VM (a lot is also done via vtables and callbacks).

this does make it easier for C code to extend/customize the VM, just 
this isn't so readily available for HLL code.

for example, many "Object" methods, such as "toString()" are infact 
special-case logic, which is redirected through C-side vtable structures 
by the VM (may redirect back to object methods for some types, such as 
Class/Instance objects).

others, such as "clone()", are handled by VM bytecodes. "toString()" 
could also be made into a bytecoded operation, FWIW.

strings themselves are pretty much entirely built-in types.
...


recently I also added new syntax for literal fixed type arrays:
"[1,2,3]UB" creates a 3 element array of unsigned bytes (this seemed 
like the "least nasty" solution).

as well as adding basic VM support for "value types" (could be used for 
"structs" or similar, and for other pass-by-value stuff).


or such...

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

#422

On 7 Jun., 12:07, BGB <cr88...@hotmail.com> wrote:
> On 6/7/2011 1:17 AM, tm wrote:
>
> > On 6 Jun., 23:47, "Tony"<nos...@myisp.net>  wrote:
>
> >> I have always understood and used "HLL" to mean "above assembly
> >> language". I put C and C++ at the same level. How could one not? That a
> >> language has more features than another does not put it at a different
> >> level. Assembly is the LLL and I don't have to worry about anything
> >> lower. Example:
>
> >> Low Level: Assembly Language
> >> High Level: C, C++, Java (but a different animal from C, C++)
> >> Higher Level: Scripting Languages
>
> > Sripting Languages is a coarse description of a goup of languages.
> > They tend to be interpreted and dynamically typed, but this is not
> > granted. The only thing that they really have in common is the name
> > "Scripting Language". There is no reason to consider all languages
> > with this label "Higher Level".
>
> > The term "Higher Level" often includes subjective feelings. People
> > tend to consider things they like "Higher Level" and things they
> > don't like "Lower Level". Because of such things an explanation is
> > needed to show why something is considered higher level.
>
> > I consider Seed7 higher level than Java and C++ because Seed7
> > defines things in libraries that Java and C++ have hard-coded in
> > their compilers. So I consider arrays defined with an abstract data
> > type as higher level than hard-coded arrays.
>
> > To see how hard-coded things work, look at the C conversions for
> > numeric values. Chapter A6 of ANSI-K&R distinguishes between:
> >    Intergral Promotion
> >    Integral Converions
> >    Integer and Floating
> >    Floating Types
> >    Arithmetic Conversions
> >    Pointers and Integers
> > The rules are not simple, and they changed between K&R-C and ANSI-C.
> > All this rules are hardcoded in every C compiler. Seed7 has no such
> > rules. There are just definitions of operators and functions for
> > numeric types. I consider that this simplification makes Seed7
> > (besides other things) higher level than C.
>
> > I consider things, that everybody can define, as higher level than
> > hard-coded do what I mean concepts (that only authors of compilers
> > and interpreters can change).
>
> and, in my current scripting language, currently more stuff is
> hard-coded into the VM than in Java...
>
> I disagree though that it makes it inherently lower-level though. just
> that the present main strategy is to implement things in C, ...

I talked about the interface to a feature, not about its
implementation. The interface should be defined in the language.
The implementation can be done in a different language, e.g.: C.
In case of functions and operators the interface is just the
function header.

The Seed7 library "integer.s7i" defines the addition of integers
with:

  const func integer:
     (in integer: summand1) + (in integer: summand2)
                                                is action "INT_ADD";

You now know that adding two integers yields an integer result.
The 'in' parameters tell you that 'summand1' and 'summand2' will
not be changed by + and that 'summand1' and 'summand2' can be
expressions.

The priority and associativity of the + operator is defined in
the library "syntax.s7i" with:

  $ syntax expr: .(). + .()                is  ->  7;

This tells you that + is an infix operator with priority 7 and it
works left to right. When + is overloaded (e.g. for float) the
overloaded + will have the same priority and associativity. So
only one syntax declaration for the (infix) + operator is needed.

In the example above the function body consists of:

  action "INT_ADD"

This refers to a C function, which implements the integer addition.
In an interpreted program the C function int_add() the does integer
addition. In a compiled program inlined C code is used instead.

BTW, the integer.s7i library is described at:

   http://seed7.sourceforge.net/libraries/integer.htm)

This is not the only library described. The Seed7 Homepage
contains descriptions of 50 libraries. See:

  http://seed7.sourceforge.net/libraries

> ...
> strings themselves are pretty much entirely built-in types.

All functions that deal Seed7 strings are defined in libraries. The
basic string functions are defined in the "string.s7i" library. See:

  http://seed7.sourceforge.net/libraries/string.htm

> recently I also added new syntax for literal fixed type arrays:
> "[1,2,3]UB" creates a 3 element array of unsigned bytes (this seemed
> like the "least nasty" solution).

Seed7 defines array literals also with operators.
Even in this case hard-coded syntax is not necessary.


Greetings Thomas Mertes

--
Seed7 Homepage:  http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.

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

#421

"tm" <thomas.mertes@gmx.at> wrote in message 
news:043628bb-8b8b-4094-8e7b-b1c61a69b525@c41g2000yqm.googlegroups.com...

> I consider Seed7 higher level than Java and C++ because Seed7
> defines things in libraries that Java and C++ have hard-coded in
> their compilers.

Isn't it the other way around? If a feature exists only in a library, it 
must be defined using more primitive elements in the language.

If the feature is built into the language, then surely that makes it higher 
level?

> So I consider arrays defined with an abstract data
> type as higher level than hard-coded arrays.

Arrays are usually fairly primitive types. If a language doesn't directly 
have arrays, and they have to be constructed (by building a new data-type 
with pointers or whatever), again I don't see that as a high-level feature!

> I consider things, that everybody can define, as higher level than
> hard-coded do what I mean concepts (that only authors of compilers
> and interpreters can change).

A brick, that can be used to make anything, is higher level than a 
pre-fabricated section? I don't think so. Although certainly it is useful to 
be able to make something different..

-- 
Bartc 

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

#423

BartC wrote:
> 
> "tm" <thomas.mertes@gmx.at> wrote in message
> news:043628bb-8b8b-4094-8e7b-b1c61a69b525@c41g2000yqm.googlegroups.com...
> 
> > I consider Seed7 higher level than Java and C++ because Seed7
> > defines things in libraries that Java and C++ have hard-coded in
> > their compilers.
> 
> Isn't it the other way around?
> If a feature exists only in a library, it
> must be defined using more primitive elements in the language.

C standard library functions don't have to be written in C.

-- 
pete

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

#427

On 6/7/2011 4:45 AM, pete wrote:
> BartC wrote:
>>
>> "tm"<thomas.mertes@gmx.at>  wrote in message
>> news:043628bb-8b8b-4094-8e7b-b1c61a69b525@c41g2000yqm.googlegroups.com...
>>
>>> I consider Seed7 higher level than Java and C++ because Seed7
>>> defines things in libraries that Java and C++ have hard-coded in
>>> their compilers.
>>
>> Isn't it the other way around?
>> If a feature exists only in a library, it
>> must be defined using more primitive elements in the language.
>
> C standard library functions don't have to be written in C.
>

yes, and in fact, some of them often aren't...

operations like strcmp, sin/cos/tan, ... are very often implemented in 
assembler, and also very often, also built right into the compiler (say, 
your call to strcmp or memcpy causing the compiler to emit specialized 
machine code).


also, my language (BGBScript) is in the category where, at present, the 
vast majority of its basic functionality is hard-coded into the VM.

for example, unlike Java, at present there are no 'Integer' or 'String' 
or 'Array' classes, ...


an advantage of not having 'String' though, is that the strings can be 
represented in a much lighter weight way, namely, the string can be 
encoded in UTF-8 and stored directly into memory.

if I did it like in Java, every string would involve:
a class instance;
an array of UTF-16 codepoints;
...

this would cost significantly more memory, as each class and array involves:
an object header;
the object data.


so, at present, built-in string "Hello":
uses 16-bytes of memory (8 byte GC header, padded up to multiple of 16).
I could store them a little more efficiently in string-tables, but this 
would give up the ability to GC old strings.


if I did it as an instance of a class:
32 bytes, object header, 16 bytes object data;
32 bytes, array header, 32 bytes array data.
total cost: 112 bytes.

is it worth using 7x the memory? IMO, no.
this is for x86, x86-64 would be a bit more (since there are pointers 
involved).

also, the internals would be a bit more complicated, and string 
operations likely a good deal more costly, if classes were used.

now, what about:
class Cons {
var lcar;
var lcdr;
function get car() return lcar;
function get cdr() return lcdr;
function set car(v) lcar=v;
function set cdr(v) lcdr=v;
function get caar() return lcar.car;
...
}

well, this would be looking at 48 bytes per cons (x86).
in the GC, cons cells take, 8 bytes (on x86, 16 bytes on x86-64).
worth a 6x memory overhead?... no.


also, in Java, when one does, say:
int i=42;
String s=i.toString();

it actually does the equivalent of:
String s=new Integer(i).toString();


so, at times, there seems to be good reason in hard-coding some things.


also, it makes it all a bit easier to customize and extend, from C...
after all, being a scripting language, the primary role of BGBScript is 
to expose application-provided functionality. it really doesn't need to 
be its own self-defining or self-contained island, as there is really 
not a whole lot to gain from this...


or such...

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

#426

On 7 Jun., 12:26, "BartC" <b...@freeuk.com> wrote:
> "tm" <thomas.mer...@gmx.at> wrote in message
>
> news:043628bb-8b8b-4094-8e7b-b1c61a69b525@c41g2000yqm.googlegroups.com...
>
> > I consider Seed7 higher level than Java and C++ because Seed7
> > defines things in libraries that Java and C++ have hard-coded in
> > their compilers.
>
> Isn't it the other way around? If a feature exists only in a library, it
> must be defined using more primitive elements in the language.

Features defined in a library can be used in the same way as
built-in features. Neither the usage nor the performance differs.
But when a feature is defined in a library its interface is
accessible to normal users. You can look into the library and you
will find the interface (header) of the feature. The interface of
a build-in feature is defined in a reference manual or in the
compiler / interpreter source. But reference manuals and
compiler / interpreter source are just something different.
Reference manuals use natural language, but the interface (header)
of a feature is defined in the programming language itself.

> If the feature is built into the language, then surely that makes it higher
> level?

You seem to separate a language from its library. For me the
standard libraries, the libraries which are always shipped with the
language, are part of the picture. Otherwise a language with
everything built-in, including the kitchen sink, would be the
highest level language. When language and standard libraries are
viewed together, moving a feature to a library makes the pure
language more slim and elegant. Note that many languages are not
capable to define statements or user defined operators in a library.
This languages have no choice and must provide such features
built-in. As such Seed7 is higher level because even the most basic
features (the statements and operators of the language) can be (and
in fact they are) defined in a library.

> > So I consider arrays defined with an abstract data
> > type as higher level than hard-coded arrays.
>
> Arrays are usually fairly primitive types. If a language doesn't directly
> have arrays, and they have to be constructed (by building a new data-type
> with pointers or whatever), again I don't see that as a high-level feature!

The user does not need to construct arrays from pointers or
something else. Arrays are predefined and provide good performance
(for resizeable arrays). The difference to built-in arrays is:
The interfaces of all functions provided by arrays can be looked up
in a library. The body of most array functions consists of so called
primitive actions. A primitive action corresponds to a C function
which implements the functionality (compiled programs use inline
code instead). E.g.: The action "ARR_IDX" provides access to an
array element by indexing. Many languages provide user defined
containers. Some of them even use the syntax of arrays for them
(indexing with [ etc.). The Seed7 arrays use the usual syntax and
are defined the same way as other containers (in a library).

> > I consider things, that everybody can define, as higher level than
> > hard-coded do what I mean concepts (that only authors of compilers
> > and interpreters can change).
>
> A brick, that can be used to make anything, is higher level than a
> pre-fabricated section?

A system that allows user defined pre-fabricated sections is
higher level compared to one that only provides a fixed set of
pre-fabricated sections.


Greetings Thomas Mertes

--
Seed7 Homepage:  http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.

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

#469

On Jun 7, 9:17 am, tm <thomas.mer...@gmx.at> wrote:
> On 6 Jun., 23:47, "Tony" <nos...@myisp.net> wrote:
>
>
>
> > Nomen Nescio wrote:
> > > "Tony" <nos...@myisp.net> wrote:
>
> > >> Jacko wrote:
>
> > >>> long arr = new long[256,-2]; should be more than sufficient,
>
> > >> Of course it isn't. You are ignoring the fact that memory footprint
> > >> and layout matters sometimes. Either that or you are making a very
> > >> HLL, something above the level of C and C++, something at the level
> > >> of scripting languages.
>
> > > Since when are C or C++ HLLs? I think it goes approximately like this
>
> > > microcode -> object code -> assembler -> c -> c++ -> HLL -> Java ->
> > > scripting lang
>
> > I have always understood and used "HLL" to mean "above assembly
> > language". I put C and C++ at the same level. How could one not? That a
> > language has more features than another does not put it at a different
> > level. Assembly is the LLL and I don't have to worry about anything
> > lower. Example:
>
> > Low Level: Assembly Language
> > High Level: C, C++, Java (but a different animal from C, C++)
> > Higher Level: Scripting Languages
>
> Sripting Languages is a coarse description of a goup of languages.
> They tend to be interpreted and dynamically typed, but this is not
> granted. The only thing that they really have in common is the name
> "Scripting Language". There is no reason to consider all languages
> with this label "Higher Level".
>
> The term "Higher Level" often includes subjective feelings. People
> tend to consider things they like "Higher Level" and things they
> don't like "Lower Level". Because of such things an explanation is
> needed to show why something is considered higher level.
>
> I consider Seed7 higher level than Java and C++ because Seed7
> defines things in libraries that Java and C++ have hard-coded in
> their compilers. So I consider arrays defined with an abstract data
> type as higher level than hard-coded arrays.
>
> To see how hard-coded things work, look at the C conversions for
> numeric values. Chapter A6 of ANSI-K&R distinguishes between:
>   Intergral Promotion
>   Integral Converions
>   Integer and Floating
>   Floating Types
>   Arithmetic Conversions
>   Pointers and Integers
> The rules are not simple, and they changed between K&R-C and ANSI-C.
> All this rules are hardcoded in every C compiler. Seed7 has no such
> rules. There are just definitions of operators and functions for
> numeric types. I consider that this simplification makes Seed7
> (besides other things) higher level than C.
>
> I consider things, that everybody can define, as higher level than
> hard-coded do what I mean concepts (that only authors of compilers
> and interpreters can change).
>
The next logical step in higher levelness: pluggable types.

> Greetings Thomas Mertes
>
> --
> Seed7 Homepage:  http://seed7.sourceforge.net
> Seed7 - The extensible programming language: User defined statements
> and operators, abstract data types, templates without special
> syntax, OO with interfaces and multiple dispatch, statically typed,
> interpreted or compiled, portable, runs under linux/unix/windows.

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

#478

On 06/ 7/11 08:17 PM, tm wrote:
>
> I consider Seed7 higher level than Java and C++ because Seed7
> defines things in libraries that Java and C++ have hard-coded in
> their compilers. So I consider arrays defined with an abstract data
> type as higher level than hard-coded arrays.
>
> To see how hard-coded things work, look at the C conversions for
> numeric values. Chapter A6 of ANSI-K&R distinguishes between:
>    Intergral Promotion
>    Integral Converions
>    Integer and Floating
>    Floating Types
>    Arithmetic Conversions
>    Pointers and Integers
> The rules are not simple, and they changed between K&R-C and ANSI-C.

They may not be simple, but they are well understood and contribute to 
the metaphors that enable C programmers to understand each other's code.

> All this rules are hardcoded in every C compiler. Seed7 has no such
> rules. There are just definitions of operators and functions for
> numeric types. I consider that this simplification makes Seed7
> (besides other things) higher level than C.

Isn't that a recipe for write only code?  The reader not only has to 
follow the logic the code attempts to express, but also the rules used 
to express the logic.

> I consider things, that everybody can define, as higher level than
> hard-coded do what I mean concepts (that only authors of compilers
> and interpreters can change).

That's a bit like saying Leggo is the highest level toy...

-- 
Ian Collins

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

#479

On 6/16/2011 3:25 PM, Ian Collins wrote:
> On 06/ 7/11 08:17 PM, tm wrote:
>>
>> I consider Seed7 higher level than Java and C++ because Seed7
>> defines things in libraries that Java and C++ have hard-coded in
>> their compilers. So I consider arrays defined with an abstract data
>> type as higher level than hard-coded arrays.
>>
>> To see how hard-coded things work, look at the C conversions for
>> numeric values. Chapter A6 of ANSI-K&R distinguishes between:
>> Intergral Promotion
>> Integral Converions
>> Integer and Floating
>> Floating Types
>> Arithmetic Conversions
>> Pointers and Integers
>> The rules are not simple, and they changed between K&R-C and ANSI-C.
>
> They may not be simple, but they are well understood and contribute to
> the metaphors that enable C programmers to understand each other's code.
>

yeah, and generally the rules make sense...


>> All this rules are hardcoded in every C compiler. Seed7 has no such
>> rules. There are just definitions of operators and functions for
>> numeric types. I consider that this simplification makes Seed7
>> (besides other things) higher level than C.
>
> Isn't that a recipe for write only code? The reader not only has to
> follow the logic the code attempts to express, but also the rules used
> to express the logic.
>

yeah...

in my case, I think it much more sensible to hard-code all the basics, 
and allow plugins for the rest...


for example, consider a person wants to add "some feature X" to the 
language, how may they do it?...

well, they can create a loadable component which:
plugs itself into the parser, so that the new syntax may be parsed;
plugs itself into the bytecode compiler so, that any new AST structures 
can be compiled;
maybe plugs into the bytecode VM, adding support for any new opcodes;
adds stuff for any new types;
...

ultimately, this is probably good enough, and if one really wants, an 
extension can be written which allows calling back into the language to 
implement extensions.


>> I consider things, that everybody can define, as higher level than
>> hard-coded do what I mean concepts (that only authors of compilers
>> and interpreters can change).
>
> That's a bit like saying Leggo is the highest level toy...
>

yeah, Lego is probably a lower-level toy, if anything because one is 
building things out of blocks, rather than out of pre-formed pieces.

FWIW, ASM also allows building programs out of large numbers of 
fundamental parts, and this is generally called low-level.

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

#481

On 17 Jun., 08:11, BGB <cr88...@hotmail.com> wrote:
> On 6/16/2011 3:25 PM, Ian Collins wrote:
>
>
>
> > On 06/ 7/11 08:17 PM, tm wrote:
>
> >> I consider Seed7 higher level than Java and C++ because Seed7
> >> defines things in libraries that Java and C++ have hard-coded in
> >> their compilers. So I consider arrays defined with an abstract data
> >> type as higher level than hard-coded arrays.
>
> >> To see how hard-coded things work, look at the C conversions for
> >> numeric values. Chapter A6 of ANSI-K&R distinguishes between:
> >> Intergral Promotion
> >> Integral Converions
> >> Integer and Floating
> >> Floating Types
> >> Arithmetic Conversions
> >> Pointers and Integers
> >> The rules are not simple, and they changed between K&R-C and ANSI-C.
>
> > They may not be simple, but they are well understood and contribute to
> > the metaphors that enable C programmers to understand each other's code.
>
> yeah, and generally the rules make sense...

You are probably used to them. Sometimes it helps to
take a step backward (to get a broader view). A neutral
outsider would probably have a different view on the rules.

> >> All this rules are hardcoded in every C compiler. Seed7 has no such
> >> rules. There are just definitions of operators and functions for
> >> numeric types. I consider that this simplification makes Seed7
> >> (besides other things) higher level than C.
>
> > Isn't that a recipe for write only code? The reader not only has to
> > follow the logic the code attempts to express, but also the rules used
> > to express the logic.
>
> yeah...
>
> in my case, I think it much more sensible to hard-code all the basics,
> and allow plugins for the rest...

Plugins are a fashion now. Firefox, Eclipse and many other
programs use them. It is iteresting to see that my ideas
become acceptable, when the term plugin is used. But plugins
are IMHO a much more low level concept to reach the same goal.
A plugin usually has access to the data structure of the main
program via an API. I see my approach with syntax definitions
(see: http://seed7.sourceforge.net/manual/syntax.htm) and
function definitions (which use the new introduced syntax)
as much more high level.

> for example, consider a person wants to add "some feature X" to the
> language, how may they do it?...
>
> well, they can create a loadable component which:
> plugs itself into the parser, ...
> plugs itself into the bytecode compiler so, ...
> maybe plugs into the bytecode VM, ...

What a complicated concept. You need to know the internals
of parser, compiler and VM to do that.

I suggest that a person who wants to add "some feature X"
takes a look at Seed7. :-)

> ultimately, this is probably good enough, ...

This must be a joke. You expect that people know the
internals of your parser, compiler and VM to do something
that Seed7 can do in just a few lines?

[snip]

> >> I consider things, that everybody can define, as higher level than
> >> hard-coded do what I mean concepts (that only authors of compilers
> >> and interpreters can change).
>
> > That's a bit like saying Leggo is the highest level toy...
>
> yeah, Lego is probably a lower-level toy, if anything because one is
> building things out of blocks, rather than out of pre-formed pieces.

You probably haven't played with Lego for a long time.
(I have children, so I see what Lego provides now).
Now they use a lot of pre-formed pieces which allow some
things to be build more quickly. But this has the
disadvantage that some things become impossible to create.

> FWIW, ASM also allows building programs out of large numbers of
> fundamental parts, and this is generally called low-level.

ASM has a 1:1 mapping to machine code, this was the reason
it was considered a 2nd generation language.


Greetings Thomas Mertes

--
Seed7 Homepage:  http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.

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

#482

On 06/17/2011 10:39 AM, tm wrote:
> You are probably used to them. Sometimes it helps to
> take a step backward (to get a broader view). A neutral
> outsider would probably have a different view on the rules.

A very good tip! Maybe you should try it yourself with your
own language, as well.

groente
-- Sander

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

#484

On 17 Jun., 11:05, "H.J. Sander Bruggink" <sander.brugg...@uni-due.de>
wrote:
> On 06/17/2011 10:39 AM, tm wrote:
>
> > You are probably used to them. Sometimes it helps to
> > take a step backward (to get a broader view). A neutral
> > outsider would probably have a different view on the rules.
>
> A very good tip! Maybe you should try it yourself with your
> own language, as well.

Okay.
What are you trying to tell me?


Greetings Thomas Mertes

--
Seed7 Homepage:  http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.

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

#485

On 6/17/2011 1:39 AM, tm wrote:
> On 17 Jun., 08:11, BGB<cr88...@hotmail.com>  wrote:
>> On 6/16/2011 3:25 PM, Ian Collins wrote:
>>
>>
>>
>>> On 06/ 7/11 08:17 PM, tm wrote:
>>
>>>> I consider Seed7 higher level than Java and C++ because Seed7
>>>> defines things in libraries that Java and C++ have hard-coded in
>>>> their compilers. So I consider arrays defined with an abstract data
>>>> type as higher level than hard-coded arrays.
>>
>>>> To see how hard-coded things work, look at the C conversions for
>>>> numeric values. Chapter A6 of ANSI-K&R distinguishes between:
>>>> Intergral Promotion
>>>> Integral Converions
>>>> Integer and Floating
>>>> Floating Types
>>>> Arithmetic Conversions
>>>> Pointers and Integers
>>>> The rules are not simple, and they changed between K&R-C and ANSI-C.
>>
>>> They may not be simple, but they are well understood and contribute to
>>> the metaphors that enable C programmers to understand each other's code.
>>
>> yeah, and generally the rules make sense...
>
> You are probably used to them. Sometimes it helps to
> take a step backward (to get a broader view). A neutral
> outsider would probably have a different view on the rules.
>

the type tower, promotion rules, ... are not magic.


>>>> All this rules are hardcoded in every C compiler. Seed7 has no such
>>>> rules. There are just definitions of operators and functions for
>>>> numeric types. I consider that this simplification makes Seed7
>>>> (besides other things) higher level than C.
>>
>>> Isn't that a recipe for write only code? The reader not only has to
>>> follow the logic the code attempts to express, but also the rules used
>>> to express the logic.
>>
>> yeah...
>>
>> in my case, I think it much more sensible to hard-code all the basics,
>> and allow plugins for the rest...
>
> Plugins are a fashion now. Firefox, Eclipse and many other
> programs use them. It is iteresting to see that my ideas
> become acceptable, when the term plugin is used. But plugins
> are IMHO a much more low level concept to reach the same goal.
> A plugin usually has access to the data structure of the main
> program via an API. I see my approach with syntax definitions
> (see: http://seed7.sourceforge.net/manual/syntax.htm) and
> function definitions (which use the new introduced syntax)
> as much more high level.
>

probably everyone here knows by now how you are doing things...

I am doing things differently, mostly hard-coding most core parts of the 
language, and using plugins for the rest.


>> for example, consider a person wants to add "some feature X" to the
>> language, how may they do it?...
>>
>> well, they can create a loadable component which:
>> plugs itself into the parser, ...
>> plugs itself into the bytecode compiler so, ...
>> maybe plugs into the bytecode VM, ...
>
> What a complicated concept. You need to know the internals
> of parser, compiler and VM to do that.
>

most of it is done via API, most of which can abstract over a lot of the 
"ugly details". partly, this is called "abstraction".

anyways, one could argue the same thing against, say, Lisp, because you 
need to know all these ugly details of how Lisp works in order to use it.


most of the low-level VM interfacing would likely involve a lot of 
dynamic types and S-Expressions, as this is a large part of what the VM 
is built on (most of these APIs are independent of the VM itself).

although not perfect, the parser API mostly boils down to S-Expressions 
/ Lists and a "char **" pointer (the latter may be wrapped in some sort 
of API, as to hide its "char **" nature).

actually, the AST format is vaguely similar to Scheme, albeit with some 
alterations over the years mostly to address representation issues.

the main alternative would have been XML based, but it seems at this 
point, S-Exps won this particular game.


either way, it is not assumed here that newbies will be sitting around 
writing VM plugins, as FWIW, newbies will make nastiness of pretty much 
any feature they use.


> I suggest that a person who wants to add "some feature X"
> takes a look at Seed7. :-)
>
>> ultimately, this is probably good enough, ...
>
> This must be a joke. You expect that people know the
> internals of your parser, compiler and VM to do something
> that Seed7 can do in just a few lines?
>

FWIW, this may not matter.


the main use for language extensions would likely be to add DSL-like 
functionality, which would ultimately depend mostly on the host app.

it then allows a host app, presumably written in C or C++, to plug in 
whatever new features it needs.

the language doesn't really need to be self-extending, because this 
isn't really all that likely to be useful.



>>>> I consider things, that everybody can define, as higher level than
>>>> hard-coded do what I mean concepts (that only authors of compilers
>>>> and interpreters can change).
>>
>>> That's a bit like saying Leggo is the highest level toy...
>>
>> yeah, Lego is probably a lower-level toy, if anything because one is
>> building things out of blocks, rather than out of pre-formed pieces.
>
> You probably haven't played with Lego for a long time.
> (I have children, so I see what Lego provides now).
> Now they use a lot of pre-formed pieces which allow some
> things to be build more quickly. But this has the
> disadvantage that some things become impossible to create.
>
>> FWIW, ASM also allows building programs out of large numbers of
>> fundamental parts, and this is generally called low-level.
>
> ASM has a 1:1 mapping to machine code, this was the reason
> it was considered a 2nd generation language.
>

yes, and as a child (elementary-school years) ASM (along with BASIC, 
namely QBasic) was one of the earlier languages I learned...

initially, I actually understood ASM a bit better than C, but C had its 
merits which made me mostly switch to it as my primary language 
(actually, early on I partly learned C by compiling programs to ASM and 
then reading the ASM output, giving me more a grasp on what some of 
these code fragments were doing).

at one point I had tried, without all that much success, to bridge 
between ASM and QBasic.

what finally killed me using Basic was (then in middle school) jumping 
ship to Linux as my main OS for a number of years, where Linux didn't 
have QBasic, so most new code was written solely in C.


and then many years went by...

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

#480

On 17 Jun., 00:25, Ian Collins <ian-n...@hotmail.com> wrote:
> On 06/ 7/11 08:17 PM, tm wrote:
>
>
>
> > I consider Seed7 higher level than Java and C++ because Seed7
> > defines things in libraries that Java and C++ have hard-coded in
> > their compilers. So I consider arrays defined with an abstract data
> > type as higher level than hard-coded arrays.
>
> > To see how hard-coded things work, look at the C conversions for
> > numeric values. Chapter A6 of ANSI-K&R distinguishes between:
> >    Intergral Promotion
> >    Integral Converions
> >    Integer and Floating
> >    Floating Types
> >    Arithmetic Conversions
> >    Pointers and Integers
> > The rules are not simple, and they changed between K&R-C and ANSI-C.
>
> They may not be simple, but they are well understood ...

They are fair understood by people who already know C.
I am quite sure that most C programmers had experiences
where they searched for the reason of an overflow or a
compilation warning regarding implicit conversions.

> ... and contribute to
> the metaphors that enable C programmers to understand each other's code.

In other words:
When you know a language you can understand programs
written in it. This is self-evident and has nothing to
do with the complexity of the rules above.

> > All this rules are hardcoded in every C compiler. Seed7 has no such
> > rules. There are just definitions of operators and functions for
> > numeric types. I consider that this simplification makes Seed7
> > (besides other things) higher level than C.
>
> Isn't that a recipe for write only code?

Why should it be?
The rules in Seed7 are simpler and the interfaces of all
operators and functions can be found in libraries.

> The reader not only has to
> follow the logic the code attempts to express, but also the rules used
> to express the logic.

This is true for every programming language. As stated
above the rules to express the logic in Seed7 are simpler.

> > I consider things, that everybody can define, as higher level than
> > hard-coded do what I mean concepts (that only authors of compilers
> > and interpreters can change).
>
> That's a bit like saying Leggo is the highest level toy...

The area of toys is much larger than the area of programming
languages. Comparing programming languages is more like
comparing construction kits.

Construction kits often have pre fabricated special parts.
E.g. the undercarriage of a train. This is advantageous,
since it allows you to build a train more quickly. Now
assume you want to build a steam locomotion whith big wheels
and coupling rods. When no such pre fabricated part exists,
you are out of luck.

When a construction kitt offers you a way to create your
own special parts, your possibilities multiply. In case of
the steam locomotion you need separate wheels in different
sizes and pieces to be used as coupling rod.

That is what Seed7 offers you: Pre fabricated parts AND
the possibility to create your own special parts.


Greetings Thomas Mertes

--
Seed7 Homepage:  http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.programming

csiph-web