Hi list,
after some experiments, I was surprised with how the optimizing compiler
could infer types. Not sure if all those behaviors are expected.. If anyone
has some explanations, that would be great.
Please see this paste for code: https://paste.factorcode.org/paste?id=2836
Here are my questions:
1) in bar1, "" like is enough to allow the compiler to infer type and
generate code using string-nth-fast and set-string-nth-fast instead of
nth-unsafe and set-nth-unsafe (just like using TYPED: in bar2); However, in
foo1, { } like is not enough (but TYPED: in foo2 works). Is this normal ?
2) in bar5, calling baz prevents the compiler from infering the type when
mapping, although it clearly outputs a string. Inlining it makes the
compiler infer again. But when the word you are calling before mapping is
from the library (for example reverse, which uses the pattern "[ X ] keep
like"), you can't inline it, so this prevents optimization of "pipeline"
code that can't change the type of the data (this would only apply to final
classes like strings or arrays, or else the output of like might be a
subclass).
Is there a doc on how the compiler infers types, and what to use (TYPED:,
like, HINTS:, etc) when inference fails ? On
http://docs.factorcode.org/content/article-hints.html, it says "The
compiler is capable of inferring enough static type information to generate
efficient code in many cases without explicit help from the programmer.",
which begs the question...
Cheers,
Jon
------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnmore_123012
_______________________________________________
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk
