Hi Bruce,
There is one file with long procedures -- unigram.icn -- that is machine
generated and working on improving it makes no sense. For the rest of our
sources, one of the best reasons it is open source is so that everyone can
contribute improvements and fix bugs. You can of course go off and fork
your own language if you want :-) but most proposed improvements are
accepted gratefully. The main exception is backwards-compatibility, if you
need to "fix" a feature that would break many existing programs, that is
when I say you are welcome to make your own language. We are going to not
break existing programs, especially Icon programs, except in the rarest of
instances.
Having said all that, to answer your other questions: procedure and method
calls have a cost, but the overhead of calling subroutines is not a big
problem in most applications. If you see duplicate code that should be in
a subroutine, you are welcome to fix it, do appropriate testing, take
timing measurements, and submit changes for consideration. If you see long
chains of if's that would be better if they were a case statement, you are
welcome to fix it, do appropriate testing, and submit changes for
consideration. Case expressions are not optimized in Icon or Unicon but
they are generally just as fast as a chain of if statements, or faster.
Lastly, there might be some changes you make for your own sake, that I
might not see as improvements, and we don't really want to change things
just for change's sake. Breaking up a large procedure into smaller ones
involves a judgement call, and unless it makes the code smaller, or a lot
more readable, if it ain't broke, don't fix it. But if you can make the
code better, go for it. Your improvements will benefit others and are not
likely to get in anyone's way. If in doubt, you cal always ask about a
specific improvement you want to do. Private e-mail is probably best for
such conversations.
Cheers,
Clint
On Mon, Jul 30, 2012 at 5:43 AM, Bruce Rennie <[email protected]> wrote:
> This is particularly directed to Clint.
>
> I am currently going through the Unicon sources (under /uni) and I doing
> some clean up on the source files. I have noticed that some of the
> routines are very long. If I split out the code into separate procedures
> will this have any detrimental effect on the running of the icode files.
> Is the overhead of calling a routine much greater than just running
> through the code directly? i have noticed that there are areas that
> could benefit from a reduction in repeated code in increasing
> understanding of what the code is doing.
>
> In conjunction to trying to understand the thread structure, I am
> looking at doing my own personal extension to the Unicon model. This (in
> my own mind I am calling "polycon").
>
> But before embarking on this journey I am trying to understand the
> details of the Unicon compiler. With that in mind, I am in the process
> of trying to simplify some of the code, things like changing long nested
> if statements to case of statements, decreasing the size of the longer
> routines, changing some of the shorter routines to be more idiomatic etc.
>
> Is any of this going to be useful to others or should I keep this well
> out of the way of what you are doing? So as to not interfere with the
> directions that you are proceeding in.
>
> regards
> Bruce Rennie
>
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Unicon-group mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/unicon-group
