No out bit parameters: I can work
around this, but I was curious about
the reason. Is it just technical?

I like to have certain functions
return a bit value for success or
failure, and use an out parameter
to return results.

bit someFunc(out char[] result)
but
bit someFunc(out bit result)
isn't allowed.

Frank Wills wrote:
> No out bit parameters: I can work
> around this, but I was curious about
> the reason. Is it just technical?

I believe it is because a pointer to bit has not been implemented yet, which would need an adress, as well as an offset within a byte.

Obviusly, it is not requiered for an out parameter...

Walter: how about allowing pointer to bit in an abridged form? It can currently be a simple byte pointer, which you get when taking adress of a bit, but when the bit is not lowest within a byte, it should raise an exception, signalling that it's not implemented yet.

-i.

Actually, my workaround is to use a pointer
to a bit as the parameter, which works fine.

Ilya Minkov wrote:
> Frank Wills wrote:
> 
>> No out bit parameters: I can work
>> around this, but I was curious about
>> the reason. Is it just technical?
> 
> 
> I believe it is because a pointer to bit has not been implemented yet, which would need an adress, as well as an offset within a byte.
> 
> Obviusly, it is not requiered for an out parameter...
> 
> Walter: how about allowing pointer to bit in an abridged form? It can currently be a simple byte pointer, which you get when taking adress of a bit, but when the bit is not lowest within a byte, it should raise an exception, signalling that it's not implemented yet.
> 
> -i.
> 

"Ilya Minkov" <midiclub@8ung.at> wrote in message news:bgjbv6$2ll9$1@digitaldaemon.com...
> Walter: how about allowing pointer to bit in an abridged form? It can currently be a simple byte pointer, which you get when taking adress of a bit, but when the bit is not lowest within a byte, it should raise an exception, signalling that it's not implemented yet.

Yes, that is a good idea.

Ilya Minkov wrote:
> Frank Wills wrote:
> 
>> No out bit parameters: I can work
>> around this, but I was curious about
>> the reason. Is it just technical?
> 
> 
> I believe it is because a pointer to bit has not been implemented yet, which would need an adress, as well as an offset within a byte.
> 
> Obviusly, it is not requiered for an out parameter...
> 

Why do you say "obviously" it is not required as an out
parameter? I don't see anything "obvious" about what
you say at all.

> Walter: how about allowing pointer to bit in an abridged form? It can currently be a simple byte pointer, which you get when taking adress of a bit, but when the bit is not lowest within a byte, it should raise an exception, signalling that it's not implemented yet.
> 
> -i.
> 

Walter wrote:
> "Ilya Minkov" <midiclub@8ung.at> wrote in message
> news:bgjbv6$2ll9$1@digitaldaemon.com...
> 
>>Walter: how about allowing pointer to bit in an abridged form? It can
>>currently be a simple byte pointer, which you get when taking adress of
>>a bit, but when the bit is not lowest within a byte, it should raise an
>>exception, signalling that it's not implemented yet.
> 
> 
> Yes, that is a good idea.
> 
> 
Walter, any chance you will answer my question, or
is the answer too "obvious" to answer?

"Frank Wills" <fdwills@sandarh.com> wrote in message news:bgjlhl$2ts2$1@digitaldaemon.com...
> Walter wrote:
> > "Ilya Minkov" <midiclub@8ung.at> wrote in message news:bgjbv6$2ll9$1@digitaldaemon.com...
> >>Walter: how about allowing pointer to bit in an abridged form? It can currently be a simple byte pointer, which you get when taking adress of a bit, but when the bit is not lowest within a byte, it should raise an exception, signalling that it's not implemented yet.
> > Yes, that is a good idea.
> Walter, any chance you will answer my question, or
> is the answer too "obvious" to answer?

The trouble comes from the out parameter being one bit out of an array of bits. Then, a simple pointer will no longer suffice, it needs a pointer and a bit number. It's not impossible, just some more work to implement.

Walter wrote:
> 
> The trouble comes from the out parameter being one bit out of an array of
> bits. Then, a simple pointer will no longer suffice, it needs a pointer and
> a bit number. It's not impossible, just some more work to implement.
> 

Ok, thanks. I was just curious as to why it was that way, and also
trying to help by providing feedback. I don't know if you intended
bit pointers to be used, or to work at this point, but they do,
and that is what I am using until the bit type is usable with an
out parameter, which is more elegant to use that pointers.

which bit is the bit ?
consider;
void func( out bit rv, int i ) { ... }
void meth() {
    bit a,b, c;
    func(a, 0 );func(b, 3 );func(c, 6 );
}
a,b,c might be bits 0,1,2 of the first stack word
shift and mask to the in is always bit0 is o.k.
but you either have to pass the ptr to the storage word/dword and the
position to save to
or have copy on return (which might mess up some code).
I believe there is no bit*
which would be struct ( int pos, int * storePtr; } similar to array.

"Frank Wills" <fdwills@sandarh.com> wrote in message news:bgiv3n$2ati$1@digitaldaemon.com...
> No out bit parameters: I can work
> around this, but I was curious about
> the reason. Is it just technical?
>
> I like to have certain functions
> return a bit value for success or
> failure, and use an out parameter
> to return results.
>
> bit someFunc(out char[] result)
> but
> bit someFunc(out bit result)
> isn't allowed.
>

Mike,

Sure, sure, yes, yes, I imagine that most
people on this list understand everything you
are explaining, and the issues involved
(who on this list doesn't know what a bit is,
and that it is a part of a larger addressable
unit in memory?)

I just wanted to know (from Walter):
 1) Why "out" isn't currently implemented for
bit parameters.
 1 - Walter's answer) It sounds like it will or
could be, if and when he gets to it. And that
there's just more work to implementing the bit
type in various manners. Obviously there are
no 'bit' addressable memory units in memory,
it must be 'extracted' from larger units (I'm
not telling anyone anything new here am I?)

 2) Bit pointers __do__ currently work. Does
Walter __intend__ for them to work, or are
they just happening to work.
 2 - Walter's answer) It sounds like he may
do something to better refine the use of
bit pointers. I don't yet know if he intended
for them to work at this point at all.

Mike Wynn wrote:
> which bit is the bit ?
> consider;
> void func( out bit rv, int i ) { ... }
> void meth() {
>     bit a,b, c;
>     func(a, 0 );func(b, 3 );func(c, 6 );
> }
> a,b,c might be bits 0,1,2 of the first stack word
> shift and mask to the in is always bit0 is o.k.
> but you either have to pass the ptr to the storage word/dword and the
> position to save to
> or have copy on return (which might mess up some code).
> I believe there is no bit*
> which would be struct ( int pos, int * storePtr; } similar to array.
> 
> "Frank Wills" <fdwills@sandarh.com> wrote in message
> news:bgiv3n$2ati$1@digitaldaemon.com...
> 
>>No out bit parameters: I can work
>>around this, but I was curious about
>>the reason. Is it just technical?
>>
>>I like to have certain functions
>>return a bit value for success or
>>failure, and use an out parameter
>>to return results.
>>
>>bit someFunc(out char[] result)
>>but
>>bit someFunc(out bit result)
>>isn't allowed.
>>
> 
> 
>