Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature/48 as operator #15

Merged
merged 17 commits into from
Nov 20, 2017
Merged

Feature/48 as operator #15

merged 17 commits into from
Nov 20, 2017

Conversation

ppaulweber
Copy link
Member

@@ -55,8 +55,8 @@ rule foo =
let b : Bit'16 = 0 in
let c = a or b in
{
assert( c = asBit( 0, 16 ))

assert( c = 0 as Bit'16 )
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks much better :D

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree 😄

rule foo =
{
let x : Integer = undef in assert( x as Boolean = undef )
let x : Integer = -123 in assert( x as Boolean = false )
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

x != 0 -> true

{
let x : Integer = undef in assert( x as Boolean = undef )
let x : Integer = -123 in assert( x as Boolean = false )
let x : Integer = -1 in assert( x as Boolean = false )
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

x != 0 -> true

rule foo =
{
let x : Tuple< Integer, Integer > = [ 1, 10 ] in
assert( x as Boolean = 0 ) //@ ERROR( 1700 )
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

0 -> false

let x : Integer = -1 in assert( x as Bit = 0b0 )
let x : Integer = 0 in assert( x as Bit = 0b0 )
let x : Integer = 1 in assert( x as Bit = 0b1 )
let x : Integer = 42 in assert( x as Bit = 0b1 )
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

42 as Bit = 0b1 looks strange

I would expect that this gives a bit-field with the min. number of bits to represent this number.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In this case you have not misunderstood the Bit type, the Bit is a abbreviation for Bit'1, which means a bit-vector of size 1. The conversion from Integer to Bit'{n} is defined as follows: If the content of the Integer can fit into the Bit'n type of bit-size n then the value gets encoded properly, otherwise the conversion shall return a undef. You are definitely right that there is a mistake in the unit test ... I'll fix this ASAP!

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FIXED

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From a user's point of view I would expect what I already mentioned above: A missing '{n} means that (if the type system is consistent) the type inference calculates the size automatically because Bit looks like a "partial" type here. Other languages handle it the same way, e.g. in Java List<> = ... where the actual list item type is inferred.

I.e. currently there are two different meanings for a single type name. Bit stands for a single bit while Bit'{n} stands for a bit vector of size n.

I see two possibilities to make it consistent:

  • Drop Bit in favor of Bit'1
  • Rename Bit'{n} to e.g. BitVector'{n} and add an alias Bit = BitVector'1

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I hope you remember that I warned you about the Bit and Bit'1 problematic about a year ago, right? In this case I would say we drop the Bit in favor for the Bit'1, because I do not want to introduce a camel case type.

PR is coming soon, see issue: sealangdotorg/sea#54


let x : Integer = undef in assert( x as Bit'8 = undef )
let x : Integer = -24 in assert( x as Bit'8 = 0b0 )
let x : Integer = -1 in assert( x as Bit'8 = 0b0 )
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should be 0b11111111

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FIXED

let x : Integer = 42 in assert( x as Bit'1 = 0b1 )

let x : Integer = undef in assert( x as Bit'8 = undef )
let x : Integer = -24 in assert( x as Bit'8 = 0b0 )
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should be 0b11101000

Two's complement -> Same for all other negative numbers

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FIXED

let x : Tuple< Integer, Integer > = [ 1, 10 ] in
assert( x as Bit'8 = 0b0 ) //@ ERROR( 1700 )

let x : Tuple< Integer, Integer > = [ 1, 10 ] in
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

General remark (for future): 1 representative test case is enough, duplicated test cases make the whole thing harder to change/maintain ;)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe ... maybe not, I think we can not be sure enough to test several cases.

let x : Decimal = 0.0 in assert( x as Bit'23 = 0b0 )
let x : Decimal = 1.1 in assert( x as Bit'23 = 0b1 )
let x : Decimal = 42.42 in assert( x as Bit'23 = 0b101010 )
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm the whole Decimal to Bit conversion isn't well-defined in my opinion.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The current approach of the type casting from Decimal to Bit'{n} is that only the Integer part gets translated to a proper bit-vector representation.

@@ -45,6 +45,5 @@ CASM init foo

rule foo =
{
println( undef + asBit( 0, 10 ) )

println( undef + 0 as Bit'10 )
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This and the following print test cases are useless, they all tests the same -> println(undef : Bit)

undef + something is already covered by expression tests.

This should be cleaned up in another PR please ;)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm aware of the print test case problematic, there will be a major clean-up PR really soon, the change here is required due to the enforcement of the <expr> as <type> syntax for type castings instead of the as<type>() built-in calls

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ppaulweber
Copy link
Member Author

@emmanuel099 please review

Copy link
Member

@emmanuel099 emmanuel099 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice work!

@emmanuel099 emmanuel099 merged commit d0753ad into master Nov 20, 2017
@emmanuel099 emmanuel099 deleted the feature/48_as_operator branch November 20, 2017 21:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants