[Swift-devel] print misbehavin'

[Mihael Hategan]

Actually that will break user defined procs, since they expect wrapped
values.
And the translation of + to sum() is also weird since it will break if
you have any wrapped values one either side.

I mean there are two choices here. There are swift values and non-swift
values. Using them with a plain karajan function requires them to be
unwrapped (vdl:getfieldvalue) and the result wrapped back with vdl:new.
Alternatively the function can be overriden to work on swift values.

And now that I see it, maybe some simple reduction would be useful.
parallel(3) is a useless alias for 3.

Mihael

On Fri, 2007-04-13 at 11:00 +0700, Ben Clifford wrote:
> On Thu, 12 Apr 2007, Mihael Hategan wrote:
> 
> > It translates fine though.
> > The issue is Swift data and their toString().
> 
> So, turns out that:
> 
> print(3) will not work, but
> 
> print(1+2) will work.
> 
> What happens is that '1' is a constant, which goes through a different 
> code path in Karajan.java to '1+2' which is an expression, generating 
> these two kml fragments:
> 
> 
>                    <print>
>                      <parallel>
>                        <vdl:new value="3"/>
>                      </parallel>
>                    </print>
> 
> 
> vs
> 
>                    <print>
>                      <parallel>
>                        <sum>
>                          <number>1</number>
>                          <number>2</number>
>                        </sum>
>                      </parallel>
>                    </print>
> 
> 
> So it seems that at least in the simple case, the vdl:new construct is 
> unnecessary for basic expressions. I tried removing the special handling 
> for constants in Karajan.java so that '3' goes through the same code path 
> as '1+2' and so print(3) turns into this code fragment instead:
> 
>                    <print>
>                      <parallel>
>                        <number>3</number>
>                      </parallel>
>                    </print>
> 
> 
> which successfully prints out 3. Hurrah!
> 
> I haven't really thought about if this is going to break other more 
> complicated stuff yet, so I'm not going to commit this patch yet. But I am 
> less frustrated than yesterday ;-)
>