From the paper:
"The challenge in taking Natural Languages as the basis to producing a
programming language is to decide which theings should be
referenceable in the context of computer programming, given the wide
range of application domains. We should keep in mind that a
naturalistic language should have an important property of most
programming languages: it should be possible to construct abstractions
on top of a relatively small number of primitive abstractions.
Ideally, each application domain would build its own terminology and
idioms, similar to what happens with Java APIs and similar to Natural
Languages' dictionaries. What we propose here is that such primitive
abstractions should be inferred from wider ground of Linguistics,
rather than from computer engineering or mathematics or ad-hoc models
such as objects. We propose this based on the fact that Natural
Language comes before, and supports, all other domain-specific
languages."
Anyway, I was wondering if there was any work on Aspect Oriented
Programming in Forth - or similar. Or if anyone has a more formalised
approach to using "parts of speech" words like the description of
using adjectives and modifiers in "Starting Forth".
I've been experimenting on and off with making high level forth
definitions read well, but I've not come to any conclusions other than
trying to abstract variable references away seems to be a good idea.
emma
I am not aware of anything in particular.
What you can do in some cases is to redefine the words for which you
want to add aspects to include the aspects or hooks for the aspects,
before you load the program that you want to add aspects to.
E.g., if you want to, say, count the number of calls and exits, you
can redefine ":", ";", DOES> and EXIT to do the counting.
But of course that works only well if you can link the aspects to some
words. If you want to add stuff like marshalling of data structures,
you cannot just add it to existing Forth code.
Of course you can write your code so that you can add specific aspects
easily; I don't think Forth programmers would think about this as
aspect-oriented programming, though. The challenge is to write code
such that it is amenable to adding aspects that you did not think
about beforehand.
Another thought: the uniformity of Forth (everything is a word,
everything on the data stack is a cell, everything in memory consists
of aus) probably helps quite a bit with stuff you might want to do
with aspects.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2009: http://www.euroforth.org/ef09/
Thanks, I had initially thought that simply redefining words as you
suggest would be enough, but I hit on the problem AOP is meant to
solve, the 'aspects' need to be spread through the rest of the code.
To keep things simple, I'm just focusing on adding aspect code to
named colon definitions for now, the idea being the original code can
be written without any knowledge of the aspects
before: word ...code... ;
after: word ...code... ;
before: and after: define a piece of headerless code, which calls on
the original definition of word as appropriate, and revectors the
original word to run this new definition.
I have a feeling it wont be easy (if at all?) to define this in ANS
Forth, but then I'm not sure how generally useful it will be anyway.
Emma
Assuming that colon-sys is nonexistent then this should work.
SYNONYM old; ;
DEFER ; IMMEDIATE
' old; IS ;
: before; ( xt -- ) COMPILE, POSTPONE old; ['] old; IS ; ;
: BEFORE: ( "name" -- ) >IN @ ' SWAP >IN !
['] before; IS ; : ;
: AFTER: ( "name" -- ) >IN @ ' SWAP >IN ! : COMPILE, ;
I hope this helps.
Michael
SYNONYM old; ;
SYNONYM old: :
DEFER ; IMMEDIATE
' old; IS ;
: new; ( n -- ) POSTPONE old; >IN ! IS ; IMMEDIATE
: before; ( n -- ) DUP >IN ! ' >BODY @ COMPILE,
POSTPONE new; ['] new; IS ; ;
: : ( "name" -- ) >IN @ DEFER :NONAME ;
' new; IS ;
: BEFORE: ['] before; IS ; : ;
: AFTER: : >IN @ OVER >IN ! ' >BODY COMPILE, >IN !;
Michael
Thank's Michael
I'm having some trouble following this, but the technique of referring
back into the input buffer is something I've not come across before.
After thinking about it some more, it's actually conflating two issues
to do it this way. A better approach seems to be to define the
'advice' (in AOP terms) independently and then apply it.
I've got the following to work in ciforth/lina.
: call >r ;
: link ( dea -- *code ) >dfa dup @ here rot ! ;
: pointcut (word) present link ;
: advice latest >dfa @ ;
: patch 'lit , , 'call , 'lit , , '>r , 'exit , ;
: before pointcut advice patch ;
: after advice pointcut patch ;
: test "hello" type ;
: to-world ", world" type ; after test
test prints " hello, world"
notes -
"(word) present" is equivalent to "bl word find drop" when word exists
">dfa @" I think is equivalent to ">body" except ciforth permits
revectoring by changing the address stored at the data field address
of a high level word header
In patch, 'lit, 'call etc are equivalent to ['] lit , ['] call etc -
I'm fairly sure this could be written more portably, but for the use
of the return stack to implement jumps, and that it is headerless code
Emma
Michael
This is the kind of "system programming" that really makes you
jump through hoops, if it must be portable.
OTOH this kind of redirection is not too hard on indirect
threaded Forths. Look up OLD: in ciforth (lina/wina).
Assuming `` word '' is a regular colon definition,
your example would become
: new-word ...code1... OLD: word ...code2... ;
'new-word >DFA @ 'word >DFA !
To restore the original behaviour of `` word '' :
'word RESTORED
Explanation: OLD: compiles some magic to directly run the
old code from the content of the >DFA such that it doesn't
change if the >DFA is later "vernagcheld".
>
>Emma
>
--
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst