On 7/17/2011 11:31 AM, karl ramberg wrote:
Hi
Here is a interesting video about programming languages
http://skillsmatter.com/podcast/agile-testing/bobs-last-language
Karl
some of this is why my own BGBScript language has a C-family syntax
(well, yes, it is closer to ActionScript, but in a general sense, a lot
comes down to hair-splitting, considering that in the greater scheme of
things, the syntactic differences between C/ActionScript/Java/C#/... are
maybe relatively minor).
its point is not to do a whole lot "new", but rather to:
try to serve my personal needs;
try to refine a lot of what exists (make the language nice to use, learn
from what others have done, ...);
...
although, he makes a point about a language being "homoiconic", which as
I understand what he is saying, my own language is not, technically:
in BGBScript, expressions are built and evaluated as strings, with the
goal of this process being relatively fast and cheap;
I had noted that even on a slow ARM emulator, interactive code entry is
still fairly responsive, mostly for sake of having millisecond
compile+execute times (despite the interpreter running around 200x
slower than native, and the interpreted code itself probably running
around 25,000x slower than native).
this was part of why (besides the bugs) my use of BGBScript won out over
dynamically-compiled C: there was probably no reasonable way I could get
my dynamic C compiler anywhere near this responsive (absent potentially
fundamental alterations in the language, resulting in a language which
merely resembles C).
not that given enough effort I couldn't probably patch over it or
anything, just I have potentially more productive things to do.
then recently I ran into an issue which causes some uncertainty at the
moment:
I added an "extern import pkgname;" variation on import, which basically
has the property that it will attempt to load the module in addition to
simply importing the package.
an uncertainty though is if this should be the default semantics, rather
than using a modifier, and how this relates to another strategy:
manually loading the modules into the VM (either from C or via the
"load(name)" API call).
also using the "extern import" form would pose restrictions:
"extern import foo.bar.baz" would effectively require a file to exist
("foo/bar/baz.bs") and to contain a package by the same name:
<--
package foo.bar.baz
{
...
}
-->
"extern import" was added along with a VM "ScriptPath" feature which is
used to help automatically resolve these imports (a library would likely
exist as a directory, or as a file serving an analogous role to a JAR file).
some other languages (such as Java) have essentially the "extern import"
semantics by default, whereas C# and ActionScript essentially work by
combining modules into bigger units which are loaded all at once (better
matching my present import semantics, which assume pre-loading any
modules for which import may be used, which allows a good deal more
freedom with how packages or files may be put together, ...).
there are good and bad points either way.
the worry is that having a separate "import" and "extern import"
statements could be confusing, in addition to the present "native
import" (used by the FFI) and "delegate import" (which allows different
import semantics, mostly re-exporting the imported packages' contents
from the current package), ...
there is more hair as well, as there may need to be "extern static
import" and "extern abstract import", ... to deal with several
organizational edge cases ("extern abstract import" would essentially do
the same thing as a "load()" call, and would be mainly of use for
constructing packages and libraries).
however, the thing is that "native import" and "delegate import" would
likely mostly be limited to library designers, whereas "import" vs
"extern import" could impact more end developers who "just want their
code to work and don't want to care what is really going on" (IOW,
probably don't want to know or care why they may need to put modifiers
on their imports and packages to make things work).
part of the reason for a lot of this though is that BGBScript has no
direct analogue of Makefiles, which would otherwise serve this role in a
language like C or C++, or in C# (for those not using VisualStudio or
MSBuild or similar). without a Makefile, sadly, some of these
complexities are liable to end up in the language itself.
or such...
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
