Re: case sensitivity

resend.

Date: Sun, 2 Mar 2003 22:19:01 -0500
Subject: Re: case sensitivity
From: James Knight <[email protected]>
To: [email protected]
In-Reply-To: <[email protected]>

I've thought that the best way to interface GOO to C would be to make 
an analog to the "asm" syntax in C. And just think, then you can do asm 
in C in GOO! Something like (see note at bottom about r"""stuff"""):
(df example (my-num|<int> my-str|<str>)
   (c-inline (("int" "my_num" my-num) ("char *" "my_str" my-str) => 
(("int" "result" result) ("int" "my_num" my-num))
   (r"""sprintf("foo %d %s\n", my_num, my_str);"""))

Or perhaps you could leave out some of the options in the name 
declaration line and have suitable defaults (ie convert "-" to "_" (and 
rules for other chars), convert <int> to "int", <str> to "char *", etc.

(df example (my-num|<int> my-str|<str>)
   (def result|<int> 0)
   (c-inline (my-num my-str => (("int" result) my-num))
     (r"""sprintf("foo %d %s", my_num++, my_str); result = 5;"""))

Also allow the creation of C functions from the GOO file so you can 
call them from other C inlines:
(c-code r"""
#define BLAHBLAH 5
void do_stuff()
{
	stuff;
}
""")

r"foo"
Basically, I don't feel that it's all that useful in most cases to 
actually expose the C API directly to GOO. You almost always want to 
wrap it up somehow, so why go through the whole exercise of making up 
GOO functions of the C primitives and then making a second layer of 
wrappers around those. Just make it so you can jump straight to the 
second layer, and you've got a much more usable system. Since GOO is 
generating C anyhow, it isn't that farfetched to just allow the user to 
intersperse their own code in the output stream. The only hard part is 
nice-ifying the name/type conversions at the boundaries. Of course, if 
the user does something stupid like "#define void int", the generated 
GOO code will miscompile as well as the user's C code, but I don't 
consider that possibility something worth worrying an excessive amount 
about.

Unfortunately I didn't have time to try implementing this.

Also - I used two pythonish notations in the example, which GOO doesn't 
actually support. One is the """string""" for having strings that 
contain ". The other is the character 'r' prefix for the string, which 
makes it a raw string (ie: doesn't interpret backslash escapes).

James

PS: case insensitive (but preserving!) systems are great. I want one 
for linux. :)

On Sunday, March 30, 2003, at 02:31  PM, Bryn Keller wrote:
> jm wrote:
>
>>> This is bad practice, though, as it's confusing and introduces 
>>> potential for errors. IMVHO, whatever  is decided, bad practice from 
>>> thirty-year-old programming languages is a problem for wrapper 
>>> generators rather than new programming languages.
>>>
>>
>> this sounds like an argument for designing goo in a vacuum. however, 
>> I don't think we can ignore the computing landscape in which goo has
>> to operate. the fact is that a very large number of libraries are
>> written in c and some of them will use bad coding standards and
>> some of these will need to be wrapped. I consider wrapping a library
>> for use in goo as part of the 'goo experience' so weaknesses in
>> wrapper generators are weaknesses in goo.
>>
> Is there some reason we can't make an FFI that allows us to specify 
> the C name separately (in a string, say) from the GOO name? Wouldn't 
> that solve this whole problem? If FFI is the only area where case is 
> important, let's just address it there.
>
> Regards,
> Bryn