>>> "Valentin" == Valentin David <valentin.david(a)gmail.com> writes:
> On 9/20/05, Akim Demaille <akim(a)lrde.epita.fr> wrote:
>> Je trouve que c'est une erreur d'avoir autant de paquets dans notre
>> arbre. C'est une contrainte, quelque chose qui nuit à la
>> productivité. Si un jour il faut rendre un paquet autonome, ce serait
>> facile de l'arnacher, mais entre temps, je propose la suppression de
>> tous les configure.ac intermédiaires. Seul le bundle compte.
> Why changing something that works? It was long to set, but now it does
> not need so much maintaining. It is good to have a build farm that
> check each packages, reading the logs is easier.
I'm sorry, but it is not my view that it is working: with Alexandre we
lost almost 1 man-day because the C grammar he thought he was using
(the one in the src tree) was not the one that was used (the last one
to be installed). In addition it is common knowledge that the
Autotools are *very* costly to run: any improvement of the working
cycle in the Tfers project is an healthy move.
I might agree for the removal of *some* indirections instead of all of
them, but as is as of today, it is ridiculous --- you can't justify so
many packages.
I propose 3 sub packages:
- StrategoXTensions
boxedsdf
esdf
sdf-astgen
sdf-attribute
sdf-detgen
sdf-option
str-lazy
- C Grammars
c-condition
c-grammar
- C++ Grammars
cxx-basic
cxx-grammar
specs-grammar
I'm reading the module prepost, and there are a few issues I would
like to raise.
Disclaimer: I have never programmed in Stratego, the code is most
certainly wrong.
1. The complete file
====================
For reference.
imports
liblib
ContractC
strategies
SearchFunDecl = alltd({
?|InitDeclarator[ ~Declarator: <id>~ ]| ; debug
; oncetd(?|DirectDeclarator[ ~ID: fun_name~ ]|)
; oncetd(
?|DirectDeclarator[
DirectDeclarator(ParameterTypeList)
PreCondition-opt
PostCondition-opt ]|
; !PreCondition-opt
; if ?|PreCondition?[ ]| then
!|Statement[ ; ]| => pre
else
?|PreCondition?[
precondition { ~Assertion+: pre~ } ]|
end
; !PostCondition-opt
; if ?|PostCondition?[ ]| then
!|Statement[ ; ]| => post
; !|ReturnValueDeclaration?[ ]| => ret
else
?|PostCondition?[
postcondition ~ReturnValueDeclaration?: ret~
{ ~Assertion+: post~ } ]|
end
; !|DirectDeclarator[
DirectDeclarator(ParameterTypeList) ]|)
; rules (PrePost : fun_name -> (pre, ret, post))
})
SearchFunDef = alltd({
?|ExternalDeclaration[ ~FunctionDefinition: <id> ~ ]|
; oncetd(?|DirectDeclarator[ ~ID: fun_name ~ ]|
; where(<PrePost> fun_name => (pre, ret, post))
; oncetd(?|BlockItemList[ BlockItem-iter ]|
; !|BlockItemList[ ~BlockItem+:
<concat> [
[|BlockItem[ ~CompoundStatement: pre ~ ]|,
|BlockItem[ ~CompoundStatement: post ~ ]|],
BlockItem-iter
]~]|
))
})
prepost = io-wrap(SearchFunDecl ; SearchFunDef)
2. The strategies
=================
First of all, why the heck should the alltd be in the rules? And BTW,
why the rules are strategies here? As a first improvement, I propose
to move the alltd down to the prepost strategy.
prepost = io-wrap(alltd (FunDecl) ; alltd (FunDef))
Then you see that there are two alltd. Although this allows to have
declarations after the implementation (which is indeed a feature) it
goes against the spirit of C. Therefore it should read
prepost = io-wrap(alltd (FunDecl ; FunDef))
Also, *save the space*! What is this fashion of starting to implement
immediately after `='?
FunDecl =
{
?|InitDeclarator[ ~Declarator: <id>~ ]| ; debug
; oncetd(?|DirectDeclarator[ ~ID: fun_name~ ]|)
; oncetd(
?|DirectDeclarator[
DirectDeclarator(ParameterTypeList)
PreCondition-opt
PostCondition-opt ]|
; !PreCondition-opt
; if ?|PreCondition?[ ]| then
!|Statement[ ; ]| => pre
else
?|PreCondition?[
precondition { ~Assertion+: pre~ } ]|
end
; !PostCondition-opt
; if ?|PostCondition?[ ]| then
!|Statement[ ; ]| => post
; !|ReturnValueDeclaration?[ ]| => ret
else
?|PostCondition?[
postcondition ~ReturnValueDeclaration?: ret~
{ ~Assertion+: post~ } ]|
end
; !|DirectDeclarator[
DirectDeclarator(ParameterTypeList) ]|)
; rules (PrePost : fun_name -> (pre, ret, post))
}
FunDef =
{
?|ExternalDeclaration[ ~FunctionDefinition: <id> ~ ]|
; oncetd(?|DirectDeclarator[ ~ID: fun_name ~ ]|
; where(<PrePost> fun_name => (pre, ret, post))
; oncetd(?|BlockItemList[ BlockItem-iter ]|
; !|BlockItemList[ ~BlockItem+:
<concat> [
[|BlockItem[ ~CompoundStatement: pre ~ ]|,
|BlockItem[ ~CompoundStatement: post ~ ]|],
BlockItem-iter
]~]|
))
}
3. The rules
============
The rules exist, and that's because they make sense. Why just making
strategies? I know, they are equivalent, but so are for and while
loops, and you do use both.
What is the InitDeclarator that we start by matching? Apparently it
is only for debugging, but that's cluttering the code. What are all
these oncetd doing here? This is *so wrong*: the code is trying to
match various piece instead of just matching what it's looking for.
IMNSHO it should look like:
FunDecl =
? |Declarator[fn (arg*) pre post]|
; rules (PrePost : fn -> (cs1*, i, cs2*))
where <?|[precondition { cs1* }]|> (pre);
<?|[postcondition (i) { cs2* }]|> (post)
Is there a nicer way to match pre*, ret and post*? And we'll see for
the function with either a pre- xor a postcondition later...
The other rule/strategy is also quite not understandable!
What is to be done is to create a dynamic rule *that performs the
replacement*!!! Not some pseudo table, which completely defeats the
whole point of dynamic rules.
We want to write something like:
where
When you put the two together, you have:
FunDecl =
? |Declarator[fn (arg*) pre post]|
; rules (InstallContract :
|FunctionDefinition[fn (arg*) { stm* }] => !|[fn (arg*) { stm'* }]
where <?|[precondition { cs1* }]|> (pre);
<?|[postcondition (i) { cs2* }]|> (post);
<install-contract (cs1*, i, cs2*)> (stm) => stm'*)
And for an experimental start, I propose
install-contract (|cs1*, i, cs2*) =
!|[ { cs1* } ~id { cs2*} ]|
We will see the complications later.
I would like to have detailed answers, and particularly from Jesus.
I'm quite sure my code is wrong, but it is probably close to correct,
my Stratego is far from fluent.
Hi,
I did not understand some behaviors of Gcc. Gcc accepts this:
-->8--
class A {};
class B {};
A B;
-->8--
I found nothing in the standard that says it is not valid. Ok.
According to the standard this one is valid, and Gcc accepts it:
-->8--
typedef int T;
typedef int T;
-->8--
It does not accept this one:
-->8--
typedef int T;
T T;
-->8--
That is ok, T is a typedef-name.
But on this one, it fails:
-->8--
class A {};
typedef A T;
T T;
-->8--
But normally, T is class-name.
And the same on this one:
-->8--
typedef class {} A;
A A;
-->8--
But here, A is not only a class-name, it is *THE* real name of the class.
I do not understand why Gcc does not accept these two last examples. I
did not find it in the standard. If someone find it somewhere...
--
Valentin David
valentin.david(a)gmail.com
On dit du sucre syntaxique, pas un sucre. Ça ne se compte pas du
sucre syntaxique, et surtout pas en anglais. Donc, svp, plus jamais
de « syntactic sugars », « we want to add a sugar » etc.
Hi guys,
First, thanks again for visiting the SUD. It was very interesting to
learn more about what you are doing :) .
Could you please send me your slides so that I can add them to the program?
Cheers,
--
Martin Bravenboer
---------------------------------------------------------------------
Center for Software Technology
Institute of Information and Computing Sciences
Utrecht University
"StOck Watch A|ert" this morning are Wysak Petroleum (WYSK), Key
Energy Services, Inc. (Pink Sheets: KEGS), Medify So|utions (MFYS),
Sequoia Interests Corporation (SQNC).
Wysak Petroleum (WYSK)
Current Price: O.18
Wysak Petroleum announces the signing of a Letter of Intent with the European
Commission Ba|tic Renewable Energy Centre (EC BREC) to assist Wysak Petro|eum in
the deve|opment of the Wysak Wind Power Project.
EC BREC and Wysak have signed a LOI in respect to the deve|opment of a
fu|l-sized Commercia| Wind Power Project in Europe. This |etter states that EC
BREC can support Wysak in matters such as financial structuring and investment,
regu|atory issues, government po|icies, negotiations, wind techno|ogies, and
other aspects relating to Wind Power.
About the Wysak Wind Project
This development wil| be up to a maximum 9OMw in size and cost upwards of $12O
mi|liOn in deve|opment expenditures. Once comp|eted, this Wind Park will supply
upwards of 170,OOO Mw of e|ectricity annua|ly for Po|and and the European
Community. This is enough green energy to supply upwards of 25,OOO homes with
electricity and offset near|y 170,O0O tonnes of Greenhouse gases. Tota| gross
e|ectric sales over a 2O-year period are estimated at over $450 milli0n for a
project this size.
About the EC Baltic Renewab|e Energy Centre
The mission of European Commission-founded EC BREC is to stimulate the
development of renewable energy sources (RES) in Po|and through the construction
of RES projects, the deve|opment of innovative technologies, and the creation of
re|evant po|icies, strategies and plans. To fu|fi|l the mission, EC BREC uses
its own research capabi|ities and cooperates with partner institutions from the
EU, other countries, and internationa| organizations.
About Wysak Petroleum
Wysak is a diversified energy company whose goal is to identify and deve|op
traditional fossil fuel sites, as we|l as clean air alternative energy producing
techno|ogies. Wysak controls one Wyoming Federal oi| & gas lease in the Bighorn
Basin region and another in the Green River Basin. Its two Wyoming State leases
are |ocated 45 miles apart within the massive Coa|Bed Methane p|ay area of the
Powder River Basin. Numerous |arge petroleum and exploration firms operate near
to al| of these properties; they inc|ude ExxonMobile (XOM), Wi|liams Gas (WMB),
and Western Gas (WGR) among others. Collective|y, over 26,00O wells produced
54.7 mi||ion barre|s of oil and 1.75 trillion cubic feet of natura| gas in
Wyoming
Conclusion:
The Examples Above Show The Awesome, Earning Potential of Little Known Companies
That Exp|ode Onto Investor's Radar Screens; Many of You Are Already Fami|iar with This.
Is WYSK Poised and Positioned to Do that For You?
Then You May Fee| the Time Has Come to Act... And Please Watch this One Trade Monday!
Go WYSK.
Penny StOcks are considered highly speculative and may be unsuitab|e for a|| but
very aggressive investors. This Profi|e is not in any way affi|iated with the
featured company.We were compensated 30O0 dol|ars to distribute this report.
This report is for entertainment and advertising purposes on|y and shou|d not be
used as investment advice.
If you wish to stop future mai|ings, or if you fee| you have been
wrongful|y p|aced in our membership, please go here or send a blank
e mail with No Thanks in the subject to st0ck1010 @ yahoo.com
