Takara-Tomy is closing preorders for this. Please order now to enjoy the
discount price!! Check out the preorder page for new pictures of this
release.
US$99, releasing 29 Mar. Preorder closed soon. Order yours today here!!
Megatron!
http://www.rinkya.com/buyrinkya/agora.cgi?cart_id=2019439.9444*Z300O62019439
.9444*4r0Uf8&keywords=br05
Happy holidays!
BuyRinkya Staff
http://rinkya.com/
Dear sir/madam,
I am Kathy from Elecsound electronics Company Limited. Do you need the electronic components listed below? Pls Trust us we will be your best choice.
Elecsound is a manufacturer of high quality, high reliability electronic components, formed in January of 1996. We currently offer a broad range of capacitors, as well as a full line of LED, Cermet Trimmer Potentiometers, Zinc Oxide Varistors and Resistors, also deal in semiconductors. Our staff has over 10 years of experience with excellent English. All of our employees have a strong work ethic and a strong commitment to provide the high quality products that consistently meet or exceed our customers" requirements. We offer very prompt reply, competitive price, speedy delivery and good after sale service.
The main products we offer inclulding as below and most of our products are lead free now .
Cermet Trimming Potentiometer Lead free
3006| 3262| 3266| 3296| 3299| 3323| 3386|
Capacitors Lead free
Aluminum Electrolytic Capacitor Radial, Axial and SMD type
Tantalum Capacitors Dipped and SMD type
Ceramic capacitors Radial, Axial and SMD type
Polyester Film Capacitors
LED series
5mm With Round Type LED
5mm Bullet LED
5mm Oval LED
5mm Cyhindrical Type LED
3mm and 5mm BiColor LED
3mm Round LED
3mm Cylindrical LED
3mm Oval LED
SMD type LED
Zinc Oxide Varistor Lead free
5mm Varistor | 7mm Varistor | 10mm Varistor | 14mm Varistor | 20mm Varistor
Your reply will be highly appreciated.
Best regards
Miss Kathy
Elecsound Electronics Company Limited
Tel No : 0086 755 83045964
Fax No: 0086 755 82513718
Dear sir/madam,
I am Kathy from Elecsound electronics Company Limited. Do you need the electronic components listed below? Pls Trust us we will be your best choice.
Elecsound is a manufacturer of high quality, high reliability electronic components, formed in January of 1996. We currently offer a broad range of capacitors, as well as a full line of LED, Cermet Trimmer Potentiometers, Zinc Oxide Varistors and Resistors, also deal in semiconductors. Our staff has over 10 years of experience with excellent English. All of our employees have a strong work ethic and a strong commitment to provide the high quality products that consistently meet or exceed our customers" requirements. We offer very prompt reply, competitive price, speedy delivery and good after sale service.
The main products we offer inclulding as below and most of our products are lead free now .
Cermet Trimming Potentiometer Lead free
3006| 3262| 3266| 3296| 3299| 3323| 3386|
Capacitors Lead free
Aluminum Electrolytic Capacitor Radial, Axial and SMD type
Tantalum Capacitors Dipped and SMD type
Ceramic capacitors Radial, Axial and SMD type
Polyester Film Capacitors
LED series
5mm With Round Type LED
5mm Bullet LED
5mm Oval LED
5mm Cyhindrical Type LED
3mm and 5mm BiColor LED
3mm Round LED
3mm Cylindrical LED
3mm Oval LED
SMD type LED
Zinc Oxide Varistor Lead free
5mm Varistor | 7mm Varistor | 10mm Varistor | 14mm Varistor | 20mm Varistor
Your reply will be highly appreciated.
Best regards
Miss Kathy
Elecsound Electronics Company Limited
Tel No : 0086 755 83045964
Fax No: 0086 755 82513718
On 2006-08-29, Eelco Visser <Eelco-Visser(a)xs4all.nl> wrote:
> Dear Stratego Users,
>
> It has been a while since the last Stratego User Days (May 2005). Last
> Spring has been rather hectic and no one felt like organizing the event
> then. In October I'm moving to Delft University of Technology and there
> appears to be some time in my schedule for another SUD. So I'd be
> willing to look into organizing a meeting in Delft somewhere in
> November. I will only initiate the organization if there are
> sufficiently many people interested and intending to attend. So please
> let me know whether you would like to attend SUD06 in November in Delft;
> and whether you'd be interested in making a contribution (talk,
> demonstration, discussion topic, whatever).
>
> -- Eelco
>
> P.S. Other opportunities to discuss Stratego/XT and exchange experiences
> are at OOPSLA/GPCE in Portland (make sure to attend our tutorial there),
> and at POPL/PEPM/... in Nice in January.
>
--
SIGOURE Benoit aka Tsuna
_____
/EPITA\ Promo 2008.CSI Rock & tRoll
Bonjour
J'ai le plaisir de vous informer que Transformers 0.5M2 a été released. Cette
version est encore en développement, c'est pourquoi elle n'a pas encore été
tagée ni released de manière officielle.
Au programme: nouveau bundle compose de trois packages:
generic-tools, c-tools, cxx-tools
Gros clean-up du build-system, portage vers Stratego/XT 0.17M2 (la dernière
version unstable est nécessaire pour compiler Transformers)
Mise a jour/ajout des notices de la GPL un peu partout ou ça manquait.
Voila :)
--
SIGOURE Benoit aka Tsuna
_____
/EPITA\ Promo 2008.CSI Rock & tRoll
(Copies envoyées aux listes projects et transformers du labo, pour
informer/faire participer les personnes concernées.)
SIGOURE Benoit <sigoure.benoit(a)lrde.epita.fr> writes:
> Yop
>
> Depuis deux jours, la BF ne build plus generic-tools. Y'a eu 3
> revisions depuis, et elle a toujours l'impression d'avoir builde la
> derniere revision (1566) alors qu'elle a 3 revisions de retard
> (generic-tools est bloque sur 1563).
>
> J'ai l'impression que c-tools et cxx-tools viennent de se bloquer
> sur la revision 1565.
Arg.
> Sinon antalya ne build rien, alors qu'elle devrai builder (entre autres)
> Transformers (et d'autres projs).
Je pense que le cron-job est suspendu ; il faut qu'on voie avec
Geoffroy.
> Enfin je pense que j'ai trouve pourquoi certaines revisions ne sont
> pas buildees par la BF. La build de Transformers prends assez
> longtemps (surtout le make check en fait) et si la build prends plus
> de 1 heure, les revisions commitees entre temps ne seront pas
> buildes. Ce qui pose probleme puisque la derniere rev ne sera
> buildee tant qu'un NOUVEAU commit ne sera pas fait. Je m'explique:
>
> Je commit la rev N.
> La BF commence a builder la rev N.
> Je commit la rev N+1.
> La BF build toujours la rev N... ca prends longtemps.
> Le crontab update les svn et passe donc a la rev N+1.
> La BF build toujours la rev N.
> Le crontab du worker se declanche et se rsync sur la derniere copie
> de travaille
> a la rev N+1.
> Mais le worker est encore en train de builder la rev N.
> La build de la rev N termine.
> La build de la rev N+1 n'aura jamais lieu car il n'y a pas d'update a faire:
> tout le monde est deja a jour, donc rien a rebuilder!
Je ne suis pas sûr que ça fonctionne comme ça ; notamment, il me
semble qu'il existe un mécanisme (primitif) de verrou pour empêcher
la mise à jour de la copie de travail d'un worker pendant qu'il
compile.
Il faut qu'on se plonge dans les détails du script.
> Je pense que ca se passe comme ca ce qui fait que meme apres
> plusieurs heures, la BF ne build pas les dernieres revisions.
>
> Cela dit quand des commits sont espaces sur plusieurs jours et que
> ca build toujours pas la derniere rev (comme c'est le cas pour
> generic-tools) je pense qu'il y a un autre probleme.
Oui, je pense aussi.
> Voila pour finir je pense qu'on peu optimiser un peu la build de
> "transformers" (le paquet complet). Le passage le plus long a l'air
> d'etre le make check de cxx-tools. On pourrait dire que
> "transformers" depends de generic-tools, c-tools et cxx-tools et
> demander a la BF de ne pas make distchecker "transformers" mais
> simplement de le make dist'er. En effet (P) si le make distcheck de
> generic-tools, c-tools et cxx-tools passe, alors le make distcheck
> de transformers passera, pas la peine de prendre plusieurs heures a
> le re-tester. La proposition (P) ne peut etre fausse que si un
> fichier necessaire au top-level de transformers n'est pas distribue,
> hors le top-level de transformers est vraiment vide, il s'agit
> vraiment juste de gluer les 3 packages sous jacant ensemble.
En fait, je proposerais bien l'inverse : compiler generic-tools,
c-tools et cxx-tools sans lancer les tests (ni `check', ni
`distcheck'), mais un faire un `distcheck' du paquet transformers
(voire un `check'). En effet, c'est le paquet transformers que vous
distribuez (et pas ses composants, individuellement), aussi les
tests devraient porter sur celui-ci, si on veut réduire leur nombre.
> Voila donc si c'est possible de faire ca, ca economisera des heures
> de make distcheck pour rien. J'ai mis les make check en --verbose 0,
> mais faut savoir que avant ca prenait 5 heures. Je sais pas combien
> de temps ca prends maintenant en --verbose 0 mais surement plus
> d'une heure. Donc voila ca fait du temps de gagne.
Ok, cool !
> Et puis compiler transformers apres {generic,c,cxx}-tools c'est
>rapide grace a ccache :D
Oui !
> Bon sinon autre question: est-ce qu'on pourrait effacer le dossier
> _build en cas de build successful? Les _build de
> {generic,c,cxx}-tools me prennent pres d'1Go (parfois plus) et tu
> sais que l'espace libre est rare sur mon / (bien que j'ai fait de la
> place).
Dans le cas général, je ne sais pas si c'est une bonne chose à faire
(en fait, je suis preneur d'avis). En revanche, c'est quelque chose
qu'on peut mettre en place facilement par machine,
- soit dans une tâche lancée par cron (mais comme c'est asynchrone
avec le build, ça risque de compromettre des compilations ; sauf si
on utilise le verrou posé par le script de build, mais ça commence à
tendre vers faire un édifice fragile...) ;
- soit à la fin du script warszaw (solution qui a ma préférence).
> Pour finir est-ce qu'on pourrait tenter de builder (sans make check)
> transformers avec le compilo Intel? Pas besoin de faire aussi les
> *-tools ni de faire de make check, juste de faire une build pour
> voir si ca compile.
Oui, sans problème. En revanche, il faut qu'on jette un oeil au statut
de ICC sur les machines de la build farm. On peut peut-être essayer
de le mettre dans /lrde/dev/linux-x86. Cependant :
- mon expérience personnelle de l'installation de ICC me faire dire
que c'est pas gagné ; en effet, j'avais installé ICC 9.1 dans un
sous-répertoire de /work sur brasilia il y quelques temps[1] et il
avait réussi à me coller également des fichiers dans /opt et dans
$HOME...
- la toute dernière version de ICC, la 9.1 (nécessaire pour compiler
TC, notamment), n'est pas encore disponible en version « non
commercial » ; seule une offre « evaluation » est disponible sur le
site d'Intel, et elle est limité dans le temps (un mois IIRC).
> L'ideal serait meme de faire intervenir cette
> build apres celle avec gcc et entre les deux de faire un find _build
> -name '*.o' -exec rm -f {} ';' pour que le make ne refasse que la
> compilation du binaire (et ainsi economiser le temps de compilation
> Stratego -> C qui est non negligable).
Arg, tu veux modifier le build tree et le reconfigurer sans faire de
`distclean' avant ! C'est pas sain. Le build ICC de Vaucanson est un
projet indépendant de celui avec GCC ; je propose de faire pareil avec
Transformers. Si c'est l'espace disque qui pose problème, on peut
supprimer les produits des builds entre chaque projet si nécessaire.
Notes:
[1] Le temps de la licence d'évaluation, en fait.
ne contient pour l'instant que les actes de "Library-Centric Software
Design 2005" http://lcsd05.cs.tamu.edu/
je vous conseille :
/mnt/doc/comp/prog/meta/stroustrup.05.lcsd.pdf
"A Rationale for Semantically Enhanced Library Languages"
Hire,
i am here sitting in the internet caffe. Found your email and
decided to writae. I might be coming to your place in 14 days,
so I decided to email you. May be we can meet? I am 25 y.o.
girl. I have a picture if you wanat. No need !to reply here as
this is not my email. Write me at mbs(a)snail4mail.com
Début du message réexpédié :
> De : "Jurgen J. Vinju" <Jurgen.Vinju(a)cwi.nl>
> Date : 16 mai 2006 10:31:14 HAEC
> À : meta-users-list(a)cwi.nl
> Objet : [meta-users-list] The ASF+SDF Meta-Environment 2.0-RC1
> (Release Candidate)
> Répondre à : meta-users-list(a)cwi.nl
>
> Dear ASF+SDF Meta-Environment people,
>
> We have decided to put a Release Candidate of the full ASF+SDF
> Meta-Environment online: version 2.0-RC1
>
> It has been a while since the previous release, and a lot of work
> has been done:
> - many requests for enhancement and bugfixes have been
> implemented. - a number of experimental features have been
> implemented
> - some features have been optimized for speed or memory consumption
> - and some legacy implementations have been replaced
>
> This is a Release Candidate, because we think a lot more has to be
> done to
> finish version 2.0 as a product: - some features are only half
> implemented (e.g. only by the ASF interpreter, not by the ASF
> compiler)
> - some features are not optimized (too slow or too big)
> - the documentation is out of date
>
> Below you will find the only available documentation on what
> changed and
> what you need to do to get your specifications working. We ARE
> catching
> up on the documentation front.
> =================
> BASIC INFORMATION
> =================
>
> Website
> -------
> * http://www.meta-environment.org
>
> Help
> ----
> * Problems, bugs and enhancements: * mailto:meta-support-
> list(a)cwi.nl
> * General help (also by other users): * mailto:meta-users-
> list(a)cwi.nl
> * Submitting issues directly: * bugzilla.sen.cwi.nl:8080/
> index.cgi
>
> Required software
> -----------------
> * The following software is necessary to compile and run 2.0RC1:
> * GNU gcc 3.4.x (the 4.x series contains bugs that we can not
> work around)
> * GNU make
> * Graphviz dot >= 1.12
> * Java JRE 1.5 (will not work with 1.4.x)
>
> ============== CHANGES & TIPS
> ==============
> Commandline
> -----------
> * The ASF+SDF Meta-Environment starts up with the command
> "asfsdf-meta", not with "meta" anymore.
> * The SDF Meta-Environment (without ASF) can be started with:
> "sdf-meta".
> * The dump scripts, pt-dump, eqs-dump, def-dump, etc. do not
> have options to save the "term-store" anymore. This feature
> has dissappeared and we are thinking about better ways to cache
> intermediate results.
>
> User interface
> --------------
> * The third-party editor interface is gone. So no more emacs or vi.
> * The editors are now implemented using a standard Swing
> implementation.
> * All Meta-Environment GUI tools are implemented in Java/Swing and
> hosted in a dockable window environment, implemented by
> InfoNode.com (GPL) * Note that many menu options have
> keyboard shortcuts, and all menus
> have changed.
> * Actions->Parse does not exist anymore, after saving an editor
> (CTRL+S), all necessary updates are done to the state of the
> system
> automatically. Any errors that may be the result of your changes
> are listed in the tab of the error viewer. (This is one of
> the experimental features that are not fast enough
> yet, sometimes after a save it takes a long time for the system
> to become idle again)
> * The full state of the system is viewable from the 'Progress'
> viewer
> tab.
> * All editors apply a generic syntax highlighting scheme, which you
> can influence in a number of ways. Contact meta-support-
> list(a)cwi.nl
> for questions.
> * We use "prefuse", an open source graph visualization and animation
> package: www.prefuse.org. The graphviz layout algorithm is used,
> but the actual displaying is done by prefuse:
> * left click and drag: move a node
> * right click and drag up/down: zoom out/in
> * right click on canvas: zoom to fit
> * left click on node: select node
> * right click on node: open context popup menu
> * the "Graph" menu contains some other options
> * Switch workspace: The "Workspace" is the directory where new
> modules
> will appear and existing modules are found. The File menu contains
> a switch workspace button that can be used at anytime.
> * Open module: the file browser that is opened gives access to:
> * the Workspace
> * the SDF library
> * the ASF+SDF library
> You should not open files outside of these domains, the interface
> tries to limit this, but it is not hacker proof.
> * Note that syntax definitions are now in the SDF library, while
> ASF+SDF data-structures and utilities are still in the ASF+SDF
> library.
> * Library modules are read-only, and coloured grey in the import
> graph.
> * The save termstore feature has dissappeared. We are thinking about
> a replacement for caching intermediate results between runs of
> the Meta-Environment.
>
> Syntax Definition Formalism and SGLR
> ------------------------------------
>
> * The SDF library now comes with some new grammars:
> * C grammar
> * Parameterized C preprocessor grammar
> * The syntax of SDF has been redesigned to use the same syntax
> for string literals everywhere. This also implies that unquoted
> string literal symbols are not literals anymore. You will get
> parse errors in your SDF modules. Before, the SDF checker
> would warn you about deprecated use of unquoted literals.
> * The AsFix2ME format has changed. It does not flatten lexical
> syntax
> anymore. Fully structured lexical trees are generated from now on.
> * AsFix2ME also does some subtle rearrangements of LAYOUT nodes.
> For details read the source code or contact meta-support-
> list(a)cwi.nl
> * The SDF checker generates less false warnings on old issues, and
> some more false warnings for new issues. * CASE-INSENSITIVE
> LITERALS are added as a feature to SDF2. The
> syntax is as follows:
> 'begin' STAT* 'end' -> PROGRAM
> Defines a program with two case-insensitive literals begin and
> end.
> (use of single quotes instead of double quotes). The SDF
> normalizer
> generates for you:
> [bB][eE][gG][iI][nN] -> 'begin' [eE][nN][dD] -> 'end'
> remember the case-sensitive notation is still:
> "begin" STAT* "end" -> PROGRAM
> which generates:
> [b][e][g][i][n] -> "begin" [e][n][d] -> "end"
> * ci-lit(<str>) was added as a symbol constructor to AsFix2[ME]
> * CYCLIC GRAMMARS: SGLR now accepts cyclic grammars. A parse forest
> with a representation of a cycle will be generated instead of
> a parse error. The representation is NOT minimal. Contact
> meta-support-list(a)cwi.nl for details.
> * AsFix2[ME] is extended with a new Tree constructor, next to
> appl, amb and char we now have: cycle.
> * The backend of SGLR was optimized for highly ambiguous languages.
> The use of memoization in several algorithms has improved the
> worst-case complexity from exponential to polynominal.
> * SGLR does not provide a detailed ambiguity report anymore, use the
> renewed implementation of the tool "ambtracker".
> * NOTE: we are currently reimplementing the API's around SGLR and
> remodularizing its implementation. * Syntax productions are
> generated from priority sections like was
> done several versions back. BEWARE: we removed this then because
> the attributes of productions are merged if the rest of the
> production is the same. It might lead to unexpected shapes of
> productions in an AsFix2 parse forest. The benefit in
> grammars for C, Java and C++ is so big, that we
> decided to put it back in (several dozens of lines less in SDF
> modules with large expression grammars)
> * PRIORITY FOR SELECTED ARGUMENTS. A priority can now be limited
> to be applicable in a certain argument only. This works for
> single productions as well as groups, and priorities are still
> transitively closed. Example:
>
> context-free priorities
> { E "[" E "]" -> E
> E "bla" -> E
> } <0> >
> E "*" E -> E {left}
>
> The first group has a higher priority than the second group, but
> only in the first (0) argument. Between the <..> brackets comma
> separated lists of argument numbers are accepted. We start
> counting
> at zero, and count EVERY MEMBER of the left hand side including
> literals, counting nested symbols as 1 member, and ignoring the
> implicit LAYOUT? non-terminal.
>
> Algebraic Specification Formalism
> ---------------------------------
>
> * STRUCTURED LEXICALS: this is the new feature that breaks old
> ASF+SDF programs that made use of lexical constructor functions.
> This is a long story, here is the summary:
> * The CHAR sort is not to be used by you anymore. From now on
> you use 'lexical variables' as such defined in SDF2:
> lexical syntax
> [0-9]+ -> Number
> Number "." Number -> Real
> lexical variables
> "digit"[0-9]* -> [0-9]
> "digits"[0-9]* -> [0-9]+
> "num"[0-9]* -> Number
> "real"[0-9]* -> Real
> * In other words, for lexical non-terminals and character classes
> do not define normal variables, but lexical variables.
> * Variables that range over SUBCLASSES may be used. If a variable
> does not range over a subclass of the expected character class,
> an error will be generated. Example:
> lexical variables
> "half" -> [0-4]
> "more" -> [0-9A-F]
> The variable 'half' is acceptable everywhere [0-9] is also
> acceptible. The variable 'more' is not accepted at [0-9]
> locations.
> * Lexical constructors are now fully NESTED, because lexical
> syntax is not flattened to a list representation anymore,
> we now also need STRUCTURED LEXICAL CONSTRUCTORS. * For
> each production in lexical syntax a lexical constructor
> function is generated:
> - the prefix function name is the sort name in lowercase
> - each function has as many arguments as the production
> had members, including literals.
> - literals are to be typed literally
> - characters are escaped in the same manner as characters
> are escaped in the definitions of SDF2 character classes.
> - lexical variables are only accepted in the context of
> these generated constructor functions
> - example (see syntax and variables above):
> equations
> [zeros] number(0 digits) = number
> (digits) [trunk] real(num . number(digits2)) = real
> (num . 0)
> - another example:
> lexical syntax
> [\"] ~[\"]* [\"] -> String
> lexical variables
> "char"[0-9]* -> ~[\"]
> "chars"[0-9]* -> ~[\"]* equations
> [remove-nl] string(\" chars1 \n chars2 \")
> = string(\" chars1 chars2 \")
> - You can not construct any lexical that does not conform to
> the SDF definition of the lexical syntax anymore. Not even
> as an intermediate step. This sometimes requires some extra
> thinking. See the library modules basic/Identifiers and
> basic/Strings and basic/Bytes for examples on how
> to analyse or transform lexical syntax.
> * (Traversal) Functions that returns lists, there used to be many
> problems with functions that returns lists, including traversal
> functions that visit list nodes: e.g. f(A) -> {B ","}*
> SDF, AsFix2 and ASF have been changed to fix these issues. *
> REWRITING LAYOUT. Layout nodes are now first class citizens in
> ASF specifications. Each layout node in a syntactic pattern (i.e.
> left-hand sides or right-hand sides of conditions and equations)
> can now be in either one of these two modes:
> * IGNORED: the layout is ignored by a match, and put in literally
> by a constructing pattern. The syntax for this is just as it
> used to be: simply type the layout as it is defined and it will
> be ignored.
> * NOT IGNORED: the layout is matched and constructed according to
> your specification. The mode is activated when:
> * You use a lexical constructor function for layout
> * You use 'layout brackets'
> * Examples:
> lexical syntax
> [\ \t\n] -> LAYOUT
> "%%" ~[\n]* [\n] -> LAYOUT
> context-free syntax
> "_" "_" -> DUMMY {layout-bracket}
> lexical variables
> "L"[0-9]* -> LAYOUT
> equations
> [] if !E then S*1 else S*2 fi = if E then S*2 else S*1 fi
> [] if layout(\n) E then S* fi = if layout(\ ) E then S* fi
> [] if L1 layout(\n) L2 E then S* fi = if L1 layout(\ ) L2 E
> then S* fi
> [] _ layout(\t) _ = _ layout(\ ) layout(\ ) _
> * The first equation ignores layout completely, like usual.
> * The second equation only matches an if statement if there is
> EXACTLY one newline between the if and the E.
> * The third equation matches an if statement with a newline
> SOMEWHERE between the if and the E.
> * The fourth equation matches ALL single tabs and translates
> them to two spaces.
> * Condition syntax
> * The deprecated '=' condition operator has dissappeared
> * Integrated unit tests
> * There are still unit tests in ASF specifications, example:
> equations
> [] myfunction(...) = myanswer(...)
> tests
> [] myfunction(xyz) == myanswer(abc)
> * Rewriting with pos-info annotations and others
> * You can store and retrieve parse tree annotations using the
> modules utilities/Annotations, utilities/ATermAnnotations and
> utilities/PosInfo. * The ASF interpreter supports this
> by default
> * The ASF compiler has an extra commandline option to
> activate support for annotations in the generated code.
> * New builtin functions:
> * See utilities/Parsing for calling the parser on files and
> strings
> * See utilities/Files for reading and writing files from ASF
> * The commandline versions of the interpreter and the compiler
> have
> a new option to pass a parse table in, for use with the
> parsing builtin
> * Interface of compiled specifications * A compiled
> specification can now read source code directly, without
> using sglr first.
> * If you compiled a specification from the Meta-Environment
> directly,
> this is the default behavior: the binary will rewrite source-
> to-source.
> * Wild and strict variables (not experimental anymore)
> * The experimental feature of wild and strict variables is
> consolidated.
> * example:
> variables
> "_x"[0-9]* -> Integer {wild}
> "x"[0-9]* -> Integer {strict}
> * wild variables may only be used as 'wildcards'. No further use
> of a variable is allowed after using it in a match.
> * strict variables are used for information propagation. A strict
> variable MUST be used after it's introduction. * NOTE:
> the use of strict variables leads to less errors, it
> prohibits unintended loss of information.
> * NOTE: the use of wild variables also leads to less errors, it
> prohibits unintended failure of matches by use of the same
> variable
> names twice. * Complete functions
> * An experimental feature: complete functions. You can annotate a
> function to be complete, which means that it may not appear in
> a normal form. Use this if you intend to implement a
> function that
> deals with all input correctly.
> * You will get a run-time error (interpreter only) if a
> complete function
> does not reduce.
> * Example:
> context-free syntax
> myfunction(Statement) -> Booleans {complete}
> * Rewriting ambiguities
> * The rewriting of ambiguities implementation has changed
> recently,
> but not tested thoroughly yet. Use with caution.
>
>
>
