|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I've uploaded the current documentation for my CSDL project at:
http://homepage.mac.com/chrishuff/csdl.html
As for the interpreter, I'll probably just rewrite it, using what I
learned the first time to make the new one better. The core will be
written in platform-independant C++, and the OS X version will have a
Cocoa GUI interface.
Any comments/suggestions?
--
--
Christopher James Huff <chr### [at] maccom>
Post a reply to this message
|
|
| |
| |
|
|
From: Thorsten Froehlich
Subject: Re: CSDL: C-like Simulation Description Language
Date: 12 Jan 2002 12:11:45
Message: <3c406e51@news.povray.org>
|
|
|
| |
| |
|
|
In article <chr### [at] netplexaussieorg> ,
Christopher James Huff <chr### [at] maccom> wrote:
> I've uploaded the current documentation for my CSDL project at:
> http://homepage.mac.com/chrishuff/csdl.html
>
> As for the interpreter, I'll probably just rewrite it, using what I
> learned the first time to make the new one better. The core will be
> written in platform-independant C++, and the OS X version will have a
> Cocoa GUI interface.
> Any comments/suggestions?
Looks interesting. The idea of using a simple C/C++ like language with more
abstract data types and then translate to plain C/C++ is really powerful.
Using your idea together with "full" function support in POV-Ray 4.0 * might
i.e. allow to develop POV-Ray source code (like new objects) in POV-Ray
itself and then just run it through a C/C++ converter to generate fast code
after everything has been debugged. This could speed up the development
cycle and the rewrite in general...
Thorsten
* Just mentioning it, I don't want to get into any discussion about 4.0!
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3c406e51@news.povray.org>,
"Thorsten Froehlich" <tho### [at] trfde> wrote:
> Looks interesting. The idea of using a simple C/C++ like language with more
> abstract data types and then translate to plain C/C++ is really powerful.
There will be two separate languages, at least at first...SimC will
support all C features (structs, pointers, and other C data types, C
function syntax, etc), while CSDL will have a more simplified syntax
(references instead of pointers, no structs, etc...the expression
handling will be far simpler, at least at first). SimC will be basically
C + odd flavor of OOP + geometric vector type.
I've heard something described as "prototype-based OOP" that sounds
similar to what I'm doing...does anyone have any information about it?
I've started to build a library, and it seems to be a very simple and
powerful way to work...
> Using your idea together with "full" function support in POV-Ray 4.0 * might
> i.e. allow to develop POV-Ray source code (like new objects) in POV-Ray
> itself and then just run it through a C/C++ converter to generate fast code
> after everything has been debugged. This could speed up the development
> cycle and the rewrite in general...
Now that is an interesting idea...I had originally started this project
to try out some ideas I had for the POV 4.0 language, mainly the OOP
ideas. I haven't even started the translator project yet...
BTW, know of any good sites with information on VM/compiler design?
> * Just mentioning it, I don't want to get into any discussion about 4.0!
Ok. ;-)
--
--
Christopher James Huff <chr### [at] maccom>
Post a reply to this message
|
|
| |
| |
|
|
From: Tony[B]
Subject: Re: CSDL: C-like Simulation Description Language
Date: 12 Jan 2002 13:43:37
Message: <3c4083d9@news.povray.org>
|
|
|
| |
| |
|
|
> ...This could speed up the development
> cycle and the rewrite in general...
I like the sound of this. :)
Post a reply to this message
|
|
| |
| |
|
|
From: Thorsten Froehlich
Subject: Re: CSDL: C-like Simulation Description Language
Date: 12 Jan 2002 14:09:34
Message: <3c4089ee@news.povray.org>
|
|
|
| |
| |
|
|
In article <chr### [at] netplexaussieorg> ,
Christopher James Huff <chr### [at] maccom> wrote:
> BTW, know of any good sites with information on VM/compiler design?
The best intro book I have to compiler design was written in German, see
<http://www.cs.inf.ethz.ch/~wirth/books/Compilerbau1/>.
However, <http://www.cs.inf.ethz.ch/~wirth/books/CompilerConstruction/> is
the English edition of the same book. I checked, and Barnes and Noble asks
it for $52 new, which I have to say is absolutely unreasonable, the German
edition did only cost 40 DM, which is about $20. You can probably get it
used for much less as Amazon says it is out of print.
The nice thing about this book compared to some other books I have is that
rather than showing off the author is very straight to the point. In many
other books I have found complicated and unreadable notation to scare people
and show what complex language theory examples the authors can imagine, yet
all those have zero practical use. In particular I should warn you not to
get "Modern Compiler Implementation in XXX", where XX is C/C++/Pascal/Java.
They simply edited the example sin the book with tons of errors for each
different target language, and the book does not cover a compiler to a
useful language.
This is different in Wirth's book, which uses a subset of the language
Oberon, a successor to Pascal. All examples are extremely easy to read and
understand. Even more important, it is very show, less than 200 pages while
it covers absolutely everything you need to know without getting
side-tracked. Don't get me wrong, you neither need to know or be interested
in Oberon, it only delivers a IMO very effective means to communicate the
general ideas of compiler design.
For his development _of_ Pascal and Modula Wirth received the ACM Turing
Award in 1984, so there is no doubt he is qualified to write about compilers
either.
Once you have read it and gained some experience, I would strongly recommend
to get a copy of Muchnick's "Advanced Compiler Design and Implementation"
book. It covers all important optimization and intermediate representation
techniques developed in the past two decades. Unfortunately it is $90, but
well worth it for the 850 packed pages. Contrary to Wirth's book, it does
not go into implementation details but presents the different techniques in
a mostly independent fashion.
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christopher James Huff wrote:
> I've uploaded the current documentation for my CSDL project at:
> http://homepage.mac.com/chrishuff/csdl.html
>
> As for the interpreter, I'll probably just rewrite it, using what I
> learned the first time to make the new one better. The core will be
> written in platform-independant C++, and the OS X version will have a
> Cocoa GUI interface.
> Any comments/suggestions?
>
Your syntax supports only vectors, but if you are going to support
transformations, then perhaps it would be better to distinguish points,
vectors and normals (as they transform differently)? RenderMan SL
supported in initial versions only points and point transformation
function and this caused quite a lot of problems. Now it has 3 different
data types and separate transformation functions for each one.
If your language will allow 'overridden' functions, then perhaps it
could get away with 1 function (if there is possibility to recognize,
which type was given as actual parameter), but better would be to use 3
different functions, as it improves readability and allows to avoid or
catch errors (IMO).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3C4### [at] comtradeee>,
Vahur Krouverk <vkr### [at] comtradeee> wrote:
> Your syntax supports only vectors,
Scalars and vectors, actually. Though currently the expression engine
uses the 3D vector code for both.
> but if you are going to support transformations, then perhaps it
> would be better to distinguish points, vectors and normals (as they
> transform differently)?
Only the math is different. The library will eventually include
functions for point and normal manipulation, as well as transformation
objects.
> If your language will allow 'overridden' functions,
I think you mean "overloaded" functions...this is something I've been
thinking of, but it isn't implemented (yet). Of course, parameters
aren't fully implemented yet either...
> then perhaps it could get away with 1 function (if there is
> possibility to recognize, which type was given as actual parameter),
> but better would be to use 3 different functions, as it improves
> readability and allows to avoid or catch errors (IMO).
There will be separate transformation functions for points, vectors, and
normals.
--
--
Christopher James Huff <chr### [at] maccom>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I've gotten a rudimentary expression parser, variables, functions, and
the user output stream working. Objects can be declared, but I haven't
written the code for deriving objects from others or for accessing
members, so they aren't very useful yet.
It's not much, but it is enough for a "Hello World" program:
scalar accum = 5;
function run()
{
string Message = "Hello World!\n";
swrite(userout, Message, "pi = ", pi, newln);
swrite(userout, "Calling aFunc():", newln);
aFunc();
swrite(userout, "aFunc() returned.", newln);
};
function aFunc()
{
scalar Count = 5;
swrite(userout, "Inside aFunc():\n");
while(Count)
{
swrite(userout, "while: ", Count, newln);
swrite(userout, "accum = ", accum, newln);
Count = Count - 1;
accum = accum + 1;
};
};
--
--
Christopher James Huff <chr### [at] maccom>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
BTW, does anyone have any recommendations for licensing?
--
--
Christopher James Huff <chr### [at] maccom>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christopher James Huff wrote:
>
> BTW, does anyone have any recommendations for licensing?
<URL:http://www.perl.com/pub/a/language/misc/Artistic.html> is, as
usual, my suggestion.
Deaken
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|