Re: more idle thinking: SiMPL


"BGB / cr88192" <cr88192@xxxxxxxxxxx> wrote in message
news:h9buac$vct$1@xxxxxxxxxxxxxxxxxxxx
this is just a few thoughts I have been thinking on and off recently, me
faced with the sort of "slippery slope" of extreme complexity I have faced
myself with over the past few years.

I will not claim at this point any particular intention to implement
something like this.


updates:
SiMPL is too much like SiMPLE, which is a language which already exists;
SMPL at least would less likely cause confusion.


I am thinking of an odd piece of syntax:
<name> '(' <exprlst> ')' <block>;
also:
<name> '(' <exprlst> ')' <expr>;

which could be used to extend the syntax in a way both context independent,
and fairly general purpose. similarly, function call syntax could be used
for other similar extensions.

semantically, this would mean a slight overloading though, as:
Foo(x, y);

could be either a function call, or something more along the lines of:
Foo<x, y>;

y=cast(int) sqrt(5);


another pondered thought was to allow ';' as a secondary grouping operator
(within things like args lists).

foo(a, b; c, d;);

which would cause a,b and c,d to be grouped into single items.

the other possibility is to allow parenthesis to be used for grouping:
foo((a, b), (c, d));


as noted, there will be no syntactic difference between type names and
expressions.

by extension:
"*int", if the pointer extension is supported (as opposed to "int *"), since
the '*' would in this case be parsed as a prefix operator.

function foo_memcpy(dst:*void, src:*src, size:int):void
{
var pa:*byte, pb:*byte;
int i;

pa=dst; pb=src;
for(i=0; i<size; i++) pa[i]=pb[i];
}


by extension (assuming this syntax used for classes / ...):
class(Foo, Bar, IBaz) {
var x:float, y:float;
function Foo(x:float, y:float)
{
this.x=x; this.y=y;
}
}


treatment of ';' could be a little more flexible than in C family languages,
where it may be safely omitted in cases where it is non-ambiguous.

<name> '(' <exprlst> ')' <block>
<name> '(' <exprlst> ')' <expr>

no ';' being needed if these appear as statements, since the end of an
expression is typically self-deliminated.

however, there are certain cases where this is not the case, such as when
the next statement would begin with a prefix operator (would matter in the
'expr' case), which would essentially require the ';' to avoid being
ambiguous.

note:
<expr> '(' <exprlst> ')' <block>
<expr> '(' <exprlst> ')' <expr>

will presently be considered invalid (where expr!=name), since these would
likely make an unreasonable headache for the compiler (AKA: not possible to
disambiguate at compile time).


':'<type> could almost be made a general-purpose syntax, apart from the
issue of ambiguity in the case of switch/case (could be hacked if needed,
namely in that case would essentially disable ':', similar to how args-lists
in C essentially disable the comma operator...).


also possible:
var(static) x:int; //makes modifiers non-special

function(static) foo():void {}
//natural extension, but creates a syntax problem if ES/JS style closures
are supported.

function(x:int, y:int):int { return(x*x+y*y); }
ES-style closure.

in some of my past script languages though, I had instead used 'fun' for
closures:
fun(x:int, y:int):int x*x+y*y;

problem:
this requires either:
making 'fun' a part of the built-in syntax;
making "':' <type>" general-purpose syntax (leading to a 'case'
special-case).


granted, all this is a little "squirrely", but it would allow pulling off
the core goals:
providing for both context independent parsing and extensibility.


compile-time semantics is another issue, since, more so than many other
languages, a little more work will be required to make sense of the ASTs.


note that, in my thinking, "import" would be mandatory prior to using any
such features.

this is because, even though these features are likely to be built into the
compiler, the import will essentially tell the compiler to make them
"visible" (beyond its use of importing module scopes).


granted, I will not specify at this point whether the language would include
any sort of macro facilities, however, if provided, they would most likely
be as an extension.


or such...



.

Relevant Pages

  • Re: How about this syntactic candy?
    ... I can think of that's worse than adding a rarely needed, rarely beneficial syntax is adding one that actually allows one to lie to the compiler in a way that _breaks_ the code. ... But more significantly, IMHO, the reason that syntax has survived so many generations of this family of languages is that it's so commonly useful. ... simple for loop. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: what is wrong with this code ?
    ... Dick Hendrickson wrote: ... The syntax for an implied DO is just ... Hmmm...Is it really an extension to allow them, ... The compiler here certainly accepts it as written; I thought them optional... ...
    (comp.lang.fortran)
  • Re: ANN: pldev.org
    ... As for left$ and right$, I actually prefer that syntax ) ... languages can vary and it's probably not good to depend on specific ... with value b+1, or b-1 if using 'downto', if the loop terminates normally. ... especially if the compiler is clever enough to detect when it might change; ...
    (comp.lang.misc)
  • Re: Borland C and Microsoft Visual C
    ... C++ always come with a packaged C compiler. ... files a .c extension and they will be compiled as C. ... incompatibilites which mean that C cannot be compiled as C++ unless you ... deliberately write it to be compilable under both languages. ...
    (comp.lang.c)
  • Re: What was Noam Chomskys contribution to *LINGUISTICS*?
    ... >>> The thing is that you can't use corpus linguistics to falsify Paul ... >> syntax class to discover how many found a particular example acceptable. ... who have likely been taught British Standard English. ... > a number of Romance and Germanic languages enter into the discussion. ...
    (sci.lang)