datadraw-user — Discussion/Help for DataDraw

[Datadraw-user] recent news about datadraw and 42

[Henrique P. <hen...@he...>]

Hello everybody!

I found about DataDraw recently and I think it's awesome!  I was wondering
how active this project still is... I noticed there isn't much posts at this
mailing list recently... there's even a message from the author Bill Cox
from almost 3 years ago where he mentioned about a new programming language
called "42" and I was also curious about that too.

Any news about Bill's latest projects?


Regards, Henrique.

Re: [Datadraw-user] A list of cool algorithms

[Richard P. <rdp...@gm...>]

He changed email.  I am sure he will contact you shortly.

Have a nice one.

On Thu, Jul 8, 2010 at 4:08 AM, Questor Fused <qu...@fu...> wrote:

> cool list of algorithms :)  I have to search wikipedia about some of
> them...btw, is bill still around? his email doesn't work anymore; I've tried
> to convert the buildsystem of datadraw to cmake, but got some errors.happy
> codingkai
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Datadraw-user mailing list
> Dat...@li...
> https://lists.sourceforge.net/lists/listinfo/datadraw-user
>
>

Re: [Datadraw-user] A list of cool algorithms

[Questor F. <qu...@fu...>]

cool list of algorithms :)  I have to search wikipedia about some of them...btw, is bill still around? his email doesn't work anymore; I've tried to convert the buildsystem of datadraw to cmake, but got some errors.happy codingkai

[Datadraw-user] A list of cool algorithms

[Richard P. <rdp...@gm...>]

Hello guys,

Some datadraw users are (I think) algorithm junkies.  So if it is your case,
check this list to see if something is missing in your culture.

http://www.risc.jku.at/people/ckoutsch/stuff/e_algorithms.html

Enjoy!

Richard Prescott

[Datadraw-user] utAssert

[Richard P. <rdp...@gm...>]

Hello everyone,

I have an issue with utAssert.  Easy to fix technically but there is
possible code break depending on solution chosen.

I was expecting utAssert to be inactive when DD_DEBUG is not set. Actually
it is not the case.  This behavior is contrary of what assert() is doing in
regard of NDEBUG.  I guess the *right* thing to do is disable utAssert when
DD_DEBUG is off.  You will find in my code a lot of:

if(utUnlikely(whatever && wrong && condition)) {
   utAssert(!"this should not happen but I won't crash");
   getBackOnMyFeet();
}

Although, some of you may prefer to keep utAssert active even when DD_DEBUG
is off.  If this is the case, we can, given a #define:
opt-in to utAssert by default, (which would be compatible with current
behavior) or
opt-out to utAssert by default.

What are your preferences? concerns? ideas?

Regards

Richard

plus-one five-one-four five-one-eight eight-one-seven-two

Re: [Datadraw-user] svn broken

[Richard P. <rdp...@gm...>]

sorry, my fault.  Bill already corrected it.  Thanks.


On Thu, Jan 22, 2009 at 4:09 PM, wang liang <fab...@gm...> wrote:

> salut~
>
> il faudrait ajouter 2 virgules.
>
> Cdt
> Liang
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> Datadraw-user mailing list
> Dat...@li...
> https://lists.sourceforge.net/lists/listinfo/datadraw-user
>
>

[Datadraw-user] svn broken

[wang l. <fab...@gm...>]

salut~

il faudrait ajouter 2 virgules.

Cdt
Liang

Re: [Datadraw-user] 42 makes me improve datadraw

[Richard P. <rdp...@gm...>]

I've commited my changes.

A diff of my .dd files using the previous and the actual version of datadraw
shows no changes.  So I assume that I am backward compatible at least.

Best Regards.

Richard

On Sat, Jan 17, 2009 at 5:26 PM, Richard Prescott <rdp...@gm...>wrote:

> Hello guys,
>
> I have implemented two features for datadraw.  One of it is "view".  I.e.
> calculated properties where the code is provided by the user and later
> usable as key for hashes, ordered_lists, and heaps.  It can also be used for
> documentation purpose as the first thing I tend to read in a datadraw
> projects is the .dd and then (sometimes) the .h.
>
> The second feature is chained key for the same types of relationships
> (hashes, ordered_lists, and heaps).  I face that for the first time when
> confronting a many to many relationship where searching for the other were
> using a derived key.  Yes, this could have been implemented with "view" but
> this solution is sexier I think.
>
> I am ready to commit.  Although, I haven't done extensive tests.  So i
> don't want to break installations using latest subversion version and also I
> didn't discuss those two features with anybody.  So maybe they are
> inappropriate? Let discuss....
>
> Code is like picture, it worth a thousand words.  So in attchmnt, an
> example of it that compiles and run.
>
> Best Regards
>
> Richard
>
>
>

Re: [Datadraw-user] Datadraw-user Digest, Vol 10, Issue 2

[Richard P. <rdp...@gm...>]

Thanks for your enthusiasm!

I lived in Sophia-Antipolis for a year back in 2001.  I have also good
souvenirs of Aix en Provence.  Le français est ma langue maternelle.  I live
in Montréal.  You are also welcome here if you ever have a chance!

Cheers!

Richard


On Sat, Jan 17, 2009 at 8:01 PM, wang liang <fab...@gm...> wrote:

> Hi, Richard
> thank you for your response.
>
> YOU are definitely right, My dvscan.c is just empty!. I delete the file
> dvscan.c and the compilation pass!
> i think the problem come from my processes of compilation. When i did it at
> first time, i had not the flex/yacc installed
> on my ubuntu 7.04(andlinux <http://www.andlinux.org/>), i completed
> my packages flex,bison,byacc when the compile errors came out, once all
> installed
> i redo ./autogen.sh ./configure make make install, but it does not change
> the dvscan.c(don't know why, i will check ).
>
> i owe you a beer, richard. you are welcome in aix en provence, France :)
> Keep coding, with obama, datadraw and 42, you can change the world..
>
> Best Regards
> Liang Wang
>
>
>

Re: [Datadraw-user] Datadraw-user Digest, Vol 10, Issue 2

[wang l. <fab...@gm...>]

Hi, Richard
thank you for your response.

YOU are definitely right, My dvscan.c is just empty!. I delete the file
dvscan.c and the compilation pass!
i think the problem come from my processes of compilation. When i did it at
first time, i had not the flex/yacc installed
on my ubuntu 7.04(andlinux <http://www.andlinux.org/>), i completed
my packages flex,bison,byacc when the compile errors came out, once all
installed
i redo ./autogen.sh ./configure make make install, but it does not change
the dvscan.c(don't know why, i will check ).

i owe you a beer, richard. you are welcome in aix en provence, France :)
Keep coding, with obama, datadraw and 42, you can change the world..

Best Regards
Liang Wang

2009/1/17 <dat...@li...>

> Send Datadraw-user mailing list submissions to
>        dat...@li...
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        https://lists.sourceforge.net/lists/listinfo/datadraw-user
> or, via email, send a message with subject or body 'help' to
>        dat...@li...
>
> You can reach the person managing the list at
>        dat...@li...
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Datadraw-user digest..."
>
>
> Today's Topics:
>
>   1. [datadraw] probleme of compile (wang liang)
>   2. Re: [datadraw] probleme of compile (Richard Prescott)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 16 Jan 2009 23:04:10 +0100
> From: wang liang <fab...@gm...>
> Subject: [Datadraw-user] [datadraw] probleme of compile
> To: dat...@li...
> Message-ID:
>        <f5a...@ma...>
> Content-Type: text/plain; charset="iso-8859-1"
>
> hi, geeks
> i have a problem when i compile the source from svn
>
> gcc  -g -O2 -Wall -W -Wno-unused-parameter -Wno-unused-function   -o
> datadraw  dvadmin.o dvbuild.o dvdatabase.o dvgenc.o dvgenh.o dvgenerate.o
> dvlexwrap.o dvmain.o dvparse.o dvread.o dvscan.o dvutil.o
> ../util/libddutil-dbg.a
> dvlexwrap.o: In function `dvlex':
> /root/ed/datadraw/src/dvlexwrap.c:36: undefined reference to `dvlexlex'
> dvparse.o: In function `dverror':
> /root/ed/datadraw/src/dvparse.y:49: undefined reference to `dvlextext'
> dvread.o: In function `dvReadFile':
> /root/ed/datadraw/src/dvread.c:268: undefined reference to
> `dvLastWasReturn'
> /root/ed/datadraw/src/dvread.c:269: undefined reference to `dvEnding'
>
> the compiler can't find these extern functions and variables,  my output of
> configure
>
> checking for a BSD-compatible install... /usr/bin/install -c
> checking whether build environment is sane... yes
> checking for gawk... gawk
> checking whether make sets $(MAKE)... yes
> checking whether to enable maintainer-specific portions of Makefiles... no
> checking for gcc... gcc
> checking for C compiler default output file name... a.out
> checking whether the C compiler works... yes
> checking whether we are cross compiling... no
> checking for suffix of executables...
> checking for suffix of object files... o
> checking whether we are using the GNU C compiler... yes
> checking whether gcc accepts -g... yes
> checking for gcc option to accept ISO C89... none needed
> checking for style of include used by make... GNU
> checking dependency style of gcc... gcc3
> checking for ranlib... ranlib
> checking for a BSD-compatible install... /usr/bin/install -c
> checking for flex... flex
> checking lex output file root... lex.yy
> checking lex library... -lfl
> checking whether yytext is a pointer... yes
> checking for bison... bison -y
> checking If the compiler accepts -Wall... yes
> checking If the compiler accepts -W... yes
> checking If the compiler accepts -Wno-unused-parameter... yes
> checking If the compiler accepts -Wno-unused-function... yes
>
> ** Configuration summary for datadraw 3.1.X-unstable:
>
>   CPPFLAGS:
>   CFLAGS:       -g -O2 -Wall -W -Wno-unused-parameter -Wno-unused-function
>   LIBS:
>
> do i miss some packages of lex/yacc?
>
> thanks
> -------------- next part --------------
> An HTML attachment was scrubbed...
>
> ------------------------------
>
> Message: 2
> Date: Fri, 16 Jan 2009 21:16:55 -0500
> From: "Richard Prescott" <rdp...@gm...>
> Subject: Re: [Datadraw-user] [datadraw] probleme of compile
> To: dat...@li...
> Message-ID:
>        <352...@ma...>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi Wang,
>
> All problematic symbols are from dvscan.o. Have you tried "rm dvscan.c
> dvscan.o; make" ?  That should do it.
>
> If the problem persist:
>
> dvlexlex shall be defined in dvscan.c generated by dvscan.l and flex.
>
> as I read your message, the following test shall differ from my execution,
> isn't it?
>
> [rip@localhost src]$ nm dvscan.o | grep -w dvlexlex
> 00000000000006fb T dvlexlex
> [rip@localhost src]$ grep -w dvlexlex dvscan.c
> #define yylex dvlexlex
> extern int dvlexlex (void);
> #define YY_DECL int dvlexlex (void)
> ...
> [rip@localhost src]$ grep -w dvlex dvscan.l
> %option prefix="dvlex"
> [rip@localhost src]$ flex --version
> flex 2.5.33
>
> What is your mileage?
>
> I tried to find on the web starting at which flex version, %option prefix
> has been introduced (it has been a while for sure) but without any success.
> On the main page of flex, flex 2.5.33 happen to be the oldest non obsoleted
> version.
>
>
> Best Regards
>
> Richard Prescott
>
>
> On Fri, Jan 16, 2009 at 5:04 PM, wang liang <fab...@gm...> wrote:
>
> > hi, geeks
> > i have a problem when i compile the source from svn
> >
> > gcc  -g -O2 -Wall -W -Wno-unused-parameter -Wno-unused-function   -o
> > datadraw  dvadmin.o dvbuild.o dvdatabase.o dvgenc.o dvgenh.o dvgenerate.o
> > dvlexwrap.o dvmain.o dvparse.o dvread.o dvscan.o dvutil.o
> > ../util/libddutil-dbg.a
> > dvlexwrap.o: In function `dvlex':
> > /root/ed/datadraw/src/dvlexwrap.c:36: undefined reference to `dvlexlex'
> > dvparse.o: In function `dverror':
> > /root/ed/datadraw/src/dvparse.y:49: undefined reference to `dvlextext'
> > dvread.o: In function `dvReadFile':
> > /root/ed/datadraw/src/dvread.c:268: undefined reference to
> > `dvLastWasReturn'
> > /root/ed/datadraw/src/dvread.c:269: undefined reference to `dvEnding'
> >
> > the compiler can't find these extern functions and variables,  my output
> of
> > configure
> >
> > checking for a BSD-compatible install... /usr/bin/install -c
> > checking whether build environment is sane... yes
> > checking for gawk... gawk
> > checking whether make sets $(MAKE)... yes
> > checking whether to enable maintainer-specific portions of Makefiles...
> no
> > checking for gcc... gcc
> > checking for C compiler default output file name... a.out
> > checking whether the C compiler works... yes
> > checking whether we are cross compiling... no
> > checking for suffix of executables...
> > checking for suffix of object files... o
> > checking whether we are using the GNU C compiler... yes
> > checking whether gcc accepts -g... yes
> > checking for gcc option to accept ISO C89... none needed
> > checking for style of include used by make... GNU
> > checking dependency style of gcc... gcc3
> > checking for ranlib... ranlib
> > checking for a BSD-compatible install... /usr/bin/install -c
> > checking for flex... flex
> > checking lex output file root... lex.yy
> > checking lex library... -lfl
> > checking whether yytext is a pointer... yes
> > checking for bison... bison -y
> > checking If the compiler accepts -Wall... yes
> > checking If the compiler accepts -W... yes
> > checking If the compiler accepts -Wno-unused-parameter... yes
> > checking If the compiler accepts -Wno-unused-function... yes
> >
> > ** Configuration summary for datadraw 3.1.X-unstable:
> >
> >    CPPFLAGS:
> >    CFLAGS:       -g -O2 -Wall -W -Wno-unused-parameter
> -Wno-unused-function
> >    LIBS:
> >
> > do i miss some packages of lex/yacc?
> >
> > thanks
> >
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > This SF.net email is sponsored by:
> > SourcForge Community
> > SourceForge wants to tell your story.
> > http://p.sf.net/sfu/sf-spreadtheword
> > _______________________________________________
> > Datadraw-user mailing list
> > Dat...@li...
> > https://lists.sourceforge.net/lists/listinfo/datadraw-user
> >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
>
> ------------------------------
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
>
> ------------------------------
>
> _______________________________________________
> Datadraw-user mailing list
> Dat...@li...
> https://lists.sourceforge.net/lists/listinfo/datadraw-user
>
>
> End of Datadraw-user Digest, Vol 10, Issue 2
> ********************************************
>

[Datadraw-user] 42 makes me improve datadraw

[Richard P. <rdp...@gm...>]

Index: src/dvgenc.c
===================================================================
--- src/dvgenc.c	(revision 542)
+++ src/dvgenc.c	(working copy)
@@ -17,62 +18,53 @@
     dvKey key,
     bool useParamName)
 {
-    dvProperty property = dvKeyGetProperty(key);
+    dvProperty property = dvKeypropertyGetProperty(dvKeyGetLastKeyproperty(key));
     dvClass childClass = dvPropertyGetClass(property);
     dvClass pointerClass;
     dvPropertyType type = dvPropertyGetType(property);
-    char *accessMacro, *lengthMacro;
+    char *param = utSprintf("_%s",
+        dvClassGetName(dvPropertyGetClass(dvKeypropertyGetProperty(dvKeyGetFirstKeyproperty(key)))));
 
-    if(useParamName) {
-        accessMacro = dvPropertyGetName(property);
-        if(!dvPropertyFixedSize(property)) {
-            lengthMacro = utSprintf("%sLength", accessMacro);
-        } else {
-            lengthMacro = utSprintf("(%s)", dvPropertyGetIndex(property));
-        }
-    } else {
-        if(!dvPropertyArray(property) && (type == PROP_BOOL || type == PROP_BIT)) {
-            accessMacro = utSprintf("%s%s%s(_%s)", dvPrefix, dvClassGetName(childClass),
-                dvPropertyGetName(property), dvClassGetName(childClass));
-        } else {
-            accessMacro = utSprintf("%s%sGet%s(_%s)", dvPrefix, dvClassGetName(childClass),
-                dvPropertyGetName(property), dvClassGetName(childClass));
-        }
-        if(!dvPropertyFixedSize(property)) {
-            lengthMacro = utSprintf("%s%sGetNum%s(_%s)", dvPrefix, dvClassGetName(childClass),
-                dvPropertyGetName(property), dvClassGetName(childClass));
-        } else {
-            lengthMacro = utSprintf("(%s)", dvPropertyGetIndex(property));
-        }
-    }
     if(dvPropertyArray(property)) {
-        dvWrtemp(dvFile, "utHashData(%0, sizeof(%1)*%2)", accessMacro, dvPropertyGetTypeName(property), lengthMacro);
+        dvWrtemp(dvFile, "utHashData(%0, sizeof(%1)*%2)",
+            dvKeyGetAccessMacro(key, useParamName, param),
+            dvPropertyGetTypeName(property),
+            dvKeyGetLengthMacro(key, useParamName, param));
         return;
     }
     switch(type) {
     case PROP_UINT: case PROP_INT: case PROP_CHAR: case PROP_ENUM: case PROP_BOOL: case PROP_BIT:
-        dvWrtemp(dvFile, "(uint32)%0", accessMacro);
+        dvWrtemp(dvFile, "(uint32)%0", dvKeyGetAccessMacro(key, useParamName, param));
         break;
     case PROP_FLOAT:
-        dvWrtemp(dvFile, "utHashFloat(%0)", accessMacro);
+        dvWrtemp(dvFile, "utHashFloat(%0)", dvKeyGetAccessMacro(key, useParamName, param));
         break;
     case PROP_DOUBLE:
-        dvWrtemp(dvFile, "utHashDouble(%0)", accessMacro);
+        dvWrtemp(dvFile, "utHashDouble(%0)", dvKeyGetAccessMacro(key, useParamName, param));
         break;
     case PROP_SYM:
-        dvWrtemp(dvFile, "utSymGetHashValue(%0)", accessMacro);
+        dvWrtemp(dvFile, "utSymGetHashValue(%0)", dvKeyGetAccessMacro(key, useParamName, param));
         break;
     case PROP_TYPEDEF:
         if(useParamName) {
-            dvWrtemp(dvFile, "utHashData(&%0, sizeof(%1))", accessMacro, dvPropertyGetTypeName(property));
+            dvWrtemp(dvFile, "utHashData(&%0, sizeof(%1))",
+                dvKeyGetAccessMacro(key, useParamName, param),
+                dvPropertyGetTypeName(property));
         } else {
-            dvWrtemp(dvFile, "utHashData(%0%1s.%2 + %4%12Index(_%1), sizeof(%3))", dvPrefix, dvClassGetName(childClass), 
-                dvPropertyGetName(property), dvPropertyGetTypeName(property), dvClassGetPrefix(childClass));
+            dvWrtemp(dvFile, "utHashData(%0%1s.%2 + %4%12Index(_%1), sizeof(%3))",
+                dvPrefix,
+                dvClassGetName(childClass), 
+                dvPropertyGetName(property),
+                dvPropertyGetTypeName(property),
+                dvClassGetPrefix(childClass));
         }
         break;
     case PROP_POINTER:
         pointerClass = dvPropertyGetClassProp(property);
-        dvWrtemp(dvFile, "%1%22Index(%0)", accessMacro, dvClassGetPrefix(pointerClass), dvClassGetName(pointerClass));
+        dvWrtemp(dvFile, "%1%22Index(%0)",
+            dvKeyGetAccessMacro(key, useParamName, param),
+            dvClassGetPrefix(pointerClass),
+            dvClassGetName(pointerClass));
         break;
     default:
         utExit("Unexpected key type");
@@ -252,7 +244,7 @@
     dvKey key;
 
     dvForeachRelationshipKey(relationship, key) {
-        property = dvKeyGetProperty(key);
+        property = dvKeypropertyGetProperty(dvKeyGetLastKeyproperty(key));
         if(!dvPropertyArray(property)) {
             dvWrtemp(dvFile, ",\n    %0 %1", dvPropertyGetTypeName(property), dvPropertyGetName(property));
         } else if(!dvPropertyFixedSize(property)) {
@@ -271,29 +263,33 @@
     dvRelationship relationship)
 {
     dvClass childClass = dvRelationshipGetChildClass(relationship);
+    dvKeyproperty keyproperty;
     dvProperty property;
-    dvPropertyType type;
     dvKey key;
     bool isFirst = true;
-    char *getString;
 
     dvForeachRelationshipKey(relationship, key) {
         if(!isFirst) {
             dvWrtemp(dvFile, " && ");
         }
         isFirst = false;
-        property = dvKeyGetProperty(key);
-        type = dvPropertyGetType(property);
+        keyproperty = dvKeyGetLastKeyproperty(key);
+        property = dvKeypropertyGetProperty(keyproperty);
         if(!dvPropertyArray(property)) {
-            getString = type == PROP_BIT || type == PROP_BOOL?  "" : "Get";
-            dvWrtemp(dvFile, "%0%1%3%2(_%1) == %2",
-                dvPrefix, dvClassGetName(childClass), dvPropertyGetName(property), getString);
+            dvWrtemp(dvFile, "%0 == %1",
+                dvKeyGetAccessMacro(key,false,utSprintf("_%s", dvClassGetName(childClass))),
+                dvPropertyGetName(property));
         } else if(!dvPropertyFixedSize(property)) {
-            dvWrtemp(dvFile, "%0%1GetNum%2(_%1) == %2Length && !memcmp(%0%1Get%2(_%1), %2, sizeof(%3)*%2Length)",
-                dvPrefix, dvClassGetName(childClass), dvPropertyGetName(property), dvPropertyGetTypeName(property));
+            dvWrtemp(dvFile, "%0 == %2Length && !memcmp(%1, %2, sizeof(%3)*%2Length)",
+                dvKeyGetLengthMacro(key, false, utSprintf("_%s", dvClassGetName(childClass))),
+                dvKeyGetAccessMacro(key, false, utSprintf("_%s", dvClassGetName(childClass))),
+                dvPropertyGetName(property),
+                dvPropertyGetTypeName(property));
         } else {
-            dvWrtemp(dvFile, "!memcmp(%0%1Get%2(_%1), %2, sizeof(%3)*(%4))",
-                dvPrefix, dvClassGetName(childClass), dvPropertyGetName(property), dvPropertyGetTypeName(property),
+            dvWrtemp(dvFile, "!memcmp(%0, %1, sizeof(%2)*(%3))",
+                dvKeyGetAccessMacro(key, false, utSprintf("_%s", dvClassGetName(childClass))),
+                dvPropertyGetName(property),
+                dvPropertyGetTypeName(property),
                 dvPropertyGetIndex(property));
         }
     } dvEndRelationshipKey;
@@ -929,6 +925,12 @@
     char *propName = dvPropertyGetName(prop);
     char *fieldName;
 
+    if(dvPropertyView(prop)) {
+        dvWrtemp(dvFile, "%1    /* property initialisation for %0 is user provided */\n",
+            propName, indent);
+        return;
+    }
+
     if(strcmp(initValue, "0") || cache != dvCacheNull) {
         if(theUnion != dvUnionNull) {
             fieldName = utSprintf("%s[x%s].%s", dvUnionGetFieldName(theUnion), name, propName);
@@ -968,7 +970,11 @@
     dvForeachClassProperty(theClass, prop) {
         if(dvPropertyGetUnion(prop) == dvUnionNull && dvPropertyGetCache(prop) == dvCacheNull &&
                 !dvPropertySparse(prop)) {
-            if(!dvPropertyArray(prop)) {
+            if(dvPropertyView(prop)) {
+                dvWrtemp(dvFile, "    /* allocation for %0 is user provided */\n",
+                    dvPropertyGetName(prop));
+            }
+            else if(!dvPropertyArray(prop)) {
                 dvWrtemp(dvFile, 
                     "    %0%1s.%2 = utNewA(%4, (%3Allocated%1()%5);\n",
                     dvPrefix, name, dvPropertyGetName(prop), dvClassGetPrefix(theClass),
@@ -1033,7 +1039,11 @@
     char *shift, *multiplier;
 
     dvForeachClassProperty(theClass, prop) {
-        if((!dvPropertyArray(prop) || dvPropertyFixedSize(prop)) && dvPropertyGetUnion(prop) == dvUnionNull &&
+        if(dvPropertyView(prop)) {
+            dvWrtemp(dvFile, "    /* reallocation for %0 is user provided */\n",
+                dvPropertyGetName(prop));
+        }
+        else if((!dvPropertyArray(prop) || dvPropertyFixedSize(prop)) && dvPropertyGetUnion(prop) == dvUnionNull &&
                 dvPropertyGetCache(prop) == dvCacheNull && !dvPropertySparse(prop)) {
             shift = dvPropertyGetType(prop) == PROP_BIT? " + 7) >> 3" : ")";
             multiplier = dvPropertyFixedSize(prop)? utSprintf("*(%s)", dvPropertyGetIndex(prop)) : "";
@@ -1094,7 +1104,11 @@
     char *name = dvClassGetName(theClass);
 
     dvForeachClassProperty(theClass, prop) {
-        if(dvPropertyGetUnion(prop) == dvUnionNull && dvPropertyGetCache(prop) == dvCacheNull &&
+        if(dvPropertyView(prop)) {
+            dvWrtemp(dvFile, "    /* free for %0 is user provided */\n",
+                dvPropertyGetName(prop));
+        }
+        else if(dvPropertyGetUnion(prop) == dvUnionNull && dvPropertyGetCache(prop) == dvCacheNull &&
                 !dvPropertySparse(prop)) {
             dvWrtemp(dvFile, 
                 "    utFree(%0%1s.%2);\n",
@@ -1273,7 +1287,13 @@
                 dvModuleGetPrefix(dvClassGetModule(baseClass)), utSprintf("%u", dvClassGetNumber(baseClass)));
         }
         dvForeachClassProperty(theClass, property) {
-            if(dvPropertyGetUnion(property) == dvUnionNull && dvPropertyGetCache(property) == dvCacheNull &&
+            if(dvPropertyView(property)) {
+                dvWrtemp(dvFile,
+                    "    /* %0.%1 not managed by this database */\n",
+                    dvClassGetName(theClass),
+                    dvPropertyGetName(property));
+            }
+            else if(dvPropertyGetUnion(property) == dvUnionNull && dvPropertyGetCache(property) == dvCacheNull &&
                     !dvPropertySparse(property)) {
                 dvWrtemp(dvFile,
                     "    utRegisterField(\"%2\", &%0%1s.%2, sizeof(%3), %4,",
@@ -1439,6 +1459,12 @@
 {
     dvClass theClass = dvPropertyGetClass(property);
 
+    if(dvPropertyView(property)) {
+        dvWrtemp(dvFile, "/* compact function for %0 is user provided */\n",
+            dvPropertyGetName(property));
+        return;
+    }
+
     dvWrtemp(dvFile, 
         "/*----------------------------------------------------------------------------------------\n"
         "  Compact the %1.%2 heap to free memory.\n"
@@ -1497,6 +1523,12 @@
 {
     dvClass theClass = dvPropertyGetClass(property);
 
+    if(dvPropertyView(property)) {
+        dvWrtemp(dvFile, "/* compact and/or allocate more space function for %0 is user provided */\n",
+            dvPropertyGetName(property));
+        return;
+    }
+
     dvWrtemp(dvFile, 
         "/*----------------------------------------------------------------------------------------\n"
         "  Allocate more memory for the %1.%2 heap.\n"
@@ -1545,6 +1577,12 @@
 {
     dvClass theClass = dvPropertyGetClass(property);
 
+    if(dvPropertyView(property)) {
+        dvWrtemp(dvFile, "/* allocate more space function for %0 is user provided */\n",
+            dvPropertyGetName(property));
+        return;
+    }
+
     dvWrtemp(dvFile, 
         "/*----------------------------------------------------------------------------------------\n"
         "  Allocate memory for a new %1.%2 array.\n"
@@ -1663,6 +1701,12 @@
 {
     dvClass theClass = dvPropertyGetClass(property);
 
+    if(dvPropertyView(property)) {
+        dvWrtemp(dvFile, "/* free space function for %0 is user provided */\n",
+            dvPropertyGetName(property));
+        return;
+    }
+
     dvWrtemp(dvFile, 
         "/*----------------------------------------------------------------------------------------\n"
         "  Free memory used by the %1.%2 array.\n"
@@ -1712,6 +1756,12 @@
 {
     dvClass theClass = dvPropertyGetClass(property);
 
+    if(dvPropertyView(property)) {
+        dvWrtemp(dvFile, "/* reallocate space function for %0 is user provided */\n",
+            dvPropertyGetName(property));
+        return;
+    }
+
     dvWrtemp(dvFile, 
         "/*----------------------------------------------------------------------------------------\n"
         "  Resize the %1.%2 array.\n"
@@ -1998,31 +2048,33 @@
 static void writeOrderedListComparisons(
     dvRelationship relationship)
 {
-    dvClass child = dvRelationshipGetChildClass(relationship);
     dvProperty property;
     dvKey key;
-    dvPropertyType type;
-    char *getString, *compareString;
     bool firstTime = true;
+    char *compareString;
 
     dvForeachRelationshipKey(relationship, key) {
-        property = dvKeyGetProperty(key);
+        property = dvKeypropertyGetProperty(dvKeyGetLastKeyproperty(key));
         if(!dvPropertyArray(property)) {
-            type = dvPropertyGetType(property);
-            getString = type == PROP_BIT || type == PROP_BOOL?  "" : "Get";
-            compareString = dvSwrtemp("%2 - %0%1%3%2(node)",
-                dvPropertyGetPrefix(property), dvClassGetName(child), dvPropertyGetName(property), getString);
+            compareString = dvSwrtemp("%0 - %1",
+                dvPropertyGetName(property),
+                dvKeyGetAccessMacro(key, false, "node"));
             writeOrderedListComparison(compareString, firstTime);
         } else if(!dvPropertyFixedSize(property)) {
-            compareString = dvSwrtemp("%2Length - %0%1GetNum%2(node)",
-                dvPropertyGetPrefix(property), dvClassGetName(child), dvPropertyGetName(property), dvPropertyGetTypeName(property));
+            compareString = dvSwrtemp("%0Length - %1",
+                dvPropertyGetName(property),
+                dvKeyGetLengthMacro(key, false, "node"));
             writeOrderedListComparison(compareString, firstTime);
-            compareString = dvSwrtemp("memcmp(%0%1Get%2(node), %2, sizeof(%3)*%2Length)",
-                dvPropertyGetPrefix(property), dvClassGetName(child), dvPropertyGetName(property), dvPropertyGetTypeName(property));
+            compareString = dvSwrtemp("memcmp(%0, %1, sizeof(%2)*%1Length)",
+                dvKeyGetAccessMacro(key, false, "node"),
+                dvPropertyGetName(property),
+                dvPropertyGetTypeName(property));
             writeOrderedListComparison(compareString, false);
         } else {
-            compareString = dvSwrtemp("memcmp(%0%1Get%2(node), %2, sizeof(%3)*(%4))",
-                dvPropertyGetPrefix(property), dvClassGetName(child), dvPropertyGetName(property), dvPropertyGetTypeName(property),
+            compareString = dvSwrtemp("memcmp(%0, %1, sizeof(%2)*(%3))",
+                dvKeyGetAccessMacro(key, false, "node"),
+                dvPropertyGetName(property),
+                dvPropertyGetTypeName(property),
                 dvPropertyGetIndex(property));
             writeOrderedListComparison(compareString, firstTime);
         }
@@ -3072,7 +3124,11 @@
     dvForeachClassProperty(theClass, prop) {
         name = dvClassGetName(theClass);
         propName = dvPropertyGetName(prop);
-        if(propIsClassProp(prop)) {
+        if(dvPropertyView(prop)) {
+            dvWrtemp(dvFile, "    /* copy for %0 is irrelevant */\n",
+                dvPropertyGetName(prop));
+        }
+        else if(propIsClassProp(prop)) {
             theUnion = dvPropertyGetUnion(prop);
             propType = dvPropertyGetType(prop);
             if(theUnion == dvUnionNull && propType != PROP_POINTER) {
@@ -3095,7 +3151,7 @@
 {
     dvProperty prop;
     dvForeachClassProperty(theClass, prop) {
-        if(dvPropertyGetType(prop) == PROP_BIT) {
+        if(dvPropertyGetType(prop) == PROP_BIT && !dvPropertyView(prop)) {
             return true;
         }
     } dvEndClassProperty;
@@ -3131,7 +3187,7 @@
         "    uint32 bitfield = 0;\n"
         "    uint8 xLevel = 0;\n\n", dvPrefix, name, prefix);
     dvForeachClassProperty(theClass, prop) {
-        if(propIsClassProp(prop) && dvPropertyGetType(prop) == PROP_BIT) {
+        if(propIsClassProp(prop) && dvPropertyGetType(prop) == PROP_BIT && !dvPropertyView(prop)) {
             name = dvClassGetName(theClass);
             propName = dvPropertyGetName(prop);
             theUnion = dvPropertyGetUnion(prop);
@@ -3150,7 +3206,7 @@
         "     uint32 bitfield)\n"
         "{\n", dvPrefix, name, prefix);
     dvForeachClassProperty(theClass, prop) {
-        if(propIsClassProp(prop) && dvPropertyGetType(prop) == PROP_BIT) {
+        if(propIsClassProp(prop) && dvPropertyGetType(prop) == PROP_BIT && !dvPropertyView(prop)) {
             name = dvClassGetName(theClass);
             propName = dvPropertyGetName(prop);
             theUnion = dvPropertyGetUnion(prop);
@@ -3446,7 +3502,11 @@
     dvClass theClass = dvPropertyGetClass(property);
     dvPropertyType type = dvPropertyGetType(property);
     dvSparsegroup sparsegroup = dvPropertyGetSparsegroup(property);
-
+    if(dvPropertyView(property)) {
+    dvWrtemp(dvFile, "/* Getting and setting %0.%1 field is user provided */\n", 
+        dvClassGetName(theClass), dvPropertyGetName(property));
+        return;
+    }
     dvWrtemp(dvFile,
         "/*----------------------------------------------------------------------------------------\n"
         "  Get the %1.%2 field.\n"
Index: src/dvutil.c
===================================================================
--- src/dvutil.c	(revision 542)
+++ src/dvutil.c	(working copy)
@@ -545,11 +545,15 @@
 {
     dvProperty property;
     dvKey key = dvRelationshipGetFirstKey(relationship);
+    dvKeyproperty keyproperty = dvKeyGetFirstKeyproperty(key);
 
     if(dvKeyGetNextRelationshipKey(key) != dvKeyNull) {
         return false;
     }
-    property = dvKeyGetProperty(key);
+    if(dvKeypropertyGetNextKeyKeyproperty(keyproperty) != dvKeypropertyNull) {
+        return false;
+    }
+    property = dvKeypropertyGetProperty(key);
     if(strcmp(dvPropertyGetName(property), utSprintf("%sSym", dvRelationshipGetChildLabel(relationship)))) {
         return false;
     }
@@ -600,3 +604,105 @@
     } while(theClass != dvClassNull);
     return dvPropertyNull;
 }
+
+/*--------------------------------------------------------------------------------------------------
+  Format a access function for just this property.
+--------------------------------------------------------------------------------------------------*/
+char *dvPropertyGetAccessMacro(
+    dvProperty property,
+    bool useParamName,
+    char * param)
+{
+    dvClass childClass = dvPropertyGetClass(property);
+    dvPropertyType type = dvPropertyGetType(property);
+    char *accessMacro;
+    if(useParamName) {
+        accessMacro = dvPropertyGetName(property);
+    } else {
+        if(!dvPropertyArray(property) && (type == PROP_BOOL || type == PROP_BIT)) {
+            accessMacro = utSprintf("%s%s%s(%s)", dvPropertyGetPrefix(property), dvClassGetName(childClass),
+                dvPropertyGetName(property), param);
+        } else {
+            accessMacro = utSprintf("%s%sGet%s(%s)", dvPropertyGetPrefix(property), dvClassGetName(childClass),
+                dvPropertyGetName(property), param);
+        }
+    }
+    return accessMacro;
+}
+
+
+/*--------------------------------------------------------------------------------------------------
+  Format a length function for just this property.
+--------------------------------------------------------------------------------------------------*/
+char *dvPropertyGetLengthMacro(
+    dvProperty property,
+    bool useParamName,
+    char * param)
+{
+    dvClass childClass = dvPropertyGetClass(property);
+    char *lengthMacro;
+    if(useParamName) {
+        if(!dvPropertyFixedSize(property)) {
+            lengthMacro = utSprintf("%sLength", dvPropertyGetName(property));
+        } else {
+            lengthMacro = utSprintf("(%s)", dvPropertyGetIndex(property));
+        }
+    } else {
+        if(!dvPropertyFixedSize(property)) {
+            lengthMacro = utSprintf("%s%sGetNum%s(%s)", dvPropertyGetPrefix(property), dvClassGetName(childClass),
+                dvPropertyGetName(property), param);
+        } else {
+            lengthMacro = utSprintf("(%s)", dvPropertyGetIndex(property));
+        }
+    }
+    return lengthMacro;
+}
+
+/*--------------------------------------------------------------------------------------------------
+  Format a access function for just this key.
+--------------------------------------------------------------------------------------------------*/
+char *dvKeyGetAccessMacro(
+    dvKey key,
+    bool useParamName,
+    char * param)
+{
+    dvKeyproperty keyproperty = dvKeyGetLastKeyproperty(key);
+    dvProperty property = dvKeypropertyGetProperty(keyproperty);
+
+    char *accessMacro = param;
+
+    dvForeachKeyKeyproperty(key, keyproperty) {
+        property = dvKeypropertyGetProperty(keyproperty);
+        accessMacro = dvPropertyGetAccessMacro(property, useParamName, accessMacro);
+    } dvEndKeyKeyproperty;
+    
+    return accessMacro;
+}
+
+/*--------------------------------------------------------------------------------------------------
+  Format a length function for just this key.
+--------------------------------------------------------------------------------------------------*/
+char *dvKeyGetLengthMacro(
+    dvKey key,
+    bool useParamName,
+    char *param)
+{
+    dvKeyproperty keyproperty = dvKeyGetLastKeyproperty(key);
+    dvProperty property = dvKeypropertyGetProperty(keyproperty);
+
+    char *lengthMacro = param;
+
+    dvForeachKeyKeyproperty(key, keyproperty) {
+        property = dvKeypropertyGetProperty(keyproperty);
+        if(dvKeypropertyGetNextKeyKeyproperty(keyproperty) != dvKeypropertyNull) {
+            lengthMacro = dvPropertyGetAccessMacro(property, useParamName, lengthMacro);
+        }
+        else {
+            lengthMacro = dvPropertyGetLengthMacro(property, useParamName, lengthMacro);
+        }
+    } dvEndKeyKeyproperty;
+
+    return lengthMacro;
+}
+
+
Index: src/Database.dd
===================================================================
--- src/Database.dd	(revision 542)
+++ src/Database.dd	(working copy)
@@ -75,6 +75,7 @@
     bit Array
     bit Cascade
     bit Sparse
+    bit View
     bit expanded // So that we only generate relationship fields once
     uint32 fieldNumber // Used in persistent databases
     Property firstElementProp // Used only for arrays
@@ -107,9 +108,11 @@
     bit Unordered
 
 class Key
-    sym PropertySym // For unbound keys
     uint32 lineNum // For reporting errors during binding
 
+class Keyproperty
+    sym PropertySym // For unbound keys
+
 class Union
     sym propertySym
     Property typeProperty
@@ -160,7 +163,8 @@
 relationship Entry Case tail_linked mandatory
 relationship Property Case tail_linked mandatory
 relationship Relationship Key tail_linked mandatory
-relationship Property Key tail_linked mandatory
+relationship Key Keyproperty tail_linked mandatory
+relationship Property Keyproperty tail_linked mandatory
 relationship Relationship Sparsegroup:Parent
 relationship Relationship Sparsegroup:Child
 
Index: src/dvgenh.c
===================================================================
--- src/dvgenh.c	(revision 542)
+++ src/dvgenh.c	(working copy)
@@ -78,7 +78,7 @@
     dvProperty prop;
 
     dvForeachClassProperty(theClass, prop) {
-        if(dvPropertyArray(prop) && !dvPropertyFixedSize(prop)) {
+        if(dvPropertyArray(prop) && !dvPropertyFixedSize(prop) && !dvPropertyView(prop)) {
             dvWrtemp(dvFile,
                 "    uint32 used%0%1, allocated%0%1, free%0%1;\n",
                 name, dvPropertyGetName(prop));
@@ -169,7 +169,7 @@
     char *preString, *postString;
 
     dvForeachClassProperty(theClass, prop) {
-        if(dvPropertyArray(prop) && !dvPropertyFixedSize(prop)) {
+        if(dvPropertyArray(prop) && !dvPropertyFixedSize(prop) && !dvPropertyView(prop)) {
             dvWrtemp(dvFile,
                 "static utInlineC uint32 %0Used%1%2(void) {return %0RootData.used%1%2;}\n"
                 "static utInlineC uint32 %0Allocated%1%2(void) {return %0RootData.allocated%1%2;}\n"
@@ -312,8 +312,10 @@
     dvProperty prop;
 
     dvForeachClassProperty(theClass, prop) {
-        if(!dvPropertySparse(prop) && dvPropertyGetUnion(prop) == dvUnionNull &&
-                dvPropertyGetCache(prop) == dvCacheNull) {
+        if(!dvPropertySparse(prop) &&
+            dvPropertyGetUnion(prop) == dvUnionNull &&
+            dvPropertyGetCache(prop) == dvCacheNull &&
+           !dvPropertyView(prop)) {
             dvWrtemp(dvFile, "    %0 *%1;\n", dvPropertyGetTypeName(prop), dvPropertyGetName(prop));
         }
     } dvEndClassProperty;
@@ -409,7 +411,7 @@
     dvProperty prop;
 
     dvForeachClassProperty(theClass, prop) {
-        if(dvPropertyArray(prop) && !dvPropertyFixedSize(prop)) {
+        if(dvPropertyArray(prop) && !dvPropertyFixedSize(prop) &&!dvPropertyView(prop)) {
             dvWrtemp(dvFile,
                 "void %0%1Alloc%2s(%3%1 %1, uint32 num%2s);\n"
                 "void %0%1Resize%2s(%3%1 %1, uint32 num%2s);\n"
@@ -443,9 +445,8 @@
     dvClass parent = dvRelationshipGetParentClass(relationship);
     dvClass child = dvRelationshipGetChildClass(relationship);
     dvKey key = dvRelationshipGetFirstKey(relationship);
-    dvProperty property = dvKeyGetProperty(key);
-    dvPropertyType type;
-    char *getString, *compareString;
+    dvProperty property = dvKeypropertyGetProperty(dvKeyGetLastKeyproperty(key));
+    char *compareString;
     uint32 numKeys = 0;
 
     dvWrtemp(dvFile,
@@ -453,25 +454,29 @@
         dvPrefix, dvClassGetName(parent), dvRelationshipGetChildLabel(relationship), 
              dvClassGetName(child), dvClassGetPrefix(parent), dvClassGetPrefix(child), 
              dvRelationshipGetParentLabel(relationship));
+
     dvForeachRelationshipKey(relationship, key) {
         numKeys++;
-        property = dvKeyGetProperty(key);
+        property = dvKeypropertyGetProperty(dvKeyGetLastKeyproperty(key));
         if(!dvPropertyArray(property)) {
-            type = dvPropertyGetType(property);
-            getString = type == PROP_BIT || type == PROP_BOOL?  "" : "Get";
-            compareString = dvSwrtemp("%0%1%3%2(right) - %0%1%3%2(left)",
-                dvPropertyGetPrefix(property), dvClassGetName(child), dvPropertyGetName(property), getString);
+            compareString = dvSwrtemp("%0 - %1",
+                dvKeyGetAccessMacro(key, false, "right"), dvKeyGetAccessMacro(key, false, "left"));
             writeComparison(compareString, dvKeyGetNextRelationshipKey(key) == dvKeyNull);
         } else if(!dvPropertyFixedSize(property)) {
-            compareString = dvSwrtemp("%0%1GetNum%2(right) - %0%1GetNum%2(left)",
-                dvPropertyGetPrefix(property), dvClassGetName(child), dvPropertyGetName(property), dvPropertyGetTypeName(property));
+            compareString = dvSwrtemp("%0 - %1",
+                dvKeyGetLengthMacro(key, false, "right"), dvKeyGetLengthMacro(key, false, "left"));
             writeComparison(compareString, false);
-            compareString = dvSwrtemp("memcmp(%0%1Get%2(left), %0%1Get%2(right), sizeof(%3)*%0%1GetNum%2(left))",
-                dvPropertyGetPrefix(property), dvClassGetName(child), dvPropertyGetName(property), dvPropertyGetTypeName(property));
+            compareString = dvSwrtemp("memcmp(%0, %1, sizeof(%2)*%3)",
+                dvKeyGetAccessMacro(key, false, "left"),
+                dvKeyGetAccessMacro(key, false, "right"),
+                dvPropertyGetTypeName(property),
+                dvKeyGetLengthMacro(key, false, "left"));
             writeComparison(compareString, dvKeyGetNextRelationshipKey(key) == dvKeyNull);
         } else {
-            compareString = dvSwrtemp("memcmp(%0%1Get%2(left), %0%1Get%2(right), sizeof(%3)*(%4))",
-                dvPropertyGetPrefix(property), dvClassGetName(child), dvPropertyGetName(property), dvPropertyGetTypeName(property),
+            compareString = dvSwrtemp("memcmp(%0, %1, sizeof(%2)*(%3))",
+                dvKeyGetAccessMacro(key, false, "left"),
+                dvKeyGetAccessMacro(key, false, "right"),
+                dvPropertyGetTypeName(property),
                 dvPropertyGetIndex(property));
             writeComparison(compareString, dvKeyGetNextRelationshipKey(key) == dvKeyNull);
         }
@@ -622,8 +627,34 @@
         } else {
             accessString = "Get";
         }
-        if(dvPropertyArray(prop) && !dvPropertyFixedSize(prop)) {
+        if(dvPropertyView(prop) && dvPropertyArray(prop) && !dvPropertyFixedSize(prop)) {
+            /* view on variable size array */
             dvWrtemp(dvFile,
+                "#ifndef %0%1Geti%2\n"
+                "extern %5 %0%1Geti%2(%4%1 %1, uint32 x);\n"
+                "#endif\n"
+                "#ifndef %0%1Get%2\n"
+                "extern %5 *%0%1Get%2(%4%1 %1);\n"
+                "#endif\n"
+                "#ifndef %0%1Get%2s\n"
+                "#define %0%1Get%2s %0%1Get%2\n"
+                "#endif\n",
+                dvPrefix, name, propName, dvClassGetReferenceTypeName(theClass),
+                dvClassGetPrefix(theClass), propTypeString);
+            dvWrtemp(dvFile,
+                "#ifndef %0%1Set%2\n"
+                "extern void %0%1Set%2(%6%1 %1, %3 *valuePtr, uint32 num%2);\n"
+                "#endif\n",
+                dvPrefix, name, propName, propTypeString, preString, postString, dvClassGetPrefix(theClass));
+            dvWrtemp(dvFile,
+                "#ifndef %0%1Seti%2\n"
+                "extern void %0%1Seti%2(%5%1 %1, uint32 x, %6 value);\n"
+                "#endif\n",
+                dvPrefix, name, propName, preString, postString, dvClassGetPrefix(theClass), propTypeString);
+        }
+        else if(dvPropertyArray(prop) && !dvPropertyFixedSize(prop)) {
+            /* variable size array */
+            dvWrtemp(dvFile,
                 "#if defined(DD_DEBUG)\n"
                 "static utInlineC uint32 %0%1Check%2Index(%4%1 %1, uint32 x) {utAssert(x < %0%1GetNum%2(%1)); return x;}\n"
                 "#else\n"
@@ -656,6 +687,31 @@
                     "static utInlineC void %0%1Seti%2(%5%1 %1, uint32 x, %6 value) {\n"
                     "%3    %0%1s.%2[%0%1Get%2Index(%1) + %0%1Check%2Index(%1, (x))] = value;%4}\n",
                 dvPrefix, name, propName, preString, postString, dvClassGetPrefix(theClass), propTypeString);
+        } else if(dvPropertyArray(prop) && dvPropertyView(prop)) {
+            /* view on fixed sized arrays */
+            dvWrtemp(dvFile,
+                "#ifndef %0%1Geti%2\n"
+                "extern %6 %0%1Geti%2(%5%1 %1, uint32 x);\n"
+                "#endif\n"
+                "#ifndef %0%1Get%2\n"
+                "extern %6 *%0%1Get%2(%5%1 %1);\n"
+                "#endif\n"
+                "#ifndef %0%1Get%2s\n"
+                "#define %0%1Get%2s %0%1Get%2\n"
+                "#endif\n",
+                dvPrefix, name, propName, dvClassGetReferenceTypeName(theClass), dvPropertyGetIndex(prop),
+                dvClassGetPrefix(theClass), propTypeString);
+            dvWrtemp(dvFile,
+                "#ifndef %0%1Set%2\n"
+                "extern void %0%1Set%2(%6%1 %1, %3 *valuePtr, uint32 num%2);\n"
+                "#endif\n",
+                dvPrefix, name, propName, propTypeString, preString, postString, dvClassGetPrefix(theClass));
+            dvWrtemp(dvFile,
+                "#ifndef %0%1Seti%2\n"
+                "extern void %0%1Seti%2(%6%1 %1, uint32 x, %7 value);\n"
+                "#endif\n",
+                dvPrefix, name, propName, dvPropertyGetIndex(prop), preString, postString, dvClassGetPrefix(theClass),
+                propTypeString);
         } else if(dvPropertyArray(prop)) {
             /* Fixed sized arrays */
             dvWrtemp(dvFile,
@@ -693,7 +749,7 @@
                     "%4    %0%1s.%2[%0%12Index(%1)*(%3) + %0%1Check%2Index(%1, x)] = value;%5}\n",
                 dvPrefix, name, propName, dvPropertyGetIndex(prop), preString, postString, dvClassGetPrefix(theClass),
                 propTypeString);
-        } else if(dvPropertySparse(prop)) {
+        } else if(dvPropertySparse(prop) && !dvPropertyView(prop)) {
             /* Access the data through the hash table */
             dvWrtemp(dvFile,
                 "extern %5 %0%1%3%2(%4%1 %1);\n"
@@ -727,8 +783,18 @@
                 preString = "";
                 postString = "";
             }
-            if(dvPropertyGetType(prop) == PROP_BIT) {
+            if(dvPropertyView(prop)) {
                 dvWrtemp(dvFile,
+                    "#ifndef %0%1%2\n"
+                    "extern %4 %0%1%5%2(%3%1 %1);\n"
+                    "#endif\n"
+                    "#ifndef %0%1Set%2\n"
+                    "extern void %0%1Set%2(%3%1 %1, %4 value);\n"
+                    "#endif\n",
+                    dvPrefix, name, propName, dvClassGetPrefix(theClass), propTypeString, accessString);
+            }
+            else if(dvPropertyGetType(prop) == PROP_BIT) {
+                dvWrtemp(dvFile,
                     "static utInlineC bool %0%1%2(%3%1 %1) {\n"
                     "    return (%0%1s.%2[%3%12ValidIndex(%1) >> 3] >> (%3%12ValidIndex(%1) & 7)) & 1;}\n"
                     "static utInlineC void %0%1Set%2(%3%1 %1, bool value) {\n"
@@ -774,7 +840,7 @@
     char *parameters = "";
 
     dvForeachRelationshipKey(relationship, key) {
-        property = dvKeyGetProperty(key);
+        property = dvKeypropertyGetProperty(dvKeyGetLastKeyproperty(key));
         if(!dvPropertyArray(property)) {
             parameters = utSprintf("%s, %s %s", parameters, dvPropertyGetTypeName(property), dvPropertyGetName(property));
         } else if(!dvPropertyFixedSize(property)) {
@@ -911,13 +977,18 @@
     char *nullObj;
 
     dvForeachClassProperty(theClass, prop) {
-        if(dvPropertyArray(prop)) {
+        if(dvPropertyView(prop)) {
+                dvWrtemp(dvFile,
+                    "    /* %0.%1 init is user responsability */\n",
+                    dvClassGetName(theClass), dvPropertyGetName(prop));
+        }
+        else if(dvPropertyArray(prop)) {
             if(!dvPropertyFixedSize(prop)) {
                 dvWrtemp(dvFile,
                     "    %0%1SetNum%2(%1, 0);\n",
                     dvPrefix, dvClassGetName(theClass), dvPropertyGetName(prop));
             } else {
-                /* Todo: write this */
+                /* TODO: write this */
             }
         } else {
             theUnion = dvPropertyGetUnion(prop);
@@ -1049,7 +1120,7 @@
             dvPrefix, name, dvClassGetReferenceTypeName(theClass));
         dvWrtemp(dvFile, "static utInlineC void %0%1FreeAll(void) {%0SetUsed%1(1);", dvPrefix, name);
         dvForeachClassProperty(theClass, prop) {
-            if(dvPropertyArray(prop) && !dvPropertyFixedSize(prop)) {
+            if(dvPropertyArray(prop) && !dvPropertyFixedSize(prop) && !dvPropertyView(prop)) {
                 dvWrtemp(dvFile, " %0SetUsed%1%2(0);" , dvPrefix, name,
                 dvPropertyGetName(prop));
             }
@@ -1078,7 +1149,7 @@
             "static utInlineC void %0%1Free(%0%1 %1) {\n",
             dvPrefix, name);
         dvForeachClassProperty(theClass, prop) {
-            if(dvPropertyArray(prop) && !dvPropertyFixedSize(prop)) {
+            if(dvPropertyArray(prop) && !dvPropertyFixedSize(prop) && !dvPropertyView(prop)) {
                 dvWrtemp(dvFile,
                     "    %0%1Free%2s(%1);\n",
                     dvPrefix, name, dvPropertyGetName(prop));
Index: src/dv.h
===================================================================
--- src/dv.h	(revision 542)
+++ src/dv.h	(working copy)
@@ -47,6 +47,8 @@
 dvCase dvCaseCreate(dvProperty property, dvEntry entry);
 dvSparsegroup dvSparsegroupCreate(dvClass theClass, utSym sym);
 dvCache dvCacheCreate(dvClass theClass);
+dvKeyproperty dvUnboundKeypropertyCreate(dvKey key, utSym sym);
+dvKey dvKeypropertyCreate(dvKey key, dvProperty property);
 
 /* Utility functions */
 void prUtilStart(void);
@@ -68,6 +70,10 @@
 bool dvRelationshipHashedByName(dvRelationship relationship);
 char *dvPropertyFindInitializer(dvProperty property);
 dvProperty dvClassLookupProperty(dvClass theClass, utSym sym);
+char *dvKeyGetLengthMacro(dvKey key, bool useParamName, char *param);
+char *dvKeyGetAccessMacro(dvKey key, bool useParamName, char * param);
+char *dvPropertyGetLengthMacro(dvProperty property, bool useParamName, char * param);
+char *dvPropertyGetAccessMacro(dvProperty property, bool useParamName, char * param);
 
 /* Some shortcut macros */
 #define dvModuleGetPrefix(module) utSymGetName(dvModuleGetPrefixSym(module))
Index: src/dvgenerate.c
===================================================================
--- src/dvgenerate.c	(revision 542)
+++ src/dvgenerate.c	(working copy)
@@ -147,18 +147,20 @@
     dvRelationship relationship)
 {
     dvProperty property;
+    dvKeyproperty keyproperty;
     dvPropident propident;
     dvKey key;
     utSym propSym;
 
     dvForeachRelationshipKey(relationship, key) {
-        property = dvKeyGetProperty(key);
+        keyproperty = dvKeyGetLastKeyproperty(key);
+        property = dvKeypropertyGetProperty(keyproperty);
         if(property != dvPropertyNull) {
             if(dvPropertyGetCache(property) == dvCacheNull) {
                 dvCacheAppendProperty(cache, property);
             }
         } else {
-            propSym = dvKeyGetPropertySym(key);
+            propSym = dvKeypropertyGetPropertySym(keyproperty);
             if(propSym != utSymNull) {
                 propident = dvPropidentAlloc();
                 dvPropidentSetSym(propident, propSym);
@@ -560,22 +562,39 @@
 static void bindKeysToProperties(
     dvModule module)
 {
-    dvClass theClass;
+    dvClass theClass, keyClass;
     dvRelationship relationship;
     dvProperty property;
     dvKey key;
+    dvKeyproperty keyproperty;
 
     dvForeachModuleClass(module, theClass) {
         dvForeachClassParentRelationship(theClass, relationship) {
             dvForeachRelationshipKey(relationship, key) {
-                if(dvKeyGetProperty(key) == dvPropertyNull) {
-                    property = dvClassLookupProperty(theClass, dvKeyGetPropertySym(key));
-                    if(property == dvPropertyNull) {
-                        utError("Line %u: key %s not found on class %s", dvKeyGetLineNum(key),
-                            utSymGetName(dvKeyGetPropertySym(key)), dvClassGetName(theClass));
+                keyClass = theClass;
+                dvForeachKeyKeyproperty(key, keyproperty) {
+                    if((property = dvKeypropertyGetProperty(keyproperty)) == dvPropertyNull) {
+                        property = dvClassLookupProperty(keyClass, dvKeypropertyGetPropertySym(keyproperty));
+                        if(property == dvPropertyNull) {
+                            utError("Line %u: key %s not found on class %s", dvKeyGetLineNum(key),
+                                utSymGetName(dvKeypropertyGetPropertySym(key)), dvClassGetName(theClass));
+                        }
+                        dvPropertyAppendKeyproperty(property, keyproperty);
                     }
-                    dvPropertyAppendKey(property, key);
-                }
+                    /* check for requirements on key element in the chain */
+                    if(dvKeypropertyGetNextKeyKeyproperty(keyproperty) != dvKeypropertyNull) {
+                        if(dvPropertyFixedSize(property)) {
+                                utError("Line %u: only last element of a key chain is supported as variable size, here %s",
+                                    dvKeyGetLineNum(key),
+                                    utSymGetName(dvKeypropertyGetPropertySym(key)));
+                        }
+                        if(dvPropertyGetType(property) != PROP_POINTER) {
+                            utError("Line %u: key %s must be bound to a class", dvKeyGetLineNum(key),
+                                utSymGetName(dvKeypropertyGetPropertySym(key)));
+                        }
+                    }
+                    keyClass  = dvPropertyGetClassProp(property);
+                } dvEndKeyKeyproperty;
             } dvEndRelationshipKey;
         } dvEndClassParentRelationship;
     } dvEndModuleClass;
Index: src/dvscan.l
===================================================================
--- src/dvscan.l	(revision 542)
+++ src/dvscan.l	(working copy)
@@ -195,8 +195,10 @@
 <INITIAL>"undo_redo"            {myDebug("KWUNDO_REDO\n"); return KWUNDO_REDO;}
 <INITIAL>"union"                {myDebug("KWUNION\n"); return KWUNION;}
 <INITIAL>"unordered"            {myDebug("KWUNORDERED\n"); return KWUNORDERED;}
+<INITIAL>"view"                 {myDebug("KWVIEW\n"); return KWVIEW;}
 <INITIAL>"volatile"             {myDebug("KWVOLATILE\n"); return KWVOLATILE;}
 
+<INITIAL>"."                    { myDebug(".\n"); return '.'; }
 <INITIAL>"+"\n                  { myDebug("Line continuation\n"); dvLineNum++; }
 <INITIAL>\n                     { myDebug("newline\n"); dvLineNum++; return '\n'; }
 <INITIAL>[0-9]+                 { dvlval.intVal = atol(dvlextext);
Index: src/dvbuild.c
===================================================================
--- src/dvbuild.c	(revision 542)
+++ src/dvbuild.c	(working copy)
@@ -247,7 +247,7 @@
 }
 
 /*--------------------------------------------------------------------------------------------------
-  Create a new key, which is part of a hashed relationship.
+  Create a new key, which is part of a complex relationship.
 --------------------------------------------------------------------------------------------------*/
 dvKey dvKeyCreate(
     dvRelationship relationship,
@@ -256,13 +256,28 @@
     dvKey key = dvKeyAlloc();
 
     dvRelationshipAppendKey(relationship, key);
-    dvPropertyAppendKey(property, key);
+    dvKeypropertyCreate(key, property);
     return key;
 }
 
 /*--------------------------------------------------------------------------------------------------
-  Create a new unbound key, which is part of a hashed relationship.
+  Create a new key, which is part of a complex relationship.
 --------------------------------------------------------------------------------------------------*/
+dvKeyproperty dvKeypropertyCreate(
+    dvKey key,
+    dvProperty property)
+{
+    dvKeyproperty keyproperty = dvKeypropertyAlloc();
+
+    dvKeyAppendKeyproperty(key, keyproperty);
+    dvPropertyAppendKeyproperty(property, keyproperty);
+    return keyproperty;
+}
+
+
+/*--------------------------------------------------------------------------------------------------
+  Create a new unbound key, which is part of a complex relationship.
+--------------------------------------------------------------------------------------------------*/
 dvKey dvUnboundKeyCreate(
     dvRelationship relationship,
     utSym propertySym,
@@ -271,12 +286,27 @@
     dvKey key = dvKeyAlloc();
 
     dvRelationshipAppendKey(relationship, key);
-    dvKeySetPropertySym(key, propertySym);
+    dvUnboundKeypropertyCreate(key, propertySym);
     dvKeySetLineNum(key, lineNum);
     return key;
 }
 
 /*--------------------------------------------------------------------------------------------------
+  Create a new unbound keyproperty, which is part of a complex relationship.
+--------------------------------------------------------------------------------------------------*/
+dvKeyproperty dvUnboundKeypropertyCreate(
+    dvKey key,
+    utSym propertySym)
+{
+    dvKeyproperty keyproperty = dvKeypropertyAlloc();
+
+    dvKeyAppendKeyproperty(key, keyproperty);
+    dvKeypropertySetPropertySym(keyproperty, propertySym);
+    return keyproperty;
+}
+
+
+/*--------------------------------------------------------------------------------------------------
   Create a new case object linking a property in a union to an entry.
 --------------------------------------------------------------------------------------------------*/
 dvCase dvCaseCreate(
Index: src/dvparse.y
===================================================================
--- src/dvparse.y	(revision 542)
+++ src/dvparse.y	(working copy)
@@ -27,6 +27,7 @@
 static dvUnion dvCurrentUnion;
 static dvProperty dvCurrentProperty;
 static dvRelationship dvCurrentRelationship;
+static dvKey dvCurrentKey;
 static dvCache dvCurrentCache;
 static uint32 dvCacheNumber;
 static uint32 dvCurrentEnumValue;
@@ -154,6 +155,7 @@
 %token KWUNDO_REDO
 %token KWUNION
 %token KWUNORDERED
+%token KWVIEW
 %token KWVOLATILE
 
 %%
@@ -367,6 +369,10 @@
 {
     dvPropertySetCascade(dvCurrentProperty, true);
 }
+| KWVIEW
+{
+    dvPropertySetView(dvCurrentProperty, true);
+}
 | KWSPARSE
 {
     if(dvCurrentUnion != dvUnionNull) {
@@ -592,10 +598,17 @@
 ;
 
 key: /* empty */
-| key upperIdent
+| key keyproperties
+;
+
+keyproperties : upperIdent
 {
-    dvUnboundKeyCreate(dvCurrentRelationship, $2, dvLineNum);
+    dvCurrentKey = dvUnboundKeyCreate(dvCurrentRelationship, $1, dvLineNum);
 }
+| keyproperties '.' upperIdent
+{
+    dvUnboundKeypropertyCreate(dvCurrentKey, $3);
+}
 ;
 
 relationshipOption: KWCASCADE

Re: [Datadraw-user] [datadraw] probleme of compile

[Richard P. <rdp...@gm...>]

Hi Wang,

All problematic symbols are from dvscan.o. Have you tried "rm dvscan.c
dvscan.o; make" ?  That should do it.

If the problem persist:

dvlexlex shall be defined in dvscan.c generated by dvscan.l and flex.

as I read your message, the following test shall differ from my execution,
isn't it?

[rip@localhost src]$ nm dvscan.o | grep -w dvlexlex
00000000000006fb T dvlexlex
[rip@localhost src]$ grep -w dvlexlex dvscan.c
#define yylex dvlexlex
extern int dvlexlex (void);
#define YY_DECL int dvlexlex (void)
...
[rip@localhost src]$ grep -w dvlex dvscan.l
%option prefix="dvlex"
[rip@localhost src]$ flex --version
flex 2.5.33

What is your mileage?

I tried to find on the web starting at which flex version, %option prefix
has been introduced (it has been a while for sure) but without any success.
On the main page of flex, flex 2.5.33 happen to be the oldest non obsoleted
version.


Best Regards

Richard Prescott


On Fri, Jan 16, 2009 at 5:04 PM, wang liang <fab...@gm...> wrote:

> hi, geeks
> i have a problem when i compile the source from svn
>
> gcc  -g -O2 -Wall -W -Wno-unused-parameter -Wno-unused-function   -o
> datadraw  dvadmin.o dvbuild.o dvdatabase.o dvgenc.o dvgenh.o dvgenerate.o
> dvlexwrap.o dvmain.o dvparse.o dvread.o dvscan.o dvutil.o
> ../util/libddutil-dbg.a
> dvlexwrap.o: In function `dvlex':
> /root/ed/datadraw/src/dvlexwrap.c:36: undefined reference to `dvlexlex'
> dvparse.o: In function `dverror':
> /root/ed/datadraw/src/dvparse.y:49: undefined reference to `dvlextext'
> dvread.o: In function `dvReadFile':
> /root/ed/datadraw/src/dvread.c:268: undefined reference to
> `dvLastWasReturn'
> /root/ed/datadraw/src/dvread.c:269: undefined reference to `dvEnding'
>
> the compiler can't find these extern functions and variables,  my output of
> configure
>
> checking for a BSD-compatible install... /usr/bin/install -c
> checking whether build environment is sane... yes
> checking for gawk... gawk
> checking whether make sets $(MAKE)... yes
> checking whether to enable maintainer-specific portions of Makefiles... no
> checking for gcc... gcc
> checking for C compiler default output file name... a.out
> checking whether the C compiler works... yes
> checking whether we are cross compiling... no
> checking for suffix of executables...
> checking for suffix of object files... o
> checking whether we are using the GNU C compiler... yes
> checking whether gcc accepts -g... yes
> checking for gcc option to accept ISO C89... none needed
> checking for style of include used by make... GNU
> checking dependency style of gcc... gcc3
> checking for ranlib... ranlib
> checking for a BSD-compatible install... /usr/bin/install -c
> checking for flex... flex
> checking lex output file root... lex.yy
> checking lex library... -lfl
> checking whether yytext is a pointer... yes
> checking for bison... bison -y
> checking If the compiler accepts -Wall... yes
> checking If the compiler accepts -W... yes
> checking If the compiler accepts -Wno-unused-parameter... yes
> checking If the compiler accepts -Wno-unused-function... yes
>
> ** Configuration summary for datadraw 3.1.X-unstable:
>
>    CPPFLAGS:
>    CFLAGS:       -g -O2 -Wall -W -Wno-unused-parameter -Wno-unused-function
>    LIBS:
>
> do i miss some packages of lex/yacc?
>
> thanks
>
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> Datadraw-user mailing list
> Dat...@li...
> https://lists.sourceforge.net/lists/listinfo/datadraw-user
>
>

[Datadraw-user] [datadraw] probleme of compile

[wang l. <fab...@gm...>]

hi, geeks
i have a problem when i compile the source from svn

gcc  -g -O2 -Wall -W -Wno-unused-parameter -Wno-unused-function   -o
datadraw  dvadmin.o dvbuild.o dvdatabase.o dvgenc.o dvgenh.o dvgenerate.o
dvlexwrap.o dvmain.o dvparse.o dvread.o dvscan.o dvutil.o
../util/libddutil-dbg.a
dvlexwrap.o: In function `dvlex':
/root/ed/datadraw/src/dvlexwrap.c:36: undefined reference to `dvlexlex'
dvparse.o: In function `dverror':
/root/ed/datadraw/src/dvparse.y:49: undefined reference to `dvlextext'
dvread.o: In function `dvReadFile':
/root/ed/datadraw/src/dvread.c:268: undefined reference to `dvLastWasReturn'
/root/ed/datadraw/src/dvread.c:269: undefined reference to `dvEnding'

the compiler can't find these extern functions and variables,  my output of
configure

checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking for ranlib... ranlib
checking for a BSD-compatible install... /usr/bin/install -c
checking for flex... flex
checking lex output file root... lex.yy
checking lex library... -lfl
checking whether yytext is a pointer... yes
checking for bison... bison -y
checking If the compiler accepts -Wall... yes
checking If the compiler accepts -W... yes
checking If the compiler accepts -Wno-unused-parameter... yes
checking If the compiler accepts -Wno-unused-function... yes

** Configuration summary for datadraw 3.1.X-unstable:

   CPPFLAGS:
   CFLAGS:       -g -O2 -Wall -W -Wno-unused-parameter -Wno-unused-function
   LIBS:

do i miss some packages of lex/yacc?

thanks

[Datadraw-user] 42 status

[Bill C. <bi...@bi...>]

I've written (but not yet debugged) an LR BNF interpreter for 42.  If
anyone is interested in the code base, it can be checked out with:

svn co https://graillang.svn.sourceforge.net/svnroot/graillang/trunk 42
cd 42/src/main/
./configure 
make

I've put in a request to change the unix name from graillang to l42, but
the guys at Sourceforge are on vacation.

The next step will be defining the "Core 42" syntax - the subset of 42
that will trivially translate to DataDraw style C, and be fairly natural
to synthesize to Verilog.  Then, I'll write an interpreter for the core.
In theory, with probably a few more goodies, the compiler proper will
then be done, and I can start writing libraries directly in 42 to add
higher level features, like classes.

Happy New Year.
Bill

Re: [Datadraw-user] New DataDraw computer language - Grail

[Bill C. <bi...@bi...>]

On Mon, 2008-12-29 at 09:58 -0500, Richard Prescott wrote:
> Could that be implemented with reference counts?
> 
> 
> yes, absolutely
> 
> 
> About decorator and patches
> 
> Well, ok then.  At least I tried.

I'm thinking of implementing strings, vectors, matrices, and dynamic
arrays so that they act like built-in value-types like int.  I would be
a great test of how extensible the compiler is to write all that in a
library.  If that works out, I doubt it would be hard to implement your
decorator library.

Regards,
Bill

[Datadraw-user] Parallel processing in 42

[Bill C. <bi...@bi...>]

On Mon, 2008-12-29 at 11:27 +0100, Questor Fused wrote:
> 3.) multithreading: the language should support mechanisms to support multiple threads. two paradigms I like: the intel-threading-building-blocks-approach and the csp2-approach. itbb is about work-packages that are handled parallel and csp is about channels and doing the communication via channels between the threads... both are high-level-things and perhaps better in libraries. both paradigmas can be programmed via an event-system.

A silly goal I have is to compile my 42 programs into FPGA based
reconfigurable computers, and actually run faster than if I were running
on Intel processors.  Today, this only works for signal processing
examples.  Generally, Intel processors win.  The reason for this is
simple: people focus on the wrong problem.  We don't need to be able to
do 1000 multiply operations in parallel.  What's needed is 100 parallel
memory controllers all running at full speed.  DataDraw separates object
properties into separate arrays which can be assigned to different
memories on different memory controllers.  This can allow multiple
memory controllers to run in parallel efficiently to speed up inner
loops, and no parallel programming is required.  In theory, this would
allow Xilinx to finally squash Intel for generic computation, since big
Xilinx FPGAs have the ability to access many DDR2 SRAM banks in
parallel.  I'd love to compile my EDA tools onto Xilinx hardware and run
faster!

So, parallel processing is very much a goal of 42.  Here is my new list
of 42's primary goals:

- foster extreme code reuse
- run much faster than C
- compile to both software and hardware
- run faster on reconfigurable computers than WinTel boxes
- allow users to extend the language

I'm an optimistic sort :-)  However, I have reasons for thinking it is
doable.  DataDraw shows that 42 can beat C in speed, and IMO it also
shows 42 can beat C++ in code reuse.  You probably have to take my word
for it that 42 will be compilable to hardware, but I think I'm in a good
position relative to almost anyone to make it happen.  Here's my
shameless self promotion for why I'm the right guy to write 42:

- I've been doing hardware synthesis for about 16 years
- I've have written several compilers and interpreters
- I'm the primary author of DataDraw
- I've been dreaming of writing a syntax-extensible compiler since high
school, and have written tons of lex/yacc code
- I am foolishly optimistic

I read up a bit on Intel's "building blocks", and C++CPS2.  42 programs
at the top level are processes, similar to Verilog/VHDL, and each
process can run in parallel.  The event processor will assign processes
to execution threads, and will optimize the number of parallel threads,
just like Intel's blocks.

C++CSP2 methodology is for each thread to have it's own private data,
and only communicate through channels.  Channels are similar to 42's
signals, so C++CSP2 style programming will also be supported.

I have some stories about trying to make EDA algorithms multi-threaded.
At company S, they sell a chip DRC checker.  Their first attempt to make
use of multiple processors was for Sun Micro's symmetric multiprocessor
machines.  After a multi-man-year effort, the DRC checker was finally
multi-threaded.  When they tested it, the tool ran slower!  What they
failed to realize was that their primary bottleneck was access to
memory, and by having multiple threads fighting over it, their program
slowed down rather than speeding up.

A program with a common database running on a symmetric multiprocessor
is very different than multiple processors working on separate
databases, and communicating when needed. The C++CSP2 mechanism could
work OK for processes that have local rather than shared databases, and
could allow processes to run across a network, or on multiple FPGAs on a
multi-FPGA reconfigurable computer.  That would work well for DRC
checking.  It might even work well for placement, if you use some sort
of partitioning placer, but it wont work at all for quadratic placers.

This would require an ability to have multiple databases of the same
type in the same program at the same time, something which currently is
not supported in DataDraw, but probably should be.  I'll try to work it
into the semantics of 42 when I iron out details.

Regards,
Bill

Re: [Datadraw-user] New DataDraw computer language - Grail

[Richard P. <rdp...@gm...>]

*Could that be implemented with reference counts?*

yes, absolutely


*About decorator and patches*

Well, ok then.  At least I tried.

Re: [Datadraw-user] BNF in 42

[Bill C. <bi...@bi...>]

Hi, kai.  Nice to hear from you.

On Mon, 2008-12-29 at 11:27 +0100, Questor Fused wrote:
> I like your ideas and have some comments, but not yet the time to contribute much :(
> some thoughts:
> 
> 1.) if you want to play around with an extensible interpreter have a look at tinypy (http://www.tinypy.org/). it's an interpreter of a subset of python and extensible at runtime...

Cool link.  I read some of the author's blog entries.  I wish I knew
Python better.  I love that the current language reference is 78 pages,
and that most of that is fluff like glossary and appendix.

Realistically, this 42 effort of mine is unlikely to result in anything
particularly useful to very many people, but I enjoy the language
development anyway.  I appreciate help especially from people with more
Python experience.

> 2.) I vote for tuples to return multiple values (I don't like the c++-way with references/values) because you can quickly see which parameters are put into a function and which parameters are returned

I agree.  I'll can pass by reference, and add returning tuples and
multiple assignment, but wont add tuples as a basic type, as Python
does, since I'll have struct to describe conglomerate types.

> 3.) multithreading: the language should support mechanisms to support multiple threads. two paradigms I like: the intel-threading-building-blocks-approach and the csp2-approach. itbb is about work-packages that are handled parallel and csp is about channels and doing the communication via channels between the threads... both are high-level-things and perhaps better in libraries. both paradigmas can be programmed via an event-system.

I've always liked how natural multi-treading is in hardware description
relative to using pthreads.  I want to keep the language compilable to
hardware, so multi-threading needs to work through the event processor
using signals that can compile to wires.

> 4.) a good way to debug the user-extensible-modules!!!  but I don't know what "a good way" could be...

I agree.  The hardest code to debug is code that generates code,
especially when the generated code is used in the code generator.
DataDraw has this problem... screw up one line of generator code, do a
make and then a make clean, and life suddenly gets hard.  The "make"
command overwrites a working version of datadraw with the one that has
the error, then "make clean" deletes all the database files datadraw
generates for it's own data structures.  When I rerun datadraw to
generate new database files, I get the version with bugs that wont
compile.  I've spent many hours backing out of this particular hole.

I think debugging for compiler extensions is just hard.  Having an
interpreter will help.  I find debugging in interpreters to be fairly
handy.

Best regards, and happy holidays.
Bill

Re: [Datadraw-user] BNF in 42

[Questor F. <qu...@fu...>]

I like your ideas and have some comments, but not yet the time to contribute much :(
some thoughts:

1.) if you want to play around with an extensible interpreter have a look at tinypy (http://www.tinypy.org/). it's an interpreter of a subset of python and extensible at runtime...

2.) I vote for tuples to return multiple values (I don't like the c++-way with references/values) because you can quickly see which parameters are put into a function and which parameters are returned

3.) multithreading: the language should support mechanisms to support multiple threads. two paradigms I like: the intel-threading-building-blocks-approach and the csp2-approach. itbb is about work-packages that are handled parallel and csp is about channels and doing the communication via channels between the threads... both are high-level-things and perhaps better in libraries. both paradigmas can be programmed via an event-system.

4.) a good way to debug the user-extensible-modules!!!  but I don't know what "a good way" could be...

happy coding and a happy new year :)
regards
   kai


----- original Nachricht --------

Betreff: Re: [Datadraw-user] BNF in 42
Gesendet: So, 28. Dez 2008
Von: Bill Cox<bi...@bi...>

> On Sun, 2008-12-28 at 11:29 -0500, Richard Prescott wrote:
> > Your are far more experienced then me regarding complex language
> > parsing.  I take your words for granted blindly.
> > 
> > I allow strings in the grammar rules to be lex-style regular
> > expressions.  What do you think?
> > 
> > 
> > That is what I wished.  I was reading about LALR and it seems
> > feasible.
> > 
> > Is your example part of the same syntax of defining relationship and
> > classes or a different syntax on a different file type?
> 
> It's part of the same file.  I may add a "syntax" keyword to introduce
> syntax blocks, but syntax blocks will be part of 42.
> 
> A primary goal of 42 will to be user-extensible.  A 42 interpreter will
> parse the syntax rules, and apply them while reading further code.  It
> remains to be defined, but at certain points in compilation,
> user-defined 42 code can be declared to make modifications to the
> program database.  While the 42 interpreter may have value on it's own,
> the primary output of the 42 translator will be (initially) C source
> code written DatDraw style.  A second output (much harder, but doable),
> will be Verilog output.  DataDraw's use of integer references makes
> hardware compilation of database data structures much more doable.
> 
> > The good point about the previous was cleanness based on
> > indentation...
> > Although, I don't have anything wonderful to propose.
> > 
> > Regards
> > 
> > Richard
> 
> 
> 
> ----------------------------------------------------------------------------
> --
> _______________________________________________
> Datadraw-user mailing list
> Dat...@li...
> https://lists.sourceforge.net/lists/listinfo/datadraw-user
> 

--- original Nachricht Ende ----

Re: [Datadraw-user] BNF in 42

[Bill C. <bi...@bi...>]

On Sun, 2008-12-28 at 11:29 -0500, Richard Prescott wrote:
> Your are far more experienced then me regarding complex language
> parsing.  I take your words for granted blindly.
> 
> I allow strings in the grammar rules to be lex-style regular
> expressions.  What do you think?
> 
> 
> That is what I wished.  I was reading about LALR and it seems
> feasible.
> 
> Is your example part of the same syntax of defining relationship and
> classes or a different syntax on a different file type?

It's part of the same file.  I may add a "syntax" keyword to introduce
syntax blocks, but syntax blocks will be part of 42.

A primary goal of 42 will to be user-extensible.  A 42 interpreter will
parse the syntax rules, and apply them while reading further code.  It
remains to be defined, but at certain points in compilation,
user-defined 42 code can be declared to make modifications to the
program database.  While the 42 interpreter may have value on it's own,
the primary output of the 42 translator will be (initially) C source
code written DatDraw style.  A second output (much harder, but doable),
will be Verilog output.  DataDraw's use of integer references makes
hardware compilation of database data structures much more doable.

> The good point about the previous was cleanness based on
> indentation...
> Although, I don't have anything wonderful to propose.
> 
> Regards
> 
> Richard

Re: [Datadraw-user] New DataDraw computer language - Grail

[Bill C. <bi...@bi...>]

Hi, Richard.

I like the 'on' statement.  DataDraw already has destructor a
> Bill, everybody,
> 
> Richard again.
> 
> I notice a mistake in my closure example.  What if the mutate variable
> (called closure_var in my example) gets used by two subroutines?  the
> first one who get destroyed will `cascade' delete the var and the
> other wont be able to use it anymore.
> 
> Well after `cascade' and `mandatory', I guess it is time for a new
> decorator.  I would call it `parasitism' for now. (I was tempted by
> `garbage_collected' but that would be overwhelming.)  `Parasitism'
> mean here that child can live as long as it gets one of its host
> Parent alive.

Could that be implemented with reference counts?

> Regarding module parameters and relationship decorators, we have up to
> now:
>       * relationship directionality: mutual, parent_only, child_only
>       * relationship termination behavior: separation, mandatory,
>         cascade, and now parasitism
>       * data structure keying information: hash key, comparison
>         function...
>       * be my guess: invent your own
> `parent_only' and `child_only' are destructive and intimately related
> to the internal data structure of the relationship.
> 
> Relationship termination behavior is another story.  they are
> constructive and independent of the internal data structure.
> Therefore they could probably be defined separately.
> 
> decorator relationship.cascade(Parent parent, Child child)
>     on Parent.destroy()                      # `on' event driven
> engine... becomes inline
>         safe foreach parent.clabel(child)    # where do I get this
> label??
>             delete child

I don't know... C++ and some other languages go to great efforts to make
generic code work with declarations, rather than just generating the
code, like the 'reuse' statement.  Module parameters seem pretty simple
as a concept compared to relationship decorators.  To change
functionality in a base module, I'd rather focus on extensions to the
'reuse' concept.

For example, if 'cascade' was not already a parameter to modules, what
if we allowed the user to redeclare the module with the parameter?  For
example, you copy and past the old module declaration, and any functions
you want to edit, and simply make them look the way you want.  The 42
compiler would make such edits when it sees redefinition of classes,
functions, or modules.  I feel that patching an author's code is far
more common than extending it through inheritance, or other mechanism,
so why not directly support patches?  In this case, we would have:

    "Add debug, cascade, and mandatory as a module parameters."
    module LinkedList(bool cascade, bool mandatory)

    if !childonly
        inline Child.destroy(Child child)
            Parent parent = child.plabelParent
            if debug
	        assert !mandatory || parent != null
	    if mandatory || (cascade && parent != null)
	        parent.removeClabelChild(child)

To add reference counting, we'd need to modify.  We need to detect when
a variable of a given class type is written to, and decrement the
reference count of whatever it use to refer to, and destroy the object
if the ref count reaches zero.  We could override the get/set methods
for class members.  We could convert all assignments, even to local
variables, to get/set functions.  Then we'd need to generate ref count
code for each set function that assigns to the given type.

If we could get this to work with strings, vectors, dynamic array, and
matrices, it'd be a good step.  I think this will be more natural once
all the mirror classes are defined.  Then we can write code to make
these kinds of transformations directly in a 42 library.  With syntactic
extension, you could even write that library, and invoke it with syntax
similar to what you defined above.  Then, we could bicker about the
value of your syntax for a while and decide if it makes it into the
default library, or just your add-on.

Bill

Re: [Datadraw-user] BNF in 42

[Richard P. <rdp...@gm...>]

Your are far more experienced then me regarding complex language parsing.  I
take your words for granted blindly.

* I allow strings in the grammar rules to be lex-style regular
expressions.  What do you think?*

That is what I wished.  I was reading about LALR and it seems feasible.

Is your example part of the same syntax of defining relationship and classes
or a different syntax on a different file type?

The good point about the previous was cleanness based on indentation...
Although, I don't have anything wonderful to propose.

Regards

Richard


On Sun, Dec 28, 2008 at 5:41 AM, Bill Cox <bi...@bi...> wrote:

> Hi, Richard.
>
> I've written a ton of lex/yacc flex/bison based parsers.  Here's one
> thing I've found.  Most formats are context sensitive.  You just can't
> parse them the easy way, but have to build a parse tree and then
> traverse it manually to extract data.  Icky, but true.  This is
> massively true for VHDL, even thought the Preface of the VHDL Language
> Reference says it's not.  It's even true for Verilog.  Simple formats,
> like Synopsys Liberty format, are massively context dependent.
>
> In 42, I figured I'd give up on allowing generic code to execute for
> each matched rule, and just go ahead and build a parse tree for the
> user.  That separates all the application specific code from the grammar
> definition, and should help make the grammars more reusable and easier
> to read.
>
> I allow strings in the grammar rules to be lex-style regular
> expressions.  What do you think?
>
> The attached file is a grammar that I currently parse to build a parser
> rule database.  Then, I'm planning to write a BNF interpreter and
> re-parse this file using the rules defined in the file.  Once that
> works, I was planning to start writing the rest of the core 42 parser in
> 42 directly, and then start on the interpreter for it.  When the
> interpreter is running, I can start writing libraries to compile more
> advanced 42 constructs into simpler code which can be directly written
> out in C.  Anyway, that's the plan... too bad the holidays wont last
> forever - I'll probably have to get too focused on real work to make
> much progress come January.
>
> Regards,
> Bill
>
> Regards,
> Bill
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Datadraw-user mailing list
> Dat...@li...
> https://lists.sourceforge.net/lists/listinfo/datadraw-user
>
>

Re: [Datadraw-user] New DataDraw computer language - Grail

[Richard P. <rdp...@gm...>]

Bill, everybody,

Richard again.

I notice a mistake in my closure example.  What if the mutate variable
(called closure_var in my example) gets used by two subroutines?  the first
one who get destroyed will `cascade' delete the var and the other wont be
able to use it anymore.

Well after `cascade' and `mandatory', I guess it is time for a new
decorator.  I would call it `parasitism' for now. (I was tempted by
`garbage_collected' but that would be overwhelming.)  `Parasitism' mean here
that child can live as long as it gets one of its host Parent alive.

Regarding module parameters and relationship decorators, we have up to now:

   - relationship directionality: mutual, parent_only, child_only
   - relationship termination behavior: separation, mandatory, cascade, and
   now parasitism
   - data structure keying information: hash key, comparison function...
   - be my guess: invent your own

`parent_only' and `child_only' are destructive and intimately related to the
internal data structure of the relationship.

Relationship termination behavior is another story.  they are constructive
and independent of the internal data structure.  Therefore they could
probably be defined separately.

decorator relationship.cascade(Parent parent, Child child)
    on Parent.destroy()                      # `on' event driven engine...
becomes inline
        safe foreach parent.clabel(child)    # where do I get this label??
            delete child


Regards

Richard,  a big worm of the can you opened...  ;-)

[Datadraw-user] BNF in 42

[Bill C. <bi...@bi...>]

Hi, Richard.

I've written a ton of lex/yacc flex/bison based parsers.  Here's one
thing I've found.  Most formats are context sensitive.  You just can't
parse them the easy way, but have to build a parse tree and then
traverse it manually to extract data.  Icky, but true.  This is
massively true for VHDL, even thought the Preface of the VHDL Language
Reference says it's not.  It's even true for Verilog.  Simple formats,
like Synopsys Liberty format, are massively context dependent.

In 42, I figured I'd give up on allowing generic code to execute for
each matched rule, and just go ahead and build a parse tree for the
user.  That separates all the application specific code from the grammar
definition, and should help make the grammars more reusable and easier
to read.

I allow strings in the grammar rules to be lex-style regular
expressions.  What do you think?

The attached file is a grammar that I currently parse to build a parser
rule database.  Then, I'm planning to write a BNF interpreter and
re-parse this file using the rules defined in the file.  Once that
works, I was planning to start writing the rest of the core 42 parser in
42 directly, and then start on the interpreter for it.  When the
interpreter is running, I can start writing libraries to compile more
advanced 42 constructs into simpler code which can be directly written
out in C.  Anyway, that's the plan... too bad the holidays wont last
forever - I'll probably have to get too focused on real work to make
much progress come January.

Regards,
Bill

Regards,
Bill

Re: [Datadraw-user] New DataDraw computer language - Grail

[Bill C. <bi...@bi...>]

Hi, Richard.

On Sat, 2008-12-27 at 12:13 -0500, Richard Prescott wrote:
> I like those discussions....  I wish we could take a beer around that.

Here's a virtual beer, then!

> Happy Holidays to everybody on the list.  I forgot to mention it last
> time.
> 
> Oups! my last mail wasn't signed. So yes, it was me: Richard.
> rdprescott on skype and gmail, richardprescott on linkedin, if anybody
> wonder.  And by the way, I am a software contractor looking for jobs
> right now.

I'll add that Richard seems to be one of the brightest programmers I've
run across in the 22 years since I graduated from college.  People could
do a lot worse than hiring Richard for software consulting.

> I just hope that all this is not too much noise for others on the
> list.  Sorry if it is the case for you.  Although, the archive button
> is easy.
> 
> I will try to separate my though onto subjects. Separate emails could
> have been irritating.  I am tempted to create a google doc on this.
> 
> Naming: grail, 42
> 
> I am a big fan of The Guide.  Although, 42.org and fortytwo.org are
> already took.  That makes me sorry, I liked 42.  There is certainly
> another way to homage Douglas Adams by taking another name from its
> novel.

42 it is.

> Strong typing
> 
> I have a new opinion on the subject.  Strong typing for data and
> parameter typing determine at compile-time as your min-max example.
> That would cover two important features of modern languages which are
> templates and interfaces in a simple elegant way.  This is now
> possible given your though (which I totally share) regarding reuse.
> The only drawback would be the amount of code generated, but even
> there, I think it wouldn't be that bad.  Small code base can get
> reused a lot, large code base tend to be used once.

I've written one compiler that uses this feature before.  It turns out
to be a bit less useful in practice than I'd hoped, but it's also fairly
easy to implement.

> Line continuation with \
> 
> I was thinking of line continuation with backslash for code not for
> comment.  Personally, I don't like multi-line comment and I am not
> forced to use it ;-)

I agree.  The block comment { ... } I'm thinking would be to comment out
whole sections, the way we do with #if 0 in C.

> Returning tuples and passing by reference
> 
> I notice it in the fifo.gr example.  I had a bad feeling about it but
> my mind wasn't set.  As normal object passing will be through handles,
> a method can modify object's properties no problem.  So the only place
> a reference is useful is for basic types (including handles
> themselves)
> 
> On the other hand, tuples may not be too hard to implement (maybe not
> in the first version)
> 
> Let
> retval, error function(param)
> 
> which consist of returning a tuple but its C implementation could be
> using a reference.
> retval_type function(Param_type param, error_type * error)
> 
> if the error code is not used, it could be optimized out:
> 
> foreach parent child
>     child.attribute = function(child)

I'm glad you have a lot of Python experience.  I have only read the
manuals, and occasionally had to look at a piece of code, but haven't
ever developed in Python.  My biases are mostly from my C experience.

My primary interest in tuples is to return multiple values from a
function, as in your example.  We could, for example, not support
tuples, but only a multi-value assignment statement like:

    x, y = findX(), findY()

or

    x, y = findPoint()

This would allow multiple return values, while avoiding two problems
with pass-by-reference.  First, it's hard to read code that randomly
uses pass-by-reference and pass-by-value, since you never know for sure
which parameters are inputs and which are outputs without reading the
function declaration in a header file.  Second, uninitialized return
values passed by reference don't even generate warnings in gcc, leading
to random crashes.

In Python, tuples are a full data type.  They seem to be used as
undeclared structures.  Personally, I prefer to declare structures, and
name the fields.  Here's a link where a guy argues that tuples should
have named fields, like C structures:

http://jtauber.com/blog/2008/11/21/relations_with_python_named_tuples/

I think structures need to be in the language to describe conglomerate
value types, like points, or IP packet headers.  I haven't shown them in
examples, but the fifo.42 example takes FifoWritePort and FifoReadPort
types, which are basically structures, in this case containing signals
since they are passed to a circuit.

With structures in 42, and a multi-value assignment statement, is there
any need for tuples as a full supported data type?

> Iterators, list comprehension and more
> 
> The strongest feature of 42 is definitely the relationship keyword and
> all good data types borrowed from datadraw.  Iterators as you defined
> it is intimately related to it. I do not see the need of fancier
> iterators given that fact.
> 
> Now, list comprehension is the answer of python to remove filter, map
> operators in p3k.  I don't know what should be our approach, what is
> the best approach.  What I know is that I insist on having a way to
> wrote data transformation in a simple elegant way.  Something that
> will generate code using the iterators as you defined it.  No need for
> more!
> 
> parent1.child1 = [ foreach parent2 child2: function(child2) ]
> 
> or
> 
> parent1.child1 = map(function, parent2, child2)
> 
> which is equivalent of 
> 
> parent1.deleteAllChild1()
> foreach parent2 child2
>     Child1 c = function(child2)
>     parent1.child1 += c

I prefer the full spelled-out foreach loop to maps.  Way back in the
early 80's when I learned Lisp as part of an algorithms class, I found
that most of the other students had trouble with map.  Several students
asked me to explain it to them.  These weren't dumb kids, either, even
if maps are a simple concept.  I think map belongs in a functional
language, but probably not 42.

> Now that I am writing it down, I really think that a more modern type
> of iterator is possible, here is what I am thinking of:
> 
> class SpatialTree
>     Polygon polygons linked_list # bad...
> 
>     # note that polygon must be of type Polygon, no doubt, 
>     #  so why specify it?
>     # and box: as soon as it can gives 
>     #  left, right, bottom top that is alright
> 
>     iterator touching(box,polygon)
>         # very bad implementation
>         foreach polygons(polygon) # why naming the local variable?
>             if polygon.touching(box)
>                 yield
>  
> # and now its usage
> Polygon polygon
> foreach my_spatial_tree.touching(window.box, polygon)
>    window.draw(polygon)
> 
> I love your depth first example. 

This is exactly the kind of iterator I'd like to support in my 42
compiler.  It's just code structure manipulation, with no runtime
overhead.

> Break and continue statement
> 
> Well, the example you provided tells me that break may be syntactic
> sugar but looks better.

Which is why it will be in a library :-)  One thing that I haven't
described clearly is how such code manipulation can be in a library.
The "reuse" statement isn't powerful enough to introduce new syntax or
modify code structure.  With synactic extension, and a language database
that you can manipulate directly in 42, you should be able to make
extensions like break in a library.  This is similar to mirror classes,
but interpreted at compile-time rather than runtime.  Exactly which code
can be interpreted vs compiled may need to be declared more explicitly,
but I was thinking it would simply depend on what data code accesses.
If you only read/write data from the language database, your code can be
interpreted at compile time.  Anything you read through a system call is
data only available at runtime.

> Class inheritance
> 
> It is syntactic sugar.  Less used as new concept are brought such as
> interfaces and dynamic types in my opinion.  Very useful to write UML
> poem such as "a rose is a rose".  At the same time, we may loose users
> just because they think 42 is not OO because it have no class
> inheritance.  So why not?

I tend to agree.  Programmers expect class inheritance now days.  Also,
we can do like many modern languages, and make all functions virtual.
That eliminates some confusion for programmers.

> The way UML view it is one kind of relationship. Programming language
> make it very strong but not UML.  Actually, the way relationship
> one-to-one relationship works in datadraw would show no overhead
> because of that.  In addition to this one-to-one relationship, it adds
> dual cascade and a way to "import" functions symbols from parent to
> child.  For abstract based class and/or virtual functions, implicit
> one to one relationship to methods?  That sounds pretty
> straightforward?

Yes, base class methods will be inherited by derived classes.

> importing symbol could be explicit alias as in python. and because you
> named the reuse, it can become very fancy mapping.  As soon as it can
> be evaluated at compile-time.

I'm not thinking of adding method mapping in class inheritance.  When
there are name collisions, the user will be able to specify which method
to call using a "." operator to specify the base class.

BTW, I'm not a fan of Python's "from" statement.  When multiple modules
export the same function name, the user can just use a dot operator to
pick the correct function.

> module parameters extention
> 
> That is a place where a default value shows its value.  ;-)

Ok, default values for module parameters make sense.  For functions,
however, they mostly seem to make sense in an environment that allows
function overloading.  While I'm not dead-set against function
overloading (I like it for overloading operators), I haven't seen much
need for it.  Are default parameters and function overloading something
you feel are significant advantages?

> Up to now, it is very easy to extend module and classes without modify
> the original author version. simply with inheritance and adding
> definitions.
> 
> String
> 
> String was my first answer but it is so a hot topic in c++ that I
> didn't want to go there.  I agree with you.

Strings are a PITA.  There are a small set of value types which are not
actual objects that you would create and delete manually, which don't
fit neatly into stack variables because they have variable memory.
These include strings, vectors, matrices, and dynamic arrays.  Having a
"string" alias for "array char" is easy.  Having proper string support
is hard.

Ideally, types like this are garbage-collected, or use reference counts
and get deleted when no longer referenced.  I'd like to support them in
42 properly, but I don't want it to get out of control like it did in C
++.  Would it make sense to add automatic reference counting to these
types of objects?

> CLI
> 
> I disagree, I know that was not your first goal.  But as you wrote:
> people will use your code in a way you didn't expect!  ;-)   Here is
> my though:
> 
> You will need a frontend parser for the language and three backends:
> one for C, one for verilog, and one for compile-time expression
> evaluation.  Three for me means multiples.  Enough to justify some
> abstraction and allow adding more: VHDL, direct machine language,
> virtual machine binary, whatever.  None of them is part of your goals
> but could be done by third party.
> 
> What I like from a CLI (command line interface or shell) is that it
> allows quicker development. I like to test concept in python shell
> when working on a larger python code base.  
> 
> Also, the datadraw shell have shown its value.  You want to loose it?

Actually, now that you've pushed the point, I realize that a 42 shell is
probably both natural and easy.  The code that can be interpreted at
compile-time is interpreted.  I was thinking that the interpreter would
be some subset of 42, but defining that subset is a PITA.  If it's
simply a 42 interpreter, you get your shell.  The "core" language that
actually gets compiled into hardware or software is far simpler than the
full 42 language.  It's the back-end compilers that get to use a subset.

We were discussing the syntax for function calls.  In particular, do we
allow both function-call syntax, and command-line syntax?  How can I
distinguish in the parser the difference between variable declaration
and function call?

    Polygon p1 p2
    findNearestPolygon x y
    findNearestPolygon(x, y)

For now, I'm assuming that the () are not optional.

> Closure
> 
> Let start with an example:
> global_type global_var
> def f1()
>     local_type local_var
>     closure_type closure_var  # looks like local but is not
>     def f2()
>         mutate_var += global_var
>     return f2
> 
> I just expect that internally something such as the following happen:
> 
> relationship f2 closure_type:closure_var mandatory
> 
> That's it!

I'm a bit confused by your example, but I think I get it.  Here's a
problem, though.  I want to synthesize 42 into hardware, but I don't
know how to synthesize code that generates functions, and then calls
them.  C-style function pointers are ok, because I can analyze the code
and see what all the possible values are that can be assigned to a
function pointer.  I can replace the function pointer with a function
type, and instead of calling indirect through a pointer, I can switch on
the type and call the correct function.

With function generators, I wont be able to determine all the possible
values of a function pointer at compile time.  How do you synthesize a
call to a function that hasn't been built yet?

> Namespace
> 
> Agree, I don't know what is best regarding operators but I prefer
> consistency all over the place.  Regarding compatibility with
> datadraw, it could be possible to wrote a different frontend?  ;-)

Yes, a different frontend would be ok.  42 is strongly motivated by
DataDraw, but let's not restrict 42 because of old DataDraw syntax.

> About hierarchical modules, I think it is a good idea.  This culture
> have been brought by Java but we see that in C++, Perl, Python,
> probably Ruby.  That solve a lot of issue when the user-base growth.
> Also, I don't think that will be hard to implement and use.
> especially when people reuse.  Which is one of the goals, isn't it?

Hierarchical modules wouldn't be too hard to support.  Would we also do
like Java, and try to have a directory structure that mimics the module
structure?  I haven't done enough Java programming to get a feel for how
worthwhile this is.

Regards,
Bill