Object representation of #123

[Stepan Koltsov]

Hi,

I'm trying to fix issue

https://github.com/jckarter/clay/issues/494

(I need it fixed for another issue, but it is not important right now).

AFAIU, problem is that clay compiler has no Object representation of static object. There is no Object subclass that represents #123. Type of #123 can be represented as StaticType with ValueHolder holding 123. EValue for #123 uses StaticType and ignores addr field.

RecordType constructor takes type parameters as ArrayRef of ObjectPtr.

https://github.com/jckarter/clay/blob/cb0dadeeb467496c1a89c7caff758c7573f94a2c/compiler/types.cpp#L57

So it is not possible to pass #123 to RecordType constructor, because there is no Object for #123.

Am I correct?

What is a proper way to deal with the issue? I think, another ObjectKind, STATIC_VALUE (and StaticValue subclass of Object) should be added.

--
Stepan

[Joe Groff]

I think the fundamental problem you've been running into lately is that the semantics of #x are broken—Symbol and #Symbol are equivalent for a symbol, but 1 and #1 are not for a non-symbol value. I don't know how ambitious you want to get with fixing things for your application, but I think ultimately what needs to happen is that '#x' should become an "evaluate at compile-time" operator which gives a result of the original type instead of a Static[x] wrapper. Overload dispatch should then learn how to dispatch on compile-time EValues in addition to on types. Something like this:

  var x:Int = #(1 + 1); // Gives the value 2 of type Int, not Static[2]

  // Requires a compile-time value for an argument

  foo(#x:Int) {

    println(x);

  }

  [when x == 2]

  foo(#x:Int) {

    println("two");

  }

  foo(#1); // Prints 1

  foo(#2); // Prints "two"

This would make it so that the 'x == #x' identity holds consistently and would eliminate the awkwardness of unwrapStatic() and other operators necessary to do CTFE in Clay.

-Joe

[Stepan Koltsov]

So, the issue I created is an opposite of what should be done.

How compiler classes should be changed to implement new behavior?

I think, PVData may have one more field of tpye ObjectPtr. If ObjectPtr is not NULL, then value is known at compile time. StaticType is no longer created for #123, but instead analyzer fills ObjectPtr of PVData with .

lookupInvokeEntry should also have one more parameter, ArrayRef<ObjectPtr> that contains not-NULL value for each parameter known at compile time.

... and so on.

Right?

--
Stepan

[Joe Groff]

That sounds right—the analyzer and overload matching both need to consider static input values in addition to input types, so PValues need to be able to hold evaluation results, as does the 'argsKey' used in the invoke tables.

-Joe

--
You received this message because you are subscribed to the Google Groups "Clay Programming Language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clay-languag...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Stepan Koltsov]

On Wednesday, April 24, 2013 7:10:59 PM UTC+4, Joe Groff wrote:

You are proposing syntax:

>>> foo(x:Int) // matches 1 and #1
>>> foo(x) // matches 1, #1, true, #true, and #Int
>>> foo(#x:Int) // matches #1

so for symmetry

>>> foo(#x) // should match #1, #true and #Int

In this case we need new syntax to match #Int instead of current:

>>> foo(#Int)

that matches any static value in new syntax.

#Int matcher could be written as

>>> foo(#x:Static[Int])

but it is too verbose.


--
Stepan

[Joe Groff]

I think changing the syntax is a separable concern. The old syntax could work with the new semantics:

foo(#2) { ... } // Match the compile-time value 2

foo(#Int) { ... } // Match the compile-time value Int

[x] foo(#x) { ... } // Match any compile-time value x

With maybe a small extension to declare the types of the static variables:

[x:Int] foo(#x) { ... } // Match any compile-time value of type Int

-Joe

--