On Sep 4, 2006, at 6:25 AM, skaller wrote:
> On Sun, 2006-09-03 at 19:37 -0400, Peter Tanski wrote:
>
>>> so the only difference is that in my form an explicit pattern
>>> is parsed and used to identify the variables, and the shape
>>> of this pattern acts as a limitation: Jay removes that limitation.
>
> And btw I have just rewritten code so that the type encoding
> now allows for 'match varibles' within types, which eliminates
> the need to duplicate the type encoding inside the type
> pattern encoding. This makes the 'typematch' as general
> as the pattern calculus with some futz which reduces the
> general types to one with the 'variable tag' removed.
Good job!
> [Felix uses ?x to denote a variable in patterns, which
> is a bit ugly]
I caught the ?v requirement in pattern matches. That's o.k.; it's
your language. If I were defining my own language I would scrap the
whole Erlang-syntax set in favor of more advanced parsing using
layout rules. If I were creating a language using the technology
available today (i.e., parsers, reasoners) all those trailing colons,
curly-bracketed code blocks, etc. may be available to programmers--
even Haskell allows them for patterns defined contrary to layout
rules--but they literally get in the way of the programmer's ability
to read the program and reason about its operations. If I wanted a
more procedural layout I would probably follow Ada or Fortran rules
for sequences. Likewise declarations for "fun," make it easier to
write a parser and might seem nice to ML users but they are messy and
smack of a primitive parsing strategy (not a good indicator of the
other capabilities in the system); worse, they are a novelty to
programmers coming from C/C++. Functions may be denoted by requiring
the first letter of the function name be lower-case, otherwise by
context; for types the first letter (and only the first letter)
should be upper case, the first definition in a union should not
require '|', as in that circumstance it is superfluous, etc. (This
is not a recommendation, just a statement of what I would do.)
> An interesting (and purely syntactic!) quandary:
> Here:
>
> 1 + int * list as list
>
> the 'as' form is a fixpoint binder denoting recursion.
> But here:
>
> match xx with | (_ * ?y) as z =>
If you want to keep one of the two uses of "as," keep "as" for
pattern matches: it is used this way in other languages (exactly this
way in OCaml, in Haskell the equivalent is z@(_,y)) so it is more
intuitive for the programmer; because 'as' is used to create synonyms
for pattern bindings in other languages the 'as' form for 1 + int *
list as list is confusing. On a practical level, if you want to
limit implicit recursion in type declarations--not recommended!--it
would be more intuitive if you defined the recursive types in the
name, such as:
union rec Tree =
| Leaf of Tree * Tree
| Tip int
What I would use is:
union Tree = Leaf (Tree * Tree)
| Tip int
--although the 'union' keyword is itself confusing to programmers
coming from C or C++; it is not apparent from context that this
construction doesn't map the two over the same region of memory.
I don't recommend requiring an explicit keyword to allow recursion in
type declarations because *that* is also confusing. Programmers
should know recursion when they see it; the recursive struct
declaration is well known to C programmers for algorithms such as
trees and linked lists, while (I believe--at this point anything I
say could be wrong about Felix) in Felix recursive structs are
allowed. It would be better to have recursion for type definitions
consistent across all types; if you allow recursion in structs and
records (again, not sure) you should also allow recursion in unions.
> the 'as' is an assignment naming a type, i.e. a typedef
I reiterate what I said in a previous email. If your intention is to
map the learning curve for programmers from:
C++ -> Felix -> ML -> Haskell
Either get rid of keywords such as 'typedef' that are used in C/C++
or use them in the same or similar way to how they are used in C/C++
(in your explanation here you seem to). At this point Felix is
working backwords--only someone already familiar with OCaml would
understand that 'typedef' in Felix is similar to typedef in OCaml;
someone (myself included) who knows C/C++ sees 'typedef' in a
language that is the "successor to C++" and thinks: "oh, I get it; a
typedef is a synonym and has the same syntax!"
> inside a pattern. These things are correlated, and they can
> be distinguished by whether there is an inner occurence
> of the introduced variable.. but this is not really
> desirable, to have two meanings of 'as' .. but I can't
> think of any other solution. Well you could use
>
> fix[list] 1 + int * list
>
> for the fixpoint .. but I actually find the Ocaml 'as'
> quite readable (although the precedence is obscure).
Use the Haskell synonym@(pattern) construct.
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Felix-language mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/felix-language
