Eclipse Community Forums: B3 » some issues solved

Help

Home

Home » Archived » B3 » some issues solved

Show: Today's Messages :: Show Polls :: Message Navigator

some issues solved [message #493337]

Sat, 24 October 2009 23:58

Henrik Lindberg

Messages: 2509
Registered: July 2009

Senior Member

Hi,
- I managed to get the label: statement working without the prefix.
- Switch now support expressions in cases (as opposed to only literal
values as before).

These two were made possible after turning on backtracking to make the
generator work without warning on if-then-else ambiguity (where the
default decision to associate else with the innermost if was correct,
but still annoying to see the warnings).

- The "in" ambiguity is much worse. I decided to rename the exotic "==."
operator to "isin" as it reminds of the original "in" operator.

- I removed the void expression - it simply has no place in regular
scripting.

- I added 'undefined' as "sibling" to 'null'. This to make it possible
to verify that assignment to 'undefined' is never done (which is legal
in JS, but not something you want to do - it is like stating that 1 = 2;
changing the value of the symbol 1 to the int value of 2 - well just a
strange anyway).

- henrik

Report message to a moderator

Re: some issues solved [message #493355 is a reply to message #493337]

Sun, 25 October 2009 06:37

Eike Stepper

Messages: 6682
Registered: July 2009

Senior Member

Hi Henrik,

I did not follow the whole "in" issue, but in case it's supposed to mean
something like "element in set" as a boolean expression, what about
generalizing it to something like "set1 isSubSetOf set2" and use the
normal "<" operator for it? Generalizing even more, "<=", ">", ">=",
"==" and "!=" could also be meaningful in terms of set algebra. But
maybe I completely missed the point :P

Cheers
/Eike

----
http://thegordian.blogspot.com
http://twitter.com/eikestepper

Henrik Lindberg schrieb:
> Hi,
> - I managed to get the label: statement working without the prefix.
> - Switch now support expressions in cases (as opposed to only literal
> values as before).
>
> These two were made possible after turning on backtracking to make the
> generator work without warning on if-then-else ambiguity (where the
> default decision to associate else with the innermost if was correct,
> but still annoying to see the warnings).
>
> - The "in" ambiguity is much worse. I decided to rename the exotic
> "==." operator to "isin" as it reminds of the original "in" operator.
>
> - I removed the void expression - it simply has no place in regular
> scripting.
>
> - I added 'undefined' as "sibling" to 'null'. This to make it possible
> to verify that assignment to 'undefined' is never done (which is legal
> in JS, but not something you want to do - it is like stating that 1 =
> 2; changing the value of the symbol 1 to the int value of 2 - well
> just a strange anyway).
>
> - henrik
>

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper

Report message to a moderator

Re: some issues solved [message #493356 is a reply to message #493355]

Sun, 25 October 2009 06:41

Eike Stepper

Messages: 6682
Registered: July 2009

Senior Member

One more idea:

If there was a kind of "auto boxing or unboxing" for singleton sets and
their single elements, one could write the following:

if (set1 >= elem)

instead of

if (set1 >= set(elem))

meaning "is elem in set1?"

Cheers
/Eike

----
http://thegordian.blogspot.com
http://twitter.com/eikestepper

Eike Stepper schrieb:
> Hi Henrik,
>
> I did not follow the whole "in" issue, but in case it's supposed to mean
> something like "element in set" as a boolean expression, what about
> generalizing it to something like "set1 isSubSetOf set2" and use the
> normal "<" operator for it? Generalizing even more, "<=", ">", ">=",
> "==" and "!=" could also be meaningful in terms of set algebra. But
> maybe I completely missed the point :P
>
> Cheers
> /Eike
>
> ----
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
>
>
>
> Henrik Lindberg schrieb:
>
>> Hi,
>> - I managed to get the label: statement working without the prefix.
>> - Switch now support expressions in cases (as opposed to only literal
>> values as before).
>>
>> These two were made possible after turning on backtracking to make the
>> generator work without warning on if-then-else ambiguity (where the
>> default decision to associate else with the innermost if was correct,
>> but still annoying to see the warnings).
>>
>> - The "in" ambiguity is much worse. I decided to rename the exotic
>> "==." operator to "isin" as it reminds of the original "in" operator.
>>
>> - I removed the void expression - it simply has no place in regular
>> scripting.
>>
>> - I added 'undefined' as "sibling" to 'null'. This to make it possible
>> to verify that assignment to 'undefined' is never done (which is legal
>> in JS, but not something you want to do - it is like stating that 1 =
>> 2; changing the value of the symbol 1 to the int value of 2 - well
>> just a strange anyway).
>>
>> - henrik
>>
>>

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper

Report message to a moderator

Re: some issues solved [message #493377 is a reply to message #493356]

Sun, 25 October 2009 14:34

Henrik Lindberg

Messages: 2509
Registered: July 2009

Senior Member

Hi, the "in" operator is supposed to perform the equivalence of the
following :

set(aName).isSubSetOf( object.getFeatureNamesAsSet() )

The idea is to generate the JS code for it dynamically, and it is
naturally helpful if the AST is already close to the intended target
language(s) - hence the search for just a different name for the "in"
operator (due to ambiguity).

I think algebra on sets is useful in b3, but it will be difficult to use
the standard operators like < since something can be viewed as both
comparable, and being a set at the same time.

Something I think is a really good idea is to support a literal query.
We already have a query syntax for advice, and we can generalize that to
select anything:

I propose that we do it like this:

Set(aName) <= theModel select ~{.:**[name=="fred"]}

This would mean, is aName a subset of a selection of features from the
model where any ancestor of theModel has a feature called "name" that
has the value "fred".

The JS "in" operation can be simplified from the above example and
written (although it results in a reference to the feature instead of a
boolean)

object select ~(aName}

I think this is a much more valuable and powerful mechanism than the JS
"in" operator.

- henrik

On 10/25/09 7:41 AM, Eike Stepper wrote:
> One more idea:
>
> If there was a kind of "auto boxing or unboxing" for singleton sets and
> their single elements, one could write the following:
>
> if (set1>= elem)
>
> instead of
>
> if (set1>= set(elem))
>
> meaning "is elem in set1?"
>
> Cheers
> /Eike
>
> ----
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
>
>
>
>
> Eike Stepper schrieb:
>> Hi Henrik,
>>
>> I did not follow the whole "in" issue, but in case it's supposed to mean
>> something like "element in set" as a boolean expression, what about
>> generalizing it to something like "set1 isSubSetOf set2" and use the
>> normal "<" operator for it? Generalizing even more,"<=", ">",">=",
>> "==" and "!=" could also be meaningful in terms of set algebra. But
>> maybe I completely missed the point :P
>>
>> Cheers
>> /Eike
>>
>> ----
>> http://thegordian.blogspot.com
>> http://twitter.com/eikestepper
>>
>>
>>
>> Henrik Lindberg schrieb:
>>
>>> Hi,
>>> - I managed to get the label: statement working without the prefix.
>>> - Switch now support expressions in cases (as opposed to only literal
>>> values as before).
>>>
>>> These two were made possible after turning on backtracking to make the
>>> generator work without warning on if-then-else ambiguity (where the
>>> default decision to associate else with the innermost if was correct,
>>> but still annoying to see the warnings).
>>>
>>> - The "in" ambiguity is much worse. I decided to rename the exotic
>>> "==." operator to "isin" as it reminds of the original "in" operator.
>>>
>>> - I removed the void expression - it simply has no place in regular
>>> scripting.
>>>
>>> - I added 'undefined' as "sibling" to 'null'. This to make it possible
>>> to verify that assignment to 'undefined' is never done (which is legal
>>> in JS, but not something you want to do - it is like stating that 1 =
>>> 2; changing the value of the symbol 1 to the int value of 2 - well
>>> just a strange anyway).
>>>
>>> - henrik
>>>
>>>

Report message to a moderator