I just worked out a new version attached to this posting. It contains several improvements, based on your suggestions.

I want to implement 2 features till its ready to use:

1. fileusage instead of parameter (or both, like your version)
2. handling of invalid cell-size like the original bf-interpreter did

I hope you all like this version ;)

Henning Hasemann wrote:
> On Thu, 24 May 2007 02:45:05 -0700
> janderson <askme@me.com> wrote:
> 
>> davidb wrote:
>> [snip]
>>> 5) line 62:
>>>    if "for (;;) ... " has only one statement(?), you don't need
>>>    enclosing {} (just cosmetics, but hey - 2 chars less typing *g*)
>>>    (or did you use it here as a means to show your intention
>>>     more clearly?)
>> [snip]
>>
>> I know this is mainly a style thing however I've seen many bugs caused by people who leave the scope brakes of the loop.
> 
> Ack, I also have only *very* few cases where I do not put brackets
> (also because I come from python so if I'm not concentrated I fear
> it might happen to me to rely on indentation)
> 
> Henning
> 

I've seen:
- People don't search-replace and removing a particular statement (it will then run the second line)
- People using them with macros (that haven't been properly scoped)
- People adding a statement that is really 2.
- People with a load of nested ifs, remove one and then the else statement relates to something else.
- Particularly in nested situations, people get the scope confused when writing the code and end up putting a statement in the wrong scope.

Its not that common, however these bugs can be a significant time sink when they occur.  I think its more time consuming to avoid putting them in.

Also, for me as a style thing its less typing to have brackets because they are auto generated as I type.  I can then easily expand the statement without having to go back and add {}.

janderson wrote:
> Henning Hasemann wrote:
>> On Thu, 24 May 2007 02:45:05 -0700
>> janderson <askme@me.com> wrote:
>>
>>> davidb wrote:
>>> [snip]
>>>> 5) line 62:
>>>>    if "for (;;) ... " has only one statement(?), you don't need
>>>>    enclosing {} (just cosmetics, but hey - 2 chars less typing *g*)
>>>>    (or did you use it here as a means to show your intention
>>>>     more clearly?)
>>> [snip]
>>>
>>> I know this is mainly a style thing however I've seen many bugs caused by people who leave the scope brakes of the loop.
>>
>> Ack, I also have only *very* few cases where I do not put brackets
>> (also because I come from python so if I'm not concentrated I fear
>> it might happen to me to rely on indentation)
>>
>> Henning
>>
> 
> I've seen:
> - People don't search-replace and removing a particular statement (it will then run the second line)
> - People using them with macros (that haven't been properly scoped)
> - People adding a statement that is really 2.
> - People with a load of nested ifs, remove one and then the else statement relates to something else.
> - Particularly in nested situations, people get the scope confused when writing the code and end up putting a statement in the wrong scope.
> 
> Its not that common, however these bugs can be a significant time sink when they occur.  I think its more time consuming to avoid putting them in.
> 
> Also, for me as a style thing its less typing to have brackets because they are auto generated as I type.  I can then easily expand the statement without having to go back and add {}.

I should add, that I'm not a style Nazi.  I was just trying to demonstrate the other side of the fence on this one.

-Joel

Don't worry about the line-buffering. That's very common behavior, and shouldn't break any interesting programs. People will NOT be surprised or disturbed if ,[.,] reads and outputs one line at a time.

Daniel Cristofani wrote:
> Don't worry about the line-buffering. That's very common behavior, and shouldn't
> break any interesting programs. People will NOT be surprised or disturbed if ,[.,]
> reads and outputs one line at a time.

Thats true, for sure.
My play instinct is forcing me to do it so, that it works at least on my own system.