> This is a bug. It should know that `M\ array like` returns an array. (Why
> it's unable to infer that from the definition isn't immediately obvious to
> me—from the definition of `M\ array like` it seems to me it ought to.)
> Monkey-patching an `{ array } declare` onto the end of the method makes it
> optimize as you'd expect.
Using compiler.tree.debugger to check out the type propagation,
[ "" like ] cleaned-up-tree .
indeed infers an output type of `string`, while
[ { } like ] cleaned-up-tree .
infers an output type of `object`. Checking out the definitions of both
`like`
methods, I tried looking at
[ >array ] cleaned-up-tree .
vs
[ >string ] cleaned-up-tree .
and noticed the same types being inferred (object vs string). So, looking
at the definitions,
IN: scratchpad \ >array see
USING: sequences ;
IN: arrays
: >array ( seq -- array ) { } clone-like ;
IN: scratchpad \ >string see
USING: sequences ;
IN: strings
: >string ( seq -- str ) "" clone-like ; inline
we notice that >array isn't inlined, while >string is. So perhaps the type
information of >array isn't getting propagated because it's not inlined?
--Alex Vondrak
------------------------------------------------------------------------------
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
