On 2015/07/01 17:47:23, rossberg wrote:
On 2015/07/01 12:16:57, bradn wrote:
> Some other type system questions:
>
> * Should Function(R, S, T0, T1...) types be unionable with each other?
(I.e.
can
> I use them to express the overloaded nature of Math.abs etc?) Some care
will
be
> required at a VisitCall to disentangle which concrete version is
relevant.
Overloading is intersection, not union. In some cases, this can be
converted
to
union on the argument types (using distributivity over the functional
implication), but not in general. In particular, there is no way to
represent
the overloading of Math.abs,
(int -> int) /\ (double -> double)
with union only.
Unfortunately, our type system cannot represent arbitrary intersections.
(It
is
a well-known result in type theory that adding both union + intersection
types
to a type system leads to combinatorial explosion that you want to avoid
at
all
cost.)
So function types themselves can be unioned, but that isn't what you
want, and
not very useful. For all cases but Math.abs that occur in asm.js you can
get
away with unioning the arguments, though. I'd simply try to handle
Math.abs as
a
special case (like asm already does for operators).
> UnionType seems to be considered an implementation internal. Would
adding a
way
> to iterate over union members be ok?
No, that's intentionally not provided (other than the iteration over
classes
and
constants, which is already kind of fishy). Because of the above, it
probably
wouldn't help you either.
> * Should a function like fround ( Undefined \/ float32 \/ float64 ->
float32)
> work as expected?
I think so, although I'm not entirely sure what you mean by "as
expected". :)
> * Should Arrays of a single Function type work correctly?
Yes. All the types should be fully compositional.
> * Any recommendations on how to represent an ArrayBuffer? I may be able
to
avoid
> this one, though, as the spec does not seem to permit variables of this
type
> other than the module parameter, so I could special case it.
Until recently there actually was a (bitset) type for that, but we
removed it
because of bit pressure.
If you can get away without for now, that would be easiest. We still have
to
solve the bit issue mid-term, however.
> * I think ArrayBuffer might not need to be expressed, but in general is
there
> some way I've missed to express a sentinel type (i.e. something that
won't
> quietly slip by union/intersect but can be checked for explicitly?)
The easiest is a bit, which we don't have. :) Other than that, we probably
want
to add a structural type for Sentinels in the future.
In some cases you might get away with creating a sentinel Class over some
dummy
map for the time being (or a dummy Constant). Depends on what you need to
express. What else besides ArrayBuffer?
> * I want to double check using the types.h types makes sense for asm
> validation/typing?
>
> Before you'd pointed me at your CL I'd been going down the road of a
type
system
> local to asm validation, mirroring the typing rules and types (intish
etc)
in
> the asm.js spec. I had figured on converting to types.h types as each
ast
node
> is visited, since with asm, at each step concrete types are known, and
type
> unions less critical.
>
> So far it seems like using types.h allows for a safe superset of
asm.js, and
> does seem to be a good deal more concise than where adding another type
system
> was going.
Yes, I'd strongly prefer using the existing types. Especially since you'll
probably need to forward them to the Turbofan backend in some form anyway.
Most
of what you are missing from the types currently is needed elsewhere as
well,
so
we strongly want to resolve it. (We are currently discussing e.g. the bit
issue.)
Is this issue now obsolete with our validator?
https://codereview.chromium.org/1217803004/
--
--
v8-dev mailing list
v8-dev@googlegroups.com
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to v8-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
