Re: [Jolie-devel] Jolie 1.2 - Inline trees
A service-oriented programming language.
Brought to you by:
fmontesi
Menu
▾
▴
Re: [Jolie-devel] Jolie 1.2 - Inline trees
|
From: Claudio G. <cg...@it...> - 2015-03-14 19:33:47
|
I like the idea to have "," because it reminds me json objects even if
there are no ":". The semicolon is an operator for composing processes and
it is already a confusing operator because a lot of programmers think it is
an end line limitator like in Java. Thus I suggest to leave semicolon with
only one semantic.
It is true that also protocol definition should be addressed with inline
tree but I will kill you if you release a jolie version that is not
compatible with old jolie files.:)
The suggestion could be to add a custom production of inline tree for
protocols where both , and ; are accepted. We could write on the docs that
semicolons are deprecated and then in the future we could remove them.
Il 14/mar/2015 17:56 "Saverio Giallorenzo" <sav...@gm...>
ha scritto:
> I imagine case 1) as a representations of a static tree-like structure.
> The order it is "unfolded" when created does not change the final output.
> An example of it are XML structures (but not JSON, in JS you can write "var
> myJSON = { "a": i++, "b": i++, "c": i++ }", but JS is evil!).
>
> Right now the ITC is not a declaration but a procedure of creation of the
> structure. That is why IMHO ITC is a constrained version of 2)
> where we only support sequential composition of assignments, with the
> difference that instead of writing the composition with ";" we write ",".
>
> Plus, since we already allow assignments to accept aliases and variables
> in ITCs I do not see any easy application of static checks on this kind of
> structures.
> E.g., think of a variable used in the creation of the tree but also used
> by one or more parallel threads (globals, parallel composition, etc.). We
> cannot say anything
> on the content of that tree (damn, dynamic typing :P).
>
> Are we sure we want to avoid option 2)?
>
> P.S. I realised only now that the name I used previously is ICT but the
> acronym is Inline Tree Creation, my bad.
>
>
> On 14 March 2015 at 12:53, Fabrizio Montesi <fam...@gm...> wrote:
>
>> I see ict as different than with, in that with is just a preprocessing
>> construct, whereas ict is an expression (and hence has a runtime
>> semantics).
>>
>> I'm scared by having ict too general, it would probably make any static
>> analysis more complicated because we may have lots of side effects in an
>> ict. With, instead, is completely transparent because it is just a
>> preprocessor instruction so only the parser sees it.
>>
>> The current ict is neither option 1 or 2.
>>
>> You can assign generic expressions to subnodes so the order matters:
>>
>> x << { .x = i++, .y = i++ }
>>
>> I think in general we should allow also for nested deep copies and, very
>> important for writing efficient code, aliases: .x -> z
>>
>> Ideally ict will become powerful enough that we can use it for the
>> implementation of the protocol configuration block in communication ports
>> (which are now implemented as a with instead, IIRC).
>>
>> However that will cause problems because we're using the ; there as a
>> separator, so bye bye backward compatibility.
>>
>> My reasoning for not using ; as a separator for ict is that it may look
>> like somebody can write in there a generic code block, but that's not true.
>>
>> Not using any separator as in types may be the best solution, but it just
>> looks weird in code imho... :-/
>>
>> Or, maybe you guys can convince me of using ; ;-)
>>
>> This is very soft ground, so please continue sharing your thoughts. Once
>> the syntax is out for the first release of Jolie 1.2 I'd like it to be
>> stable.
>>
>> Sent from my phone.
>> On Mar 14, 2015 9:50 AM, "Saverio Giallorenzo" <
>> sav...@gm...> wrote:
>>
>>> I see your point. I think it depends on which kind of construct we want
>>> the inline tree creation (ICT) to be. I see two options:
>>>
>>> 1) ICT is used only to assign constant values. In this case it does not
>>> matter the order in which the assignments are computed as they are
>>> independent. That is the case to use commas "," or even nothing, like the
>>> syntax of types.
>>>
>>> 2) ICT is "with" on steroids. The result of its evaluation returns a
>>> tree but its body is a Jolie procedure, hence it can contain ";", "|" and
>>> input choices to compose statements in which ".any.path" is interpreted and
>>> evaluated in a similar way as "with". In that case we could have something
>>> like:
>>>
>>> animals << {
>>> .pet[ 0 ].name = "cat";
>>> getAnimal@PetShop()( .pet[ 1 ].name );
>>> {
>>> .wild[ i++ ].name = "tiger" |
>>> .wild[ i++ ].name = "lion"
>>> } // super-dangerous non-deterministic block :)
>>> }
>>>
>>>
>>> Personally, I find the second option intriguing, but I do not have a
>>> precise idea of the possibile havocs it might lead to (maybe none).
>>>
>>> What do you think about it?
>>>
>>> On 14 March 2015 at 09:17, Matthias Dieter Wallnöfer <
>>> mwa...@ya...> wrote:
>>>
>>>> We could also try to imitate "with", which requires the semicolons, but
>>>> its block content is also not limited to assignments.
>>>>
>>>> > with ( animals ){
>>>> > .pet[ 0 ].name = "cat";
>>>> > .pet[ 1 ].name = "dog";
>>>> > println@Console(.pet[0].name)();
>>>> > .wild[ 0 ].name = "tiger";
>>>> > .wild[ 1 ].name = "lion"
>>>> > }
>>>>
>>>> Saverio Giallorenzo schrieb:
>>>> > If I may toss an idea, what about making the syntax of inline trees as
>>>> > close al possible to that of type declaration?
>>>> >
>>>> > E.g., we have type
>>>> >
>>>> > type myType: string {
>>>> > .x[ 1, * ]: int
>>>> > .y[ 1, 3 ]: void {
>>>> > .value*: double
>>>> > .comment: string
>>>> > }
>>>> > }
>>>> >
>>>> > and we write
>>>> >
>>>> > myTree << "Root" {
>>>> > .x[0]=1
>>>> > .x[1]=2
>>>> > .y << {
>>>> > .value[0]=1.1
>>>> > .value[1]=2.1
>>>> > .value[2]=3.1
>>>> > .comment = "This is a comment"
>>>> > }
>>>> > }
>>>> >
>>>> > Granted a comma does not make such a big difference, as an user I
>>>> would
>>>> > wander why one syntax needs the comma and the other does not.
>>>> >
>>>> > BTW, should the deep-copy operator work inside inline trees or shall
>>>> we
>>>> > allow only assignments?
>>>> >
>>>> > Best,
>>>> > sg
>>>> >
>>>> >
>>>> > On 12 March 2015 at 10:10, Matthias Dieter Wallnöfer
>>>> > <mwa...@ya... <mailto:mwa...@ya...>> wrote:
>>>> >
>>>> > ";" is more about sequential execution for us, "," is our
>>>> delimiter
>>>> > (consider also "for") so I would stuck with ",".
>>>> >
>>>> > Matthias
>>>> >
>>>> >
>>>> > Fabrizio Montesi <fam...@gm... <mailto:fam...@gm...
>>>> >>
>>>> > schrieb am 9:30 Donnerstag, 12.März 2015:
>>>> >
>>>> >
>>>> >
>>>> > Hi all,
>>>> >
>>>> > Any ideas on my last comment in the e-mail (comma vs semi-colon)?
>>>> > I'd like some feedback on that particular syntax before making it
>>>> > official on the docs site.
>>>> >
>>>> > Even an "I like it" would make me feel better. Break the silence.
>>>> ;-)
>>>> >
>>>> > Cheers,
>>>> > Fabrizio
>>>> >
>>>> >
>>>> > On Sat, Mar 7, 2015 at 3:44 PM, Fabrizio Montesi
>>>> > <fam...@gm... <mailto:fam...@gm...>> wrote:
>>>> >
>>>> > Hi all,
>>>> > >
>>>> > >I committed a series of patches I had lingering around for a
>>>> while
>>>> > on inline trees.
>>>> > >
>>>> > >Now we can write stuff like this:
>>>> > >
>>>> > >a.left << "Left" { .x = 1, .y = 2, .y.left = "y_l", .y.right =
>>>> "y_r" };
>>>> > >
>>>> > >
>>>> > >valueToPrettyString@StringUtils( { .x = 1, .y = 2 } )( s );
>>>> > >
>>>> > >
>>>> > >
>>>> > >
>>>> > >This is obtained by introducing a new kind of expression
>>>> > (InlineTreeExpression) that takes a value for the root node and a
>>>> > series of assignments in between curly brackets { }.
>>>> > >
>>>> > >
>>>> > >You can thus write an inline tree wherever you can write an
>>>> expression.
>>>> > >
>>>> > >
>>>> > >Let me know what you think.
>>>> > >
>>>> > >
>>>> > >In particular, I tried to follow what they do in other language
>>>> by
>>>> > using the comma to separate assignments, but I'm not very happy
>>>> that
>>>> > it is inconsistent with what we do in protocol configurations
>>>> where
>>>> > we use ; instead.
>>>> > >
>>>> > >
>>>> > >Feedback is welcome.
>>>> > >
>>>> > >
>>>> > >Cheers,
>>>> > >Fabrizio
>>>> >
>>>> >
>>>> >
>>>> ------------------------------------------------------------------------------
>>>> > Dive into the World of Parallel Programming The Go Parallel
>>>> Website,
>>>> > sponsored
>>>> > by Intel and developed in partnership with Slashdot Media, is your
>>>> > hub for all
>>>> > things parallel software development, from weekly thought
>>>> leadership
>>>> > blogs to
>>>> > news, videos, case studies, tutorials and more. Take a look and
>>>> join the
>>>> > conversation now. http://goparallel.sourceforge.net/
>>>> >
>>>> > _______________________________________________
>>>> > Jolie-devel mailing list
>>>> > Jol...@li...
>>>> > <mailto:Jol...@li...>
>>>> > https://lists.sourceforge.net/lists/listinfo/jolie-devel
>>>> >
>>>> >
>>>> ------------------------------------------------------------------------------
>>>> > Dive into the World of Parallel Programming The Go Parallel
>>>> Website,
>>>> > sponsored
>>>> > by Intel and developed in partnership with Slashdot Media, is your
>>>> > hub for all
>>>> > things parallel software development, from weekly thought
>>>> leadership
>>>> > blogs to
>>>> > news, videos, case studies, tutorials and more. Take a look and
>>>> join the
>>>> > conversation now. http://goparallel.sourceforge.net/
>>>> > _______________________________________________
>>>> > Jolie-devel mailing list
>>>> > Jol...@li...
>>>> > <mailto:Jol...@li...>
>>>> > https://lists.sourceforge.net/lists/listinfo/jolie-devel
>>>> >
>>>> >
>>>>
>>>>
>>>
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for
> all
> things parallel software development, from weekly thought leadership blogs
> to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Jolie-devel mailing list
> Jol...@li...
> https://lists.sourceforge.net/lists/listinfo/jolie-devel
>
>
|