early language design. 
Author Message
 early language design.

I am asking for comments on a early partial design for a language. at
present I have not really gotten any comments (either good or bad).

the language derives many structures from scheme and Smalltalk, with a few
others thought up by me.
at present I have written the partial spec and am writing a
compiler/interpreter (many details are sufficiently different from scheme
to require noticable changes to my scheme system...).

the parser was largely rewritten, and I am currently restructuring the main
compiler. the code generator and interpreter should require minimal
modification.

------
General

I will attempt to design a language. this will be a hybrid of a functional
and imperative object oriented language.

Basic Syntax
function args...
object args...

the first object on a line is either a function call or an object.
any lower lines with a higher indentation are also considered as functional
arguments to a given function, thus functional arguments will naturally be
the last arguments to a function.

a line may be terminated with '\' indicating it is continued on the next
line. for the next line indentation is considered unimportant, however a
good apprach would be to indent it more than one would indent any following
subexpressions, or the same if none exist.

parenthesis may also be used to indicate nested functional arguments on the
same line:
function ... (function args...) ...

also infix notation may be supported:
arg function
arg function args...

however the order of operations at present will not be defined based on the
requirement that nested expressions require parenthesis...

in cases where it is possible for both prefix and infix evaluation to
occure, prefix will be the default. thus in this case prefix may be used to
clarify certain constructs.

consider:
'new object' vs. 'object new'. it would seem that new would be the default
in both, however in the second object could default to taking the 'new' as
an argument, thus calling it's 'new' function.

at present I will define symbols to contain letters, numbers, or one of the

the exeption will be + or - followed by a number, in which case it is
considered as a sign identifier and a number.
I will define symbols to be case insensitive, and to have lower case as the
default. some symbols by convention will be written in upper case, but this
has no real effect on the language.

'object this will have the same behavior as in lisp, ie: the object will
not be evaluated.

#\character will represent an individual character, character will be the
character itself.
#\code will represent a character by it's code.
code will either be numeric (hex, required to start with a number), or a
special nmonic for the character.
all characters will be required to be seperated by a space, and any value
which consists of multiple characters will be a code.
#\a => 'a'
#\0A => '\n'
#\space => ' '

numbers and strings will follow the usual rules.

// will be used for line comments, with /* and */ for block comments.

the language will be dynamically typed and lexically scoped, and I will
make the requirement that it be tail recursive.

conceptually there will only be a few primative types: numbers, characters,
arrays, and environments.
there will be a special array referred to as a cons, this will have 2 slots
called head and tail.

strings and symbols will be considered an array of characters.

(items...) will be used to represent a list.
a list will be composed of cons cells, each of which will have the data
item in head and the remainder of the list in tail.
another form is
(items... . item) which will represent a list with item placed in the final
tail.
() will be an empty list, this will be considered a value in itself.

#(items...) will represent a array containing the items.

constructs accepting multiple forms will evaluate left to right and will
return the value of the last form.

if an expression is opened, ie: with ( it is still required to be line
broken and ended with ).
ex:
(begin
        display "1\n"
        display "2\n")
is valid.

but:
(1+
2)
is not, and:
(1+ \
2)
is.

a requirement is that sub expressions on lower lines still need a higher
indentation than the parent line.

true and false will be values:
T and F, corresponding to true and false respecivly.
there will also be NULL, which will be considered distinct from ().

Definitions

define variable  
define variable value
define (variables...)
define (variables...) values...
defines variable, and assigns value to it if a value is given.
define will only create a new binding but will not change any previous
ones.
in the case where it is given lists of variables or a variables list and
values it will bind multiple variables at the same time. the variables and
values are to be the same in number.

redefine ...
will have the same syntax as define however if the variable exists it will
be assigned rarther than creating a new binding.

defspecial variable
defspecial variable value
despecial (variables...)
despecial (variables...) values...
defines a special variable, special variables differ from normal ones in
that they follow dynamic scoping rules.
defining multiple special variables with the same name serves little
practical purpose as only the last defined value is used.

function name (args...)
        forms...
function name args_lst
        forms...
defines a function called name. multiple functions may be defined with the
same name in which case the last definition which matches will be used.
at present I will define that args may be either symbols or literals, where
a function match is considered if the values are equal.
_ will be usable as a value which will allways match (except if the arg is
not present).

having a symbol in the tail position, or having a symbol for an args list
will specify that the function accepts a variable number of arguments.
extra arguments will be passed to the function in the form of a list.

lambda (args...)
        forms...
lambda args_lst
        forms...
will create an anonymous function which accepts args, anonymous functions
have the advantage that they can be passed as variables without needing to
be bound.

let (variable value)
        forms...
letrec (variable value)
        forms...
let ((variable value)...)
        forms...
letrec ((variable value)...)
        forms...
will bind variable to value in each list and then invoke forms with the
variables bound.
in let the bindings are not in effect when each value is evaluated, however
in letrec they are, possibly allowing mutually recursive functions.

Objects And Environments
objects and environments will be considered roughly analogous.
an object will just be an environment with a few special functions bound.

the structure will be that of a pair of variable dimensional trees, the
trees are to have matching structure however one contains symbols and the
other objects. any symbol denotes a leaf and thus indicates that spot on
the tree to contain data. I will define that either tuples or lists may
compose an object.
likely this will need to be optimized, however the exact implementation of
the environment is outside this spec.

this will use a variation of a prototype object system.

all the top level forms of an object will be the implicit  constructor.
in cases where any "normal" operator is being used with the object the
object is to be used first in order to allow it to override the operator,
placing the operator in prefix position may be used to be more explicit.

General Object Minipulation
clone object
clones an object, by duplicating both lists. it does not call a
constructor, also it ignores any "clone proof" parts of the tree.

self, which will be bound on clone within the object to the resulting
object.
parent will also be bound to it's previous self.

one can check if an object is an ancestor of another first by comparing the
self value, then stepping along parent and comparing each one with the self
of the other.

an implementation is free to create both self and parent as builtin
variables, this may allow for more efficiency in some places (ie: checking
for ancestory, where one could implement parent as a list).

exec object
        forms...
executes forms within the object's environment. this will be useful for
mutating the object.

object args...
when an object is used as a function it will work by looking up the symbol
indicated by the first arg, returning that value if it is not a closure or
object, otherwise it will apply it with the remaining args. prefixing the
last arg with a _ may be used to alter this behavior, in which case it will
just return the value rather than trying to apply it.

this is preferred means by which to interact with an object.

object (parents...)
        forms...
defobject name (parents...)
        forms...

this will work by creating a new object which will be the accumulation of
the current bindings and all the parents. after this it will invoke forms
within the new object. in the case of object the resulting object is
returned otherwise the result is undefined.

this is intended to behave much like a class in other systems, but may be
used to create other kinds of objects as well.
the last parent will dominate, each parent will dominate over the one
comming before. all of the parents are considered clone proof.
by default this will also include all bindings in place at the time of
definition, which will be considered as coming before all the others (and
thus will have the least influence).

Object Utility Bindings
current-bindings
which will return the current environment.

last symbol  
last symbol num
can be used for backtracing
...

read more »



Sun, 06 Feb 2005 00:52:59 GMT  
 early language design.

Quote:

> I am asking for comments on a early partial design for a language. at
> present I have not really gotten any comments (either good or bad).

you can think of silence as an early partial comment.

(or a late one, if you've pissed people off. ;-)

fwiw, i skimmed the proposal, saw "\" and stopped skimming, so probably
further comment from me on this proposal would not be helpful.

thi



Sun, 06 Feb 2005 01:33:00 GMT  
 early language design.

Quote:


>> I am asking for comments on a early partial design for a language. at
>> present I have not really gotten any comments (either good or bad).

> you can think of silence as an early partial comment.

does it really suck that bad?...

Quote:
> (or a late one, if you've pissed people off. ;-)

> fwiw, i skimmed the proposal, saw "\" and stopped skimming, so probably
> further comment from me on this proposal would not be helpful.

it is a bit ugly, but I could not think of a better solution. it uses line
oriented parsing, so it is a problem that shows up. other less elagent and
more complicated solutions exist.

most lines will likely not be that long anyways...

I wonder more about the other parts of the design, ie: the object system.

--
<cr88192[at]hotmail[dot]com>
<http://bgb1.hypermart.net/>



Sun, 06 Feb 2005 02:23:17 GMT  
 early language design.

Quote:

> does it really suck that bad?...

suckiness has many orders.  lots of people filter on higher-ordered
suckiness factors, like how they perceive the tone of your posts, or
whether or not you've demonstrated due diligence in researching their
areas of expertise.  the thinking goes: if these factors flag suckiness
probably first-order suckiness is also indicated.  sometimes it's
difficult to get good feedback because it's difficult to find the right
questions because it's difficult to know what questions others have
asked already and have answered in their own minds.

from recent (6mo) history, i notice that you have started a compiler
project.  being a compilation dilletante, i am more interested in
hearing about that than in hearing about a new language.  if you have
abandoned the project, i am interested in hearing what you learned,
including what you learned about yourself.  also, i am always interested
in source code, especially if i can use it freely.

thi



Sun, 06 Feb 2005 03:32:48 GMT  
 early language design.

Quote:

> I am asking for comments on a early partial design for a language. at
> present I have not really gotten any comments (either good or bad).

You might try posting what your *goals* are.  If you are trying to
assimilate the best of a number of languages, then you might list what
elements you are trying to combine.  You might also list what elements
you are trying to get rid of -- that ought to inspire some heated
replies.  :)

-Lex



Sun, 06 Feb 2005 04:02:03 GMT  
 early language design.

Quote:


>> I am asking for comments on a early partial design for a language. at
>> present I have not really gotten any comments (either good or bad).

> You might try posting what your *goals* are.  If you are trying to
> assimilate the best of a number of languages, then you might list what
> elements you are trying to combine.  You might also list what elements
> you are trying to get rid of -- that ought to inspire some heated
> replies.  :)

I am not sure what my goals are.

I guess I am trying to take what things I think are good from varius
languages and trying to combine them in a form that is useful to users.

basic, albeit crappy, has generally been able to become the language of
newbies. it has a generally cruddy, line oriented, but somewhat verbose
syntax and reasonably obvious semantics.

however, I also like languages to be sufficiently powerful that I can get
stuff done with them. I also hope for acceptable performance. I hope it can
be reasonablye asily adapted to distributed operation, and will not
generate too much syncronization work.
additionally I hope it will be useful as an add on scripting language as
well.

I have decided to use a syntax which is an indentation based hybrid of
scheme and basic syntax (I guess). the syntax aims to be consistent enough
so that it is possible to easily extend the language.
I want a reasonably powerful and flexible object system which allows easy
alteration of object, intended for game objects or other scripting type
purposes.

this asks too much, I don't really know.

--
<cr88192[at]hotmail[dot]com>
<http://bgb1.hypermart.net/>



Sun, 06 Feb 2005 05:47:04 GMT  
 early language design.
This response contains a *lot* of quoted text to establish context.

Quote:

> I am asking for comments on a early partial design for a language. at
> present I have not really gotten any comments (either good or bad).

Well if you *really* want comments....

Quote:
> the first object on a line is either a function call or an object.

The first token?  Identifier?  Is it looked up?

Quote:
> any lower lines with a higher indentation are also considered as functional
> arguments to a given function, thus functional arguments will naturally be
> the last arguments to a function.

Grouping by indentation is ok for people, but *bad* for machines.
Here are some of the problems:

    1.  There are several whitespace characters and they are easy to
        confuse with each other.

    2.  You will be unable to manipulate programs with tools that do
        not preserve whitespace identity.  Some mail programs, for example.

    3.  Print-read consistency becomes *much* harder to maintain.

    4.  Non-standard indentation cannot be used.  (Non-standard indentation
        comes in handy sometimes when you need to emphasize a particular
        construct.)

Quote:
> a line may be terminated with '\' indicating it is continued on the next
> line.

What if the last visible character is `\', but there is trailing whitespace?

Quote:
> for the next line indentation is considered unimportant, however a
> good apprach would be to indent it more than one would indent any following
> subexpressions, or the same if none exist.

> parenthesis may also be used to indicate nested functional arguments on the
> same line:
> function ... (function args...) ...

> also infix notation may be supported:
> arg function
> arg function args...

Can the user define new infix operations?  Can he redefine an infix
operation to be a prefix one?

Quote:
> however the order of operations at present will not be defined based on the
> requirement that nested expressions require parenthesis...

> in cases where it is possible for both prefix and infix evaluation to
> occure, prefix will be the default. thus in this case prefix may be used to
> clarify certain constructs.

> consider:
> 'new object' vs. 'object new'. it would seem that new would be the default
> in both, however in the second object could default to taking the 'new' as
> an argument, thus calling it's 'new' function.

No generic functions?

Quote:
> at present I will define symbols to contain letters, numbers, or one of the


What about these:

is-this-an-identifier  x:=y+7

Quote:
> the exeption will be + or - followed by a number, in which case it is
> considered as a sign identifier and a number.
> I will define symbols to be case insensitive, and to have lower case as the
> default. some symbols by convention will be written in upper case, but this
> has no real effect on the language.

Good!

Quote:

> 'object this will have the same behavior as in lisp, ie: the object will
> not be evaluated.

> #\character will represent an individual character, character will be the
> character itself.

What is the namespace of characters?

#\small-latin-a-with-circumflex

Quote:
> #\code will represent a character by it's code.

What coding system?

Quote:
> code will either be numeric (hex, required to start with a number), or a
> special nmonic for the character.
> all characters will be required to be seperated by a space, and any value
> which consists of multiple characters will be a code.
> #\a => 'a'
> #\0A => '\n'
> #\space => ' '

> numbers and strings will follow the usual rules.

> // will be used for line comments, with /* and */ for block comments.

Do block comments nest or not?

Quote:
> the language will be dynamically typed and lexically scoped, and I will
> make the requirement that it be tail recursive.

Good!

Quote:
> conceptually there will only be a few primative types: numbers, characters,
> arrays, and environments.
> there will be a special array referred to as a cons, this will have 2 slots
> called head and tail.

So would *any* 2-element array be a cons?  Would all conses be arrays?

Quote:
> strings and symbols will be considered an array of characters.

> (items...) will be used to represent a list.
> a list will be composed of cons cells, each of which will have the data
> item in head and the remainder of the list in tail.
> another form is
> (items... . item) which will represent a list with item placed in the final
> tail.
> () will be an empty list, this will be considered a value in itself.

> #(items...) will represent a array containing the items.

> constructs accepting multiple forms will evaluate left to right and will
> return the value of the last form.

> if an expression is opened, ie: with ( it is still required to be line
> broken and ended with ).
> ex:
> (begin
>         display "1\n"
>         display "2\n")
> is valid.

> but:
> (1+
> 2)
> is not, and:
> (1+ \
> 2)
> is.

> a requirement is that sub expressions on lower lines still need a higher
> indentation than the parent line.

> true and false will be values:
> T and F, corresponding to true and false respecivly.
> there will also be NULL, which will be considered distinct from ().

> Definitions

Definitions only occur at top level?

Quote:

> define variable
> define variable value
> define (variables...)
> define (variables...) values...
> defines variable, and assigns value to it if a value is given.
> define will only create a new binding but will not change any previous
> ones.
> in the case where it is given lists of variables or a variables list and
> values it will bind multiple variables at the same time. the variables and
> values are to be the same in number.

> redefine ...
> will have the same syntax as define however if the variable exists it will
> be assigned rarther than creating a new binding.

What happens if I DEFSPECIAL inside a lexical block?

Quote:
> defspecial variable
> defspecial variable value
> despecial (variables...)
> despecial (variables...) values...
> defines a special variable, special variables differ from normal ones in
> that they follow dynamic scoping rules.
> defining multiple special variables with the same name serves little
> practical purpose as only the last defined value is used.

> function name (args...)
>         forms...
> function name args_lst
>         forms...
> defines a function called name. multiple functions may be defined with the
> same name in which case the last definition which matches will be used.

Matches in what way?

- Show quoted text -

Quote:
> at present I will define that args may be either symbols or literals, where
> a function match is considered if the values are equal.
> _ will be usable as a value which will allways match (except if the arg is
> not present).

> having a symbol in the tail position, or having a symbol for an args list
> will specify that the function accepts a variable number of arguments.
> extra arguments will be passed to the function in the form of a list.

> lambda (args...)
>         forms...
> lambda args_lst
>         forms...
> will create an anonymous function which accepts args, anonymous functions
> have the advantage that they can be passed as variables without needing to
> be bound.

> let (variable value)
>         forms...
> letrec (variable value)
>         forms...
> let ((variable value)...)
>         forms...
> letrec ((variable value)...)
>         forms...
> will bind variable to value in each list and then invoke forms with the
> variables bound.
> in let the bindings are not in effect when each value is evaluated, however
> in letrec they are, possibly allowing mutually recursive functions.

> Objects And Environments

There are so many paradigms for object-oriented programming that it
is hard to come up with one that satisfies everyone.  I think if you
attempt to integrate objects and environments in the way you have
described that you will run into some interesting (and intractable)
problems, but you'll find them soon enough.

Quote:
> objects and environments will be considered roughly analogous.
> an object will just be an environment with a few special functions bound.

> the structure will be that of a pair of variable dimensional trees, the
> trees are to have matching structure however one contains symbols and the
> other objects. any symbol denotes a leaf and thus indicates that spot on
> the tree to contain data. I will define that either tuples or lists may
> compose an object.
> likely this will need to be optimized, however the exact implementation of
> the environment is outside this spec.

> this will use a variation of a prototype object system.

Prototype object systems don't seem to interact with lexical scoping
that well (in my experience).

- Show quoted text -

Quote:

> all the top level forms of an object will be the implicit  constructor.
> in cases where any "normal" operator is being used with the object the
> object is to be used first in order to allow it to override the operator,
> placing the operator in prefix position may be used to be more explicit.

> General Object Minipulation
> clone object
> clones an object, by duplicating both lists. it does not call a
> constructor, also it ignores any "clone proof" parts of the tree.

> self, which will be bound on clone within the object to the resulting
> object.
> parent will also be bound to it's previous self.

> one can check if an object is an ancestor of another first by comparing the
> self value, then stepping along parent and comparing each one with the self
> of the other.

> an implementation is free to create both self and parent as builtin
> variables, this may allow for more efficiency in some places (ie: checking
> for ancestory, where one could implement parent as a list).

> exec object
>         forms...
> executes forms within the object's environment. this will be useful for
> mutating the object.

Scoping?  (let ((x 22)) (exec foo
...

read more »



Sun, 06 Feb 2005 05:47:06 GMT  
 early language design.

Quote:


>> does it really suck that bad?...

> suckiness has many orders.  lots of people filter on higher-ordered
> suckiness factors, like how they perceive the tone of your posts, or
> whether or not you've demonstrated due diligence in researching their
> areas of expertise.  the thinking goes: if these factors flag suckiness
> probably first-order suckiness is also indicated.  sometimes it's
> difficult to get good feedback because it's difficult to find the right
> questions because it's difficult to know what questions others have
> asked already and have answered in their own minds.

> from recent (6mo) history, i notice that you have started a compiler
> project.  being a compilation dilletante, i am more interested in
> hearing about that than in hearing about a new language.  if you have
> abandoned the project, i am interested in hearing what you learned,
> including what you learned about yourself.  also, i am always interested
> in source code, especially if i can use it freely.

a reasonably recent version should be available on my site, it can give
ideas as to the general organization.
all the code which I have written is in the public domain...

it keeps being reused and rewritten, then ends up being part of another
project. later on I rip it out and add on a few features, then it gets
embeded in something else.
my compiler recently has been getting altered to make it handle my new
language design. most of the changes so far has been a new parser, cleaning
up some bits of the compile process, and changing the semantics of some of
the compiler supplied macros.

for the new syntax some more information needs to be stored during the
compile process (such as some info about definitions: function, macro, ...).
I am making it so that such information is available with the compile time
bindings (mostly the builtins will use "dummy headers" to flag types...).
it is possible I could also use such information for optimization purposes
(the compiler could determine that a variable is not assigned, as
assignment will be flagged in the variable...).
also, real bindings would be available in cases of interpreter compilation,
thus I may be able to make better use of such bindings (or I could continue
as before...). before there tended to just be a tree of symbols available,
with no type info and no bindings, now this is not enough. this should
still not be noticable to the user, as it just effects compilation...
(actually now I should be able to implement a macro system as well, as an
effective means of identifying macros exists...).

the structure of environments has been changed, before they were forced to
a list, with lists of bindings. the structure has been relaxed such that
either symbols or sub lists can exist at any point, now other structures
should be possible (ie: joined environments). symbol lookup can use a
"trace" which indicates the position in each list of the requested data.
still some issues here need to be resolved (in the case of var retrieval
efficiency). it is likely that lambda lists and let bindings will be packed
into vectors. luckily it is allready established that the compile time
binding tree structure will match that available at run time...

anything else?...

--
<cr88192[at]hotmail[dot]com>
<http://bgb1.hypermart.net/>



Sun, 06 Feb 2005 06:29:16 GMT  
 early language design.

Quote:

> This response contains a *lot* of quoted text to establish context.



>> I am asking for comments on a early partial design for a language. at
>> present I have not really gotten any comments (either good or bad).

> Well if you *really* want comments....

>> the first object on a line is either a function call or an object.

> The first token?  Identifier?  Is it looked up?

this was ambiguous, I meant "parsed object", which includes any constants
and identifiers. if it is an identifier then it is looked up to determine
if it is a function.

Quote:
>> any lower lines with a higher indentation are also considered as
>> functional arguments to a given function, thus functional arguments will
>> naturally be the last arguments to a function.

> Grouping by indentation is ok for people, but *bad* for machines.
> Here are some of the problems:

>     1.  There are several whitespace characters and they are easy to
>         confuse with each other.

>     2.  You will be unable to manipulate programs with tools that do
>         not preserve whitespace identity.  Some mail programs, for
>         example.

both these have been resolved by kinds of parser kludge, ie: a tab is
considered as being 8 chars thick. it should be adjustable, but generally I
will discourage really mixing tabs and spaces...

Quote:
>     3.  Print-read consistency becomes *much* harder to maintain.

yes, since it uses more or less the same printer as before it dumps out
code in a lispish syntax...

Quote:
>     4.  Non-standard indentation cannot be used.  (Non-standard
>     indentation
>         comes in handy sometimes when you need to emphasize a particular
>         construct.)

yes, a good point. more indentation is fine if it does not interfere with
deeper nested structures. less indentation could be a problem.

mostly it will force a certain indentation though...

Quote:
>> a line may be terminated with '\' indicating it is continued on the next
>> line.

> What if the last visible character is `\', but there is trailing
> whitespace?

it is ignored. at present '\' is used mostly to tell the parser to ignore
the newline.

Quote:
>> for the next line indentation is considered unimportant, however a
>> good apprach would be to indent it more than one would indent any
>> following subexpressions, or the same if none exist.

>> parenthesis may also be used to indicate nested functional arguments on
>> the same line:
>> function ... (function args...) ...

>> also infix notation may be supported:
>> arg function
>> arg function args...

> Can the user define new infix operations?  Can he redefine an infix
> operation to be a prefix one?

ok, I need to clarify this:
technically there is little difference between prefix and infix operations.
any prefix can be used as an infix and vice versa...

both + 2 3 and 2 + 3 will work.

Quote:
>> however the order of operations at present will not be defined based on
>> the requirement that nested expressions require parenthesis...

>> in cases where it is possible for both prefix and infix evaluation to
>> occure, prefix will be the default. thus in this case prefix may be used
>> to clarify certain constructs.

>> consider:
>> 'new object' vs. 'object new'. it would seem that new would be the
>> default in both, however in the second object could default to taking the
>> 'new' as an argument, thus calling it's 'new' function.

> No generic functions?

generic functions can be defined, but it is quite likely that they would
need to be used in prefix position to avoid confusing the compiler.
a good fix is needed.

it is likely that some more object manipulation functions will be needed.

Quote:
>> at present I will define symbols to contain letters, numbers, or one of

>> number.

> What about these:

> is-this-an-identifier  x:=y+7

both are identifiers in the present design. to get the expected behavior in
the second you would have to write:
x := (y + 7)
it sucks, I know...

Quote:

>> 'object this will have the same behavior as in lisp, ie: the object will
>> not be evaluated.

>> #\character will represent an individual character, character will be the
>> character itself.

> What is the namespace of characters?

> #\small-latin-a-with-circumflex

this would be under the code catagory.
the "characters" include the normally typable characters.
#\a #\& ...

Quote:
>> #\code will represent a character by it's code.

> What coding system?

>> code will either be numeric (hex, required to start with a number), or a
>> special nmonic for the character.
>> all characters will be required to be seperated by a space, and any value
>> which consists of multiple characters will be a code.
>> #\a => 'a'
>> #\0A => '\n'
>> #\space => ' '

this coding system, likely extended to unicode.

Quote:
>> numbers and strings will follow the usual rules.

>> // will be used for line comments, with /* and */ for block comments.

> Do block comments nest or not?

I have not decided on this yet.

Quote:

>> conceptually there will only be a few primative types: numbers,
>> characters, arrays, and environments.
>> there will be a special array referred to as a cons, this will have 2
>> slots called head and tail.

> So would *any* 2-element array be a cons?  Would all conses be arrays?

need to clarify, cons is a seperate type from other arrays.

Quote:

>> Definitions

> Definitions only occur at top level?

many will, I will also allow them to occure in nested blocks but I require
that they largely follow the same semantics (or that they all behave like
let...).
Quote:

>> define variable
>> define variable value
>> define (variables...)
>> define (variables...) values...
>> defines variable, and assigns value to it if a value is given.
>> define will only create a new binding but will not change any previous
>> ones.
>> in the case where it is given lists of variables or a variables list and
>> values it will bind multiple variables at the same time. the variables
>> and values are to be the same in number.

>> redefine ...
>> will have the same syntax as define however if the variable exists it
>> will be assigned rarther than creating a new binding.

> What happens if I DEFSPECIAL inside a lexical block?

it should extend to all lexically visible code.

- Show quoted text -

Quote:

>> defspecial variable
>> defspecial variable value
>> despecial (variables...)
>> despecial (variables...) values...
>> defines a special variable, special variables differ from normal ones in
>> that they follow dynamic scoping rules.
>> defining multiple special variables with the same name serves little
>> practical purpose as only the last defined value is used.

>> function name (args...)
>>         forms...
>> function name args_lst
>>         forms...
>> defines a function called name. multiple functions may be defined with
>> the same name in which case the last definition which matches will be
>> used.

> Matches in what way?

mostly like how it is in haskell.
function f (a) a
function f (()) 'a
function f (0) 'b

f 0 => b
f () => a
f '(1 2 3) => (1 2 3)

except in reverse order, so the most general will need to come first.

Quote:

>> Objects And Environments

> There are so many paradigms for object-oriented programming that it
> is hard to come up with one that satisfies everyone.  I think if you
> attempt to integrate objects and environments in the way you have
> described that you will run into some interesting (and intractable)
> problems, but you'll find them soon enough.

maybe. this just seemed cool though...

- Show quoted text -

Quote:

>> objects and environments will be considered roughly analogous.
>> an object will just be an environment with a few special functions bound.

>> the structure will be that of a pair of variable dimensional trees, the
>> trees are to have matching structure however one contains symbols and the
>> other objects. any symbol denotes a leaf and thus indicates that spot on
>> the tree to contain data. I will define that either tuples or lists may
>> compose an object.
>> likely this will need to be optimized, however the exact implementation
>> of the environment is outside this spec.

>> this will use a variation of a prototype object system.

> Prototype object systems don't seem to interact with lexical scoping
> that well (in my experience).

maybe, I don't know.

Quote:

>> exec object
>>         forms...
>> executes forms within the object's environment. this will be useful for
>> mutating the object.

> Scoping?  (let ((x 22)) (exec foo (+ x 3)))

> Does the second X refer to the instance variable named X in object foo?

it would refer to the one found in foo.
this one could be difficult though...

Quote:

>> object args...
>> when an object is used as a function it will work by looking up the
>> symbol indicated by the first arg, returning that value if it is not a
>> closure or object, otherwise it will apply it with the remaining args.
>> prefixing the last arg with a _ may be used to alter this behavior, in
>> which case it will just return the value rather than trying to apply it.

> But how can I do computed dispatch?

> (let ((method (ask-user-for-method)))
>   (object method args))

this could be a problem. likely I will need a special function for this...

an idea could be: ((get object method) args)

Quote:
>> not     accepts only 1 argument, returns T if a is F, F otherwise.

>> Macros

> Infix macros?

yes. as stated before there is little difference between prefix and infix
notation, thus the same rules apply as for functions.

I am nowhere near a completed design, thus comments are helpful in finding
issues which need to be fixed...

--
<cr88192[at]hotmail[dot]com>
<http://bgb1.hypermart.net/>



Sun, 06 Feb 2005 07:17:27 GMT  
 early language design.

|
| > This response contains a *lot* of quoted text to establish context.
| >
| >


| >> I am asking for comments on a early partial design for a language. at
| >> present I have not really gotten any comments (either good or bad).
| >
| > Well if you *really* want comments....
| >
| >> the first object on a line is either a function call or an object.
| >
| > The first token?  Identifier?  Is it looked up?
| >
| this was ambiguous, I meant "parsed object", which includes any constants
| and identifiers. if it is an identifier then it is looked up to determine
| if it is a function.

Why the separation of objects & functions?  Couldn't you have a
GenericFunction class and have all generic functions actually be
objects, as well?

--

     -- Tim Olson



Sun, 06 Feb 2005 09:41:38 GMT  
 early language design.

Quote:




> |
> | > This response contains a *lot* of quoted text to establish context.
> | >
> | >


> | >> I am asking for comments on a early partial design for a language. at
> | >> present I have not really gotten any comments (either good or bad).
> | >
> | > Well if you *really* want comments....
> | >
> | >> the first object on a line is either a function call or an object.
> | >
> | > The first token?  Identifier?  Is it looked up?
> | >
> | this was ambiguous, I meant "parsed object", which includes any
> | constants and identifiers. if it is an identifier then it is looked up
> | to determine if it is a function.

> Why the separation of objects & functions?  Couldn't you have a
> GenericFunction class and have all generic functions actually be
> objects, as well?

I think you miss the point.

function a (b c)
        b * c

the first "parsed object" is the symbol "function", followed by "a" then a
list containing "b" and "c", ... an object is not it's name, rather it is
referred to by it's name...

otherwise a function is a kind of object (which I refer to with the more
general term "closure").

in my design objects are a kind of tweaked out closure, however I had
considered this "not very important" at the current time.

a pride (or possibly flaw) of my object system is that I don't include
classes, rather new objects are created by cloning others...

--
<cr88192[at]hotmail[dot]com>
<http://bgb1.hypermart.net/>



Sun, 06 Feb 2005 11:56:23 GMT  
 early language design.

Quote:
> a pride (or possibly flaw) of my object system is that I don't include
> classes, rather new objects are created by cloning others...

That's like Self. Take a look at Self. It's called a Prototype based
system instead of a Class based system.


Sun, 06 Feb 2005 12:43:36 GMT  
 early language design.

Quote:


> > I will define symbols to be case insensitive, and to have lower case as the
> > default. some symbols by convention will be written in upper case, but this
> > has no real effect on the language.

> Good!

Given the existence of Unicode and the increasing meaninglessness of lower vs
upper case, perhaps modern languages ought to be case sensitive after all.

If a language is restricted to ASCII, then case insensitivity is well defined
and makes good sense.

But if a language allows general Unicode characters case is no longer well
defined.  Making the language be case sensitive neatly avoids the whole issue
(i.e. the language has "characters" and a character is what it is, period).

The original problems with case-sensitive languages are not *that* bad.
--
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,



Sun, 06 Feb 2005 15:20:43 GMT  
 early language design.

Quote:

> true and false will be values:
> T and F, corresponding to true and false respecivly.
> there will also be NULL, which will be considered distinct from ().

Use #t, #f, and #null (or #nil) instead. That way they won't interfere with
symbols of the same name.

A common grief for me when writing language modes in Emacs lisp was that I
could not use 'nil as a regular symbol (e.g. in a list that represents, say, a
language's keywords, like Delphi), since it had its special meaning.

--
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,



Sun, 06 Feb 2005 15:24:07 GMT  
 early language design.

Quote:

> Given the existence of Unicode and the increasing meaninglessness of lower vs
> upper case, perhaps modern languages ought to be case sensitive after all.

> If a language is restricted to ASCII, then case insensitivity is well defined
> and makes good sense.

> But if a language allows general Unicode characters case is no longer well
> defined.  Making the language be case sensitive neatly avoids the whole issue
> (i.e. the language has "characters" and a character is what it is, period).

> The original problems with case-sensitive languages are not *that* bad.
> --
> Cheers,                                        The Rhythm is around me,
>                                                The Rhythm has control.
> Ray Blaak                                      The Rhythm is inside me,


i don't understand your message.  you use the words

Given, If, But, Making, The, Cheers, and Rhythm

am i to assume these have the same meaning as the words

given, if, but, making, the, cheers, and rhythm

respectively?



Sun, 06 Feb 2005 16:18:04 GMT  
 
 [ 25 post ]  Go to page: [1] [2]

 Relevant Pages 

1. early language design 2

2. early language design.

3. early language design 2

4. A bad design decision early on in A

5. early teaching languages

6. Early Ada History: Whitaker on the Language Evaluations

7. Design criteria for languages

8. programming language sensitive design

9. Program Design Language (PDL)

10. Evolution toward greater SAFETY in language design

11. CFP: ECOOP'97 Workshop on Language Support for Design Patterns and Frameworks (LSDF'97)

12. programming language sensitive design

 

 
Powered by phpBB® Forum Software