Bryan C. Warnock:
# On Tuesday 26 February 2002 22:17, you wrote:
# > How is this the case? STRING ** and Parrot_String * are equivalent.
# > You can use & on both a STRING * and a Parrot_String to get
# a STRING**
# > (a.k.a. a Parrot_String *). I don't see where the problem is.
#
# Ah, except
On Tuesday 26 February 2002 22:17, you wrote:
> How is this the case? STRING ** and Parrot_String * are equivalent.
> You can use & on both a STRING * and a Parrot_String to get a STRING**
> (a.k.a. a Parrot_String *). I don't see where the problem is.
Ah, except that you had a different typede
Bryan C. Warnock:
# On Tuesday 26 February 2002 22:17, you wrote:
# > How is this the case? STRING ** and Parrot_String * are equivalent.
# > You can use & on both a STRING * and a Parrot_String to get
# a STRING**
# > (a.k.a. a Parrot_String *). I don't see where the problem is.
#
# Ah, except
Bryan C. Warnock:
# On Tuesday 26 February 2002 14:31, Brent Dax wrote:
# > But they'll know about char* unless this is their first C
# program. I
# > don't think we should expect them to know which of our
# types should be
# > used as pointers and which shouldn't.
# >
# > Look at it this way. P
On Tuesday 26 February 2002 14:31, Brent Dax wrote:
> But they'll know about char* unless this is their first C program. I
> don't think we should expect them to know which of our types should be
> used as pointers and which shouldn't.
>
> Look at it this way. Pro: it makes things simpler for em
Dan Sugalski:
# At 10:31 AM -0800 2/26/02, Brent Dax wrote:
# >Different scopes, different policies. Outside the core (and
# in places
# >with external visibility) we use the Parrot_Foo-type
# pointer-to stuff;
# >inside we use FOO. *This is the same policy we have now*, except for
# >the outsid
Dan Sugalski:
# At 10:26 AM -0800 2/26/02, Brent Dax wrote:
# >That'll just give us an explosion of wrapper types.
#
# Not wrapper types, no. But 'different' types, yes.
#
# Extenders will probably see things like:
#
# typedef void PMC;
#
# or
#
# typedef char PMC;
#
# rather than the actu
At 10:31 AM -0800 2/26/02, Brent Dax wrote:
>Different scopes, different policies. Outside the core (and in places
>with external visibility) we use the Parrot_Foo-type pointer-to stuff;
>inside we use FOO. *This is the same policy we have now*, except for
>the outside the core part. I want tha
At 10:26 AM -0800 2/26/02, Brent Dax wrote:
>That'll just give us an explosion of wrapper types.
Not wrapper types, no. But 'different' types, yes.
Extenders will probably see things like:
typedef void PMC;
or
typedef char PMC;
rather than the actual struct.
>Like it or not,
>embedd
Dan Sugalski:
# At 8:10 PM -0800 2/23/02, Brent Dax wrote:
# > typedef struct foo_t * FooPtr;
# > typedef struct foo_t FOO;
#
# Y'know, thinking about this, I don't like this trick. That should be
# FOO, and FOO *.
#
# We either typedef the struct, or the pointer to a struct. Not both.
Di
Dan Sugalski:
# At 8:35 PM -0800 2/23/02, Brent Dax wrote:
# >The Magic Word in this case is "embedders".
# >
# >a) We can't reserve "any symbol starting with 'P'" to
# Parrot. That's a
# >little too wide a scope.
# >b) I'd rather not have embedders worrying about "is this a
# value type or
# >a
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 8:10 PM -0800 2/23/02, Brent Dax wrote:
> > typedef struct foo_t * FooPtr;
> > typedef struct foo_t FOO;
>
> Y'know, thinking about this, I don't like this trick. That should be
> FOO, and FOO *.
>
> We either typedef the struct, or the point
At 8:35 PM -0800 2/23/02, Brent Dax wrote:
>The Magic Word in this case is "embedders".
>
>a) We can't reserve "any symbol starting with 'P'" to Parrot. That's a
>little too wide a scope.
>b) I'd rather not have embedders worrying about "is this a value type or
>a pointer type?". They don't *wan
At 8:10 PM -0800 2/23/02, Brent Dax wrote:
> typedef struct foo_t * FooPtr;
> typedef struct foo_t FOO;
Y'know, thinking about this, I don't like this trick. That should be
FOO, and FOO *.
We either typedef the struct, or the pointer to a struct. Not both.
--
On Sat, 23 Feb 2002 20:10:53 -0800,
Brent Dax <[EMAIL PROTECTED]> wrote:
> Dan Sugalski:
> # At 10:43 PM -0500 2/23/02, Josh Wilmes wrote:
> # >So indent needs to be told about non-standard type
> # (typedefs) to work best.
> # >The problem is that some of the parrot code does this:
> # >
On Saturday 23 February 2002 23:35, Brent Dax wrote:
> The Magic Word in this case is "embedders".
>
> a) We can't reserve "any symbol starting with 'P'" to Parrot. That's a
> little too wide a scope.
Well, Phuck.
> b) I'd rather not have embedders worrying about "is this a value type or
> a po
Bryan C. Warnock:
# On Saturday 23 February 2002 23:20, Brent Dax wrote:
# > The Right Answer is probably to change all the STRING*s in
# the core to
# > Parrot_Strings. However, there are two problems with that:
#
# I think that's the recommended school of thought, although
# I've always
# prefe
On Saturday 23 February 2002 23:20, Brent Dax wrote:
> The Right Answer is probably to change all the STRING*s in the core to
> Parrot_Strings. However, there are two problems with that:
I think that's the recommended school of thought, although I've always
preferred *not* to typedef the final
Bryan C. Warnock:
# On Saturday 23 February 2002 23:10, Brent Dax wrote:
# > struct foo_t {
# > int i;
# > };
# >
# > typedef struct foo_t * FooPtr;
# > typedef struct foo_t FOO;
# >
# > void bar(FooPtr);
# >
# > void bar(FOO *x) {
# > x->i++;
# >
On Saturday 23 February 2002 23:10, Brent Dax wrote:
> struct foo_t {
> int i;
> };
>
> typedef struct foo_t * FooPtr;
> typedef struct foo_t FOO;
>
> void bar(FooPtr);
>
> void bar(FOO *x) {
> x->i++;
> }
>
> int main() {
Dan Sugalski:
# At 10:43 PM -0500 2/23/02, Josh Wilmes wrote:
# >So indent needs to be told about non-standard type
# (typedefs) to work best.
# >The problem is that some of the parrot code does this:
# >
# >#define CHARTYPE struct parrot_chartype_t
# >#define ENCODING struct parrot_encoding_t
# >
The problem, as I understand it, is that you end up with two names for the
same underlying type, but you can't convert between them without a cast.
Which sort of defeats the reason for these "shortcut names".
--Josh
At 22:47 on 02/23/2002 EST, Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 10:
At 10:43 PM -0500 2/23/02, Josh Wilmes wrote:
>So indent needs to be told about non-standard type (typedefs) to work best.
>The problem is that some of the parrot code does this:
>
>#define CHARTYPE struct parrot_chartype_t
>#define ENCODING struct parrot_encoding_t
>#define STRING struct parrot_s
23 matches
Mail list logo
