On 6/14/2011 12:14 PM, Michael FIG wrote:
Hi,
John Nilsson<[email protected]> writes:
So my fix is to make the separation a hidden thing, which means the
program needs to be represented in something that allows such hidden
things (and I don't think Unicode control characters is the way to go
here).
Why not crib a hack from JavaDoc and make your nested syntax embedded in
comments in the host language?
or, like in my languages (generally for other things):
use a keyword...
reusing prior example:
public int totalAmmount(InvoiceNo invoceNo)
{
return SQLExpr {
SELECT SUM(ammount) FROM Invoices WHERE invoiceNo = :InvoiceNo;
}
}
granted, yes, this requires the ability to plug things into the parser
and compiler, which isn't really possible with a standard Java compiler,
but is not an inherent limitation of text IMO.
another person, elsewhere (Thomas Mertes, who endlessly flogs his
"Seed7" language) is basically really into supporting stuff like this
in-language (absent using compiler plug-ins).
in my case, usually a plugin would be registered with the parser and the
compiler, where the parser plugin would detect and respond to a certain
keyword, and the compiler plugin would respond to specific added AST
node types.
some other things in my language is done via attributes and modifier
blocks, but generally this is for things which don't otherwise change
the basic syntax.
native {
... FFI related stuff ...
}
$[ifdef(FOO)] {
... conditionally compiled stuff...
}
...
yes, yes, my attribute syntax is nasty...
embedding things in comments technically works, but is IMO a nasty way
to do extensions, in much the same way as is the "embed complex program
logic in strings" strategy.
slightly less nasty (but still not really ideal IMO), is to use special
purpose preprocessing, like how Objective-C and Objective-C++ work.
I can already do some of the above with C, via having a more "expanded"
version of a C-style preprocessor, but generally don't do this sort of
thing unless really necessary (I prefer strategies that can be done
purely within the language, rather than those which would require more
heavy-handed methods, when possible...).
or such...
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
