CBoard Community Project: Poll #1

[Snafuist]

one thing I had considered was a scripting language that was identical to C -- i.e., interpreted C.

Valgrind on steroids sounds a like a great idea. We may even implement array bounds checking.

Greets,
Philip

PS: I suggest that we move the whole discussion to our new forum.

[Brafil]

Sorry, I'd like to join, but I can't see the verification image. It's a fault of my computer, I almost never see them. Could the admin please create an account for me? Thx.

Besides, Technically there is no difference between a scripting and programming language. But IMO scripting is more using OS utilities, file manipulation, makefiles etc. while programming is to do more complex tasks as kernel, GUI or game programming. There is no clean border, but I think you know what you mean. Maybe we could use a C-like syntax, but please not statically-typed.

[phantomotap]

"It's a fault of my computer, I almost never see them. Could the admin please create an account for me?"

Depending on what the problem ultimately is and the software used you could try loading the file in a window of its own.

Soma

[Brafil]

I can't see this registration image. You know, where you enter five or six digits or letters. It doesn't work on another computer here, nor on windows nor on linux. I can't load it because I can't see it, even if I mark the text around the place it had to be.

PS: I'm not a robot! I can see the verification image of this forum.

[MK27]

Re: brainstorming, here is my thought du (yester)jour, which is just a suggestion about *how* we could be brainstorming:
CCP • View topic - brainstorming methodology

I like brewbuck's idea, if we could still put a little OO in. Which does not necessarily mean an interpreted C++. "Eval" sometimes seems like a potentially lazy sloppy thing but it is also a very quick solution for (eg) preventing a user from invoking a runtime error -- this might make the build system *much* more user friendly. Perhaps I or brewbuck or someone else can come up with a little "description" of the concept for those who are not familiar with it. Again I am busy today with other things, unfortunately, but I will actually try to do exactly this over the weekend.

So here's another idea: if people have concepts (like eval) that they know from an (or a number of) existing languages that they think are worth including, put them on the table. But first go read my post on the other forum about *how* to put them on the table...seriously.

ps. I hope someone helped brafil out?

[Snafuist]

Sorry, I'd like to join, but I can't see the verification image. It's a fault of my computer, I almost never see them. Could the admin please create an account for me? Thx.

Send me a PM containing your email address.

Does anybody else have the same problem?

Greets,
Philip

[MK27]

But IMO scripting is more using OS utilities, file manipulation, makefiles etc. while programming is to do more complex tasks as kernel, GUI or game programming. There is no clean border, but I think you know what you mean.

I'll give it to you right now Brafil: IMO this is an irrational prejudice (perhaps you meant "shell scripting"?). The term "script" simply indicates that an interpreter is involved; ie, the program does not run as a process of it's own (the way a binary executable would, because it has been compiled into asm), it runs as a "script" for an interpreter. The reason you will never see a kernel written in a scripting language has nothing to do with limitations of syntax, et al. -- it is because you cannot run an interpreter without a binary executable kernel. In that sense, bytecode interpreted languages like Java use scripts, with an added level of indirection. There will be no Java kernels either.

Consider: this site, which is for the openGL perl bindings, claims that "Due to Perl's strength in string manipulation, there are cases where Perl can even outperform C when loading/manipulating shader programs." Of course, the perl interpreter is written in C. There's a trip.

Conversely, the popularity of interpreted scripting languages is because of the compressed syntax enabled by the interpreter. I have done GUI stuff in perl and C, and my jury is very much still out on the issue of "which is better", ultimately. For sure, you can get more complex much faster/easier with perl, *because* perl is more complex, syntactically, than C.

A moral: Don't bother contrasting "scripting" languages with "non-scripting" languages in terms of performance or usefulness.

[phantomotap]

O_o

Yog Sothoth!

The things you see when you don't have your elephant gun.

Soma

[brewbuck]

So... I've been busy with other things lately, but I'm still around.

Anybody, please let me know if you need something facilitated or otherwise managed, or some kind of impediment removed. I'm here as a resource. It sounds like we're still hashing out our ideas.

[phantomotap]

For whatever reason, the forum software kept claiming my post was source so I gave up and added code tags around everything.

I have an urge to put on a red hat, gesture wildly at
my enemies, and scream "I choose you brewbuck!". ^_^;

The "C as an interpreted language" thing sounds good,
but honestly the choice between '{'/'}', '('/')', or 'BEGIN'/'END'
and other such things don't really make a difference to me.

I'd like to vote to add parametric polymorphisms to that,
but that isn't exactly a necessity I suppose. And that does
kind of kill part of your offerings for wanting C in the first place. 

Where would we go with the include model? Abandon the
actual C model using the `include' directive as an instruction
to the interpreter to load the interfaces if they are available?
Or keep the C model and maybe use `progma' for such things?

I don't know where everyone went... it seems that interest
peeked and died rather quickly. So what's the verdict here?
Did everyone lose interest or am I just over-reading the silence?

Soma

[brewbuck]

I'd like to vote to add parametric polymorphisms to that,
but that isn't exactly a necessity I suppose. And that does
kind of kill part of your offerings for wanting C in the first place.

Where would we go with the include model? Abandon the
actual C model using the `include' directive as an instruction
to the interpreter to load the interfaces if they are available?
Or keep the C model and maybe use `progma' for such things?[/Code]

I would have it work identically (or at least seem so) to compiled C. The idea being you could take a pre-existing C program and execute it in the virtual environment for dynamic analysis. Making the language even a little bit backward-incompatible with C would defeat a large part of the purpose, in my mind.

There are, obviously, difficulties here, like headers which change their behavior if a particular preprocessor symbol is defined. But that doesn't seem insurmountable -- each unique instance of a header can be identified by the file path itself plus information on all the preprocessor state that was in effect at the moment that header was included.

These preprocessed units could be written to disk, somewhat like object files, but not exactly, since in compiled C, an object file corresponds to a "translation unit" and in this case it would correspond to an actual source file plus all preprocessor state. But I think most, if not all of this, could be hidden from the user.

I'd like to see some object oriented features as well, but we're going to need an interpreter base first, anyway, so getting something like that working is a long way out.

Thoughts?

[phantomotap]

"I would have it work [...] purpose, in my mind."

*shrug*

I get what your saying... vanilla C is just such a painful language. Of course, the "OO", functional, and generics facilities I envisioned truly expand C without the difficulties of C++ so we could certainly start at the ground floor adding those facilities as an option later. And since, or at least it seems, that one of your goals in "sandboxing" C is to catch bad uses of the poor type system it is very likely that the base source will have good support for a strong type system before we get to that point.

"There are, obviously, difficulties [...] moment that header was included."

I wasn't even talking about third party headers included from the interpret context. I was talking about the standard C headers and environment headers of the platform (the interpreter itself).

All standard compliant platforms have the `string.h' header, how do we handle that? My suggestion would be to assume conformance of outside standard headers built on "advance knowledge" of how these headers should behave while falsifying the include process for these files (possibly with a fake include directory passed to the interpreter with the same precedence rules as you may find with compilers). Other headers could then be interpreted in the same "sandbox" fashion as the source itself.

Then there are environment headers like "our_make_utility.h"--which would probably be useless in the non-interpreted context--, how do we handle that? I figured we would expose an API to potential consumers, other developers building on the work of the interpreter, that would be used to "fake" such headers as part of interpreting a given translation unit.

I guess I'm asking, within the C inclusion model, how do you envision hooking the API(s) provided by a given build of the interpreter to the real source files? And for structures and functions beyond the standard? And for those compiled into a given build of the interpreter?

Your original offering, or at least one of the original ones, noted a desire for a "single source" tool. With that in mind, I can imagine no way that such things could not be faked, but you probably have something different in mind.

"These preprocessed units [...] hidden from the user."

This seems a reasonable approach for intermediate files... possibly storing prototypes, type information, and that sort of thing in a reasonable table/format instead of the traditional inclusion model (which would then to be parsed as C every time) allowing us to bypass additional passes? (Is this something like modern pre-compiled headers?) Yet another file format would be annoying, but at the same time, parsing/building common files formats with that kind of potential only adds another layer of difficulty. (Thinking specifically of stream-ready formats or plain text files with markup like XML.) I've used SQLite for that kind of thing; the license will certainly not be an issue. Or would you'd rather just stick to a "home grown" file format"?

"I'd like to see some [...] is a long way out."

As it seems that we've dwindled to three or four... never?! >_<

Soma

[brewbuck]

I wasn't even talking about third party headers included from the interpret context. I was talking about the standard C headers and environment headers of the platform (the interpreter itself).

All standard compliant platforms have the `string.h' header, how do we handle that? My suggestion would be to assume conformance of outside standard headers built on "advance knowledge" of how these headers should behave while falsifying the include process for these files (possibly with a fake include directory passed to the interpreter with the same precedence rules as you may find with compilers). Other headers could then be interpreted in the same "sandbox" fashion as the source itself.

We could have a "virtual standard library" like you are suggesting (I think), but if the virtual environment provides enough base functionality, I don't see why we couldn't actually compile a "for real" C standard library like uClibc. At some point any C library has to call out to platform-dependent routines provided by the OS. This would "just" be another port of one of the existing C libraries to the new platform.

I'm not sure yet whether I think that's less work than implementing a virtual C library. Could go either way, I guess.

"These preprocessed units [...] hidden from the user."

This seems a reasonable approach for intermediate files... possibly storing prototypes, type information, and that sort of thing in a reasonable table/format instead of the traditional inclusion model (which would then to be parsed as C every time) allowing us to bypass additional passes? (Is this something like modern pre-compiled headers?) Yet another file format would be annoying, but at the same time, parsing/building common files formats with that kind of potential only adds another layer of difficulty. (Thinking specifically of stream-ready formats or plain text files with markup like XML.) I've used SQLite for that kind of thing; the license will certainly not be an issue. Or would you'd rather just stick to a "home grown" file format"?

The basic need, it seems, is a way of serializing/deserializing the interpreter's internal representation of the compiled source. As far as how that's done, I don't really care as long as whatever method we choose is not a nightmare from an extensibility/backward compatibility standpoint.

As it seems that we've dwindled to three or four... never?! >_<

With summer coming on in the northern hemisphere I expect we'll probably see people shifting back and forth. Some people want to go outside in the summer, for others its the best time to write code.

I admit I haven't even been over to our website lately. I'll try to get some time on this tonight.

[phantomotap]

I'd never considered something like uclibc, and from a cursory glance... it looks like the build environment would suffer from the dependency. I'll look more when I get the chance.

Soma

[Brafil]

@MK27: Yes, I was meaning _shell_ scripting languages. I didn't say shell, cuz for me it's nod interpreted-vs-compiled rather than the things the language was designed for.