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

Groups > alt.os.development > #8901

Re: Smaller C

Show all headers | View raw

On Fri, 09 Oct 2015 05:50:47 -0400, Alexei A. Frounze <alexfrunews@gmail.com> wrote:

> On Thursday, October 8, 2015 at 5:19:22 PM UTC-7, Rod Pemberton wrote:
>> On Thu, 08 Oct 2015 03:22:56 -0400, Alexei A. Frounze <...@gmail.com> wrote:

[...]

>> What more is needed in C?
>
> I've listed some extras above.
>
> I'd like to have better strings and standard containers.

Containers seem to be an object-oriented construct.

So, why would C need this if C has structures?

> And arrays as true first-class types.

What advantage would this offer? ...

E.g., you can always place an array within a struct
to get a first-class type.  You don't even need to
specify the size of the array, due to the C "struct
hack" feature, which was standardized for C99.

#28 C Struct Hack
http://web.archive.org/web/20070807074051/http://home.tiscalinet.ch/t_wolf/tw/c/c9x_changes.html

> I'd like Unicode and regexp's in the language/library.

I'm indifferent and/or mixed on these at this point ...

I see no point in using Unicode to program since ASCII
is sufficient, but Unicode is needed for emitting strings,
nowadays.

Regexp's are convenient, but I've only needed them in
a program a few times, e.g., commandline parameters.

> I'd like multi-precision arithmetic in the language/library.

I'm assuming you meant integer arithmetic here since
C has floats.

The ability to construct larger integers from smaller ones
like with assembly is definately missing in C.  I think most
people will agree upon that.

> I'd like to be able to define functions inside other
> functions simply because their code would be in the right
> context, surrounded by relevant/related code.

Ok.

Another reason that could be useful is for "inheriting"
variables from the outer function into the inner since
it's within outer scope.  This would be useful with
variables declared register.  Implementing this may
be an another issue.

> Richer ways to communicate with the outer world, not just
> stdin/stdout/stderr, even if that's optional functionality
> (e.g. for hosted environment).

I'm not sure of what you mean by this.

A binary stream works with text, binary, files, memory
mapped devices, graphics, etc.

What would you be communicating with, which couldn't be
communicated with via a binary stream? ...

Port I/O is the only thing which comes to my mind.

(Deja Vu...  Did James ask the same?)

> Even if you think that something like Python isn't a
> serious language (it has plenty of shortcomings) or isn't
> going to stay, useful things get done in it and it's
> much easier to write in it than in C because the language
> is richer and there's quite a bit of stuff in its library,
> which has no match in the standard C library. Of course,
> not all richness is necessary or very useful, but some
> is.

I've not used Python, AFAIR.  IIRC, it's converted to C.

For anything which is converted to C, one must ask why
not just use C in the first place?  That includes just
about every language in existence, since they've all
emitted C code or were written in it at some point.  If
someone doesn't have a good justification as to why to
not use C, which they usually don't when asked that,
then I see no point in them using another language.
"All roads lead to Rome."  So, you might as well start
there, IMO.  Of course, Rome fell, but it took a long
time.

>> The usual things mentioned in response to that seems to
>> be features from other languages that people are familiar
>> with, e.g., closures or lists from LISP, etc, or slightly
>> more advanced math concepts such as complex integers.
>> However, none of these are used to program a computer's
>> hardware.  They may be used to program applications.
>
> Sure. And most programmers make applications, which operate
> with higher abstractions than those chiseled in the silicon
> of the CPU. So, why not provide some of those most common
> abstractions?

That is why we have a large C library, and an even larger
POSIX C library, and why Linux has many, many more libraries,
none of which work together or with out-of-date versions of
each other, and now you want even more functionality above,
which is likely to be kept in even more libraries.  ;-)

So, issues with bloat (as indicated sarcasticly above),
or implementation, or portability would be reasons not
to do so.  Do the advantages outweigh the costs?  Are
diminishing returns in effect?  I would probably argue
that the more advanced the concept becomes, the less it
will be used and so it has less value.  At some point,
it doesn't make sense for someone to implement it.

E.g., if you're not plotting Mandelbrot sets or taking
an Algebra class, when would you ever use complex numbers?
Should you construct an entire financial transaction
framework?  Everybody must buy things and take care of
banking.  What about a physics engine?  Everyone is going
to use 3D virtual reality.  When do you stop?  It that
point once we can no longer model anything more in reality?

>> > And then there's another important question. How close
>> > to C or its "spirit" do we want the language to be?
>>
>> How minimal should minimalism be? ...
>
> Forth? Brainfuck? Discrete vacuum tubes? :)

I don't know much about tubes, other than they do much the
same as transistors, have a vacuum, plate, grid etc, emit
electrons, can become very hot, use higher voltages, have
"getter" to absorb oxygen, don't perform IRL as good as in
theory, can be defective despite everyones belief they are
nearly perfect devices, perfectly manufactured, and they
can provide a modified sound which some musicians love.

Getter
https://en.wikipedia.org/wiki/Getter

I've learned much about the first two over the past few years.

Forth, especially ITC Forth, has a number of useful techniques
and features, which could be used for interpreters for other
languages, e.g., 0-operand stacks, threaded code (DTC, ITC),
simplified AST as a dictionary (library), but it seems that
early Forth deviated from it's original designs at some point.
I'm not found of some of what came after the deviation.  It
was more algebraic, like C, than word based, like it is now.

Brainfuck is not really as simple as it seems ...  It uses
many boundary effects.  There are a couple handfuls of commonly
used sequences which are used to implement slightly higher
level operations.  A language designed with these slightly
higher level operations would still be too low-level, but
actually more useful, e.g., perhaps if used inconjunction
with an ITC interpreter and a stack like ITC Forths.  Of
course, ITC Forth dictionaries (library) are usually built
up from a small set of about 35 to 65 "primitives" (low-level
functions).

I'm not sure about the entirety of the ANSI/ICO C libraries,
but I suspect that much of it can also be built up from some
base functions, and odds and ends.  Most minimal C libraries
interface to the host OS with less than 20 functions, mostly
file I/O related.  I'd probably attempt to start with the
memory functions in <string.h> and most of <stiod.h> and
work from there.  I'd be doubtful about building up the POSIX
C libraries that way, simply due to their rather large
size, but it may be possible.

>> I might've expected it
>> from James though with all his philosophical, programming
>> questions.  The Forth language definately takes certain
>> aspects of that much further than C and somewhat too
>> far IMO for various things.
>
> There's usually a fair bit of disagreement because newbies
> naturally want things very different from the pros. And not
> just newbies vs pros. People with different background/
> experience. I wonder if there ever was an attempt to come up
> with a language that could be automatically "zoomed in and
> out" without breaking any code written in it, but by just
> providing different views/interpretations of it. E.g. some
> obscure or non-trivial feature could be expressed as a series
> of easy to grasp features and they could be collapsed back
> into the obscure non-trivial one back, all by a press of
> a key or a turn of a wheel.
>

Every object in C maps onto an array of C bytes.  Is something
like that what you meant?  Or, did you mean something more
along the lines of expanding and collapsing items in a list
in a browser, and dragging and dropping a link into a folder?
So, James was recently discussing modules, and you seem to be
thinking about containers, I'd say in a similar manner.  You
both seem to want some way to organize, build up, and group
smaller pieces into large pieces like Minecraft or Forth or
MacDraw or Visio a does.  Point, click, drag, drop, organize,
link, connect, group, *BOOM* working code ...  Wasn't that
the point of Visual Basic, Visual C/C++, and Visual Studio, etc?

>> > Specifically, how much work will be needed to convert
>> > existing C code to this language?
>>
>> I don't see that as an issue for two reasons.
>>
>> First, new code will be written for this variation,
>> if people enjoy using it or find it to be effective.
>>
>> Second, a more powerful compiler can be modified to
>> produce or reduce code to the variation, if it's that
>> useful to do so, e.g., to bootstrap code.
>
> If you were to get rid of C completely and just have
> this one language instead, wouldn't you want to convert
> the programs that you like to use into this language?

Most likely, but that takes time.  There is a large amount
of in-use code which must be converted, tweaked and tested,
or rewritten from scratch.  Think of converting all C or
Python code etc to a new language 'X'.  Immense.

>> > should it be part of the language (like C is a part of C++)?
>>
>> There are some things which are definately misplaced in C.
>> So, it would be nice if they were also available as part of
>> the C compiler too, e.g., malloc(), free(), exit(), etc.
>
> Compiler? Why? Aren't those OS-specific? Or do you envision
> the OS and the compiler as one thing, much like Forth?

I'd desire them to be optionally available in the compiler so
that only <stdio.h> would be absolutely required for the
minimalist compiler situation.  Once a compiler has a library,
this isn't needed, but may still be useful to someone reducing
library dependence to only <stdio.h>.


Rod Pemberton

-- 
Just how many texting and calendar apps does humanity need?
Just how many food articles from neurotic millenials do we need?

Back to alt.os.development | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Re: Smaller C Peter Cheung <mcheung63@gmail.com> - 2015-10-07 00:10 -0700
  Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-10-07 00:52 -0700
    Re: Smaller C Peter Cheung <mcheung63@gmail.com> - 2015-10-07 02:51 -0700
      Re: Smaller C "wolfgang kern" <nowhere@never.at> - 2015-10-07 21:01 +0200
        Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-10-08 00:25 -0700
          Re: Smaller C "wolfgang kern" <nowhere@never.at> - 2015-10-08 10:50 +0200
            Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-10-08 02:06 -0700
              Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-10-08 19:39 -0400
                Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-10-09 01:00 -0700
                Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-10-09 20:28 -0400
      Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-10-08 00:22 -0700
        Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-10-08 20:19 -0400
          Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-10-09 02:50 -0700
            Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-10-09 22:18 -0400
              Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-10-10 01:48 -0700
                Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-10-12 01:52 -0400
                Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-10-11 23:49 -0700
                Re: Smaller C "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-10-12 20:33 -0400
              Re: Smaller C James Harris <james.harris.1@gmail.com> - 2016-01-16 16:50 +0000
                Re: Smaller C Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-01-23 13:19 -0500
                Re: Smaller C "Alexei A. Frounze" <alexfrunews@gmail.com> - 2016-01-23 13:54 -0800

csiph-web