On 20 March 2010 06:25, Jonathan S. Shapiro <[email protected]> wrote:
> On second thought, Ben may have been on the trail of a good idea.
>
> Instead of reserving capital latin letters for type variables, why not
> reserve lowercase greek letters, and then define 'a, 'b, etc. as
> convenience syntax for these...
>
> Or alternatively, stick with the 'blah as the canonical form, but
> accept the corresponding greek characters as convenience syntax.
>
> Not sure I love it, but it's a thought.
>
You wanted your bike shed to get a new paint so let's see what the
paint shops have in stock.
I for one can type small Greek letters quite easily right now because
I installed some fancy input method which I did not set up so far and
it defaults to Greek as the alternate input. Still this is only on one
machine, only in X, and it will likely not last long.
That said I am set up for writing in full Unicode and I could probably
set up a Math table to input not only Greek but stuff like
๐๐
๐น๐ญ๐ก๐๐๐ฝ๐ฑ๐ฅ๐๐๐ ๐ผ๐ถ๐ฐ๐ชโชโซโฎโฌโฌโถโผโพโนโฆ
โฆโจนโจบโจปโฉโฉ
Note that *all* the letters above are different from common Latin and
Greek letters.
Unicode also offers a number of interesting miscellaneous shapes like
๐ฝ๐ ๐ก๐ข๐ฃ๐คโโโ โฉโ๐๐๐แแแแแแทแฅแฏแโดฑโดฒโดตโตโตโตฅโตโตโต๐ธ๐น๐บ๐๐๐๐ฐ๐ค๐ธ๐๐๐ฃ
and about 20 different pot shapes (although some were perhaps meant to
be something different) ;-)
๐ฒ๐ธ๐ณ๐ฌ๐๐๐๐ง๐ช๐ ๐ฐ๐ฆ๐จ๐ค๐ฃ๐ฅ๐ฉ๐ข๐ฑ๐ญ๐ฎ๐ซ๐ฏ
I am sure people running Windows and other non-customizable or hard to
customize proprietary systems would mind, though. And so would people
who are too fond of the Linux console which sucks at displaying
anything but ASCII perhaps with a handful of accented characters
thrown in.
I think that the traditional use of symbols that appear on the US
keyboard has its merits. Most programmers are set up for writing these
already because it is the requirement for most other languages, and
most complex input methods use the US layout for Latin anyway.
The lisp-like syntax has only two or three elements of syntax other
than literals : (), whitespace and perhaps comma.
This is simple but the syntax elements are quite overloaded making the
syntax somewhat hard to understand at a glance.
I am not sure how exactly the syntax looks like for multiple arguments.
let's say
(forall ('a 'a) (define (+ x y) (something_with_x_and_y)))
there are way too many ()s, and it's hard to tell which part of the
definition the ()s denote should the definition get longer.
Of the available symbols !%^&*+=<> are most often used for operators,
"' for quoting, comma for list separator, ; for a terminator.
The use of :?!_ is somewhat less fixed, sometimes they get to be part
of identifiers or denote special identifiers, sometimes they get used
as (part of) operators.
#...@$ are typically not used as operators but often denote special parts
of syntax or special identifiers.
(), [ ], {} are most often used for some kind of grouping but () also
for function call, [] for indexing or lists and {} typically for code
grouping.
Since we want to drop current syntax and start with something new I
would say that looking at something that is reasonably simple to write
and parse yet also reasonably simple to read is called for.
I would start with reserving () for general operation grouping to
specify precedence and [,] for list and saying that functions always
operate on a single argument but it can be of a list type, including a
list of particular length.
Of the not so specific symbols you could reserve one for denoting a
type, say a prefix :
Then you can say
def + of [ x of :x, y of :x ] to :x
{something_with_and_y}
or just
def + of [ x,y ]
{something_with_x_and_y}
if you don't need to refer to the types and they can be inferred.
Using some symbols instead of the keywords is certainly possible but
the number of symbols which are relatively easy to type is limited.
For example, all the arrow-like symbols -> => suffer from the issue
that they are composed of shifted and non-shifted character with the
shifted character coming at the end and are thus quite hard to type.
Using just : would be hard to read
def + : [ x : :x, y : :x ] : :x
but perhaps
def + : [ x : @x, y: @x ]: @x
would be usable.
Obviously you can go on endlessly replacing operators, keywords,
rearranging the order of parts of the definition, etc.
In the end one way has to be chosen.
Function application should not need a special notion since we have
only a single argument but to make things easier for peole who are
used to () calls one could perhaps allow for (,) to be equivalent of
([,]) but it would make the parser more ambiguous.
There are also the traditional issues of
- Is = comparison or assignment?
- If it is comparison what is the assignment? the answer is typically
:= which is not a nice operator but still far from the atrocity of ->
and => and XML.
- can there be a multiple assignment like a=b=c=0?
- can assignment be a part of expression and what is the result? This
can solve the problem above by saying that it can, c:=x returns (copy
of)x, and a:=b:=c:=0 is resolved as a:=(b:=(c:=0))
This brings the issue of operators.
In C++ the operators are predefined with fixed arity, precedence and
associativity.
In some languages you can define arbitrary operators like (a mod b)
with arbitrary precedence order and associativity but then the parser
has to be programmable and you can have issues with multiple libraries
wanting different definitions or precedence of operators.
The other thing which is not so hard to define and actually very
useful, especially for interoperability is argument naming.
That is, you do not just define a function which takes a list of 10
arguments but you also name the arguments.
That way if you define something like
def draw_rectangle : [ display: @display_handle, x: @integer, y:
@integer, width: @integer, height: @integer, color: @drawing_color ] :
@drawing_error
and call it like, say
draw_rectangle [ color: Black, x: 0, y: 0, width: display_width,
height: display_height, display: display_handle]
the call should work, and it should work even if later revision of the
library (possibly external library which is just wrapped for bitc)
rearranges order of the arguments.
This can be obviously resolved at compile time to just a list of
anonymous arguments.
Thanks
Michal
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
