Re: [Felix-language] pattern calculus

Peter Tanski Sun, 10 Sep 2006 17:07:19 -0700

James Dennett wrote:

Peter Tanski wrote:

On Sep 10, 2006, at 1:31 AM, skaller wrote:

On Sun, 2006-09-10 at 00:50 -0400, Peter Tanski wrote:

On Sep 8, 2006, at 9:49 PM, skaller wrote:

Regarding C++ template type notation, why did you choose square
brackets for the list of predicates, instead of angle brackets?

Because < and > are comparison operators?

'<' and '>' are comparison operators in C++ as well and in C++ they
are used to mark template parameters. It all depends on context.

And this is the single biggest impediment to writing a simple but robust
parser for some aspects of C++, as understanding enough of the context
to know whether < is an operator or a delimiter requires the ability to
tell if a name is a template, which requires the ability to instantiate
templates, including performing overload resolution. Without this
level of language knowledge, it's not even possible to robustly pick
out where top-level declarations begin and end in C++ code (so far
as I can determine).

Thanks for the insight. Felix must also perform a little semantic analysis while parsing because function names (though prefixed with 'fun') and certain keywords, such as 'list' and 'typeclass' are appended with square-bracketed material:

fun f[T1,T2]

typeclass[T1,T2]

list[int]

It might be better to separate things with keywords and whitespace, terminated with a period or parenthesised. Compare:

fun new_function[T] (x:T,y:T):T = { ... }

with

new_function :: forall T. (T,T) -> T

new_function x y = ...

and

new_function :: (forall a.) => (a,a) -> a

new_function x y = ...

with only a minimal knowledge of the semantics, which is more readable? (The original form is certainly compact.) Note: in the Haskell form of the last function, the function type signature (declaration) may be left out because the types may be inferred; this is also true for the types and the return type in Felix, in most cases:

fun new_function (x,y) = { ... }

Felix does allow ML-style syntax:

fun new_function : (T,T) -> T =

| (?x,?y) => ...

which is readable but is limited to match expressions since it has no other way to resolve the names of the parameters, as an alternative form of:

fun new_function(x:T,y:T):T =

match (x,y) with

| (?n,?m) => ...

and I do not know whether it allows type constraints:

fun new_function[T] : (T,T) -> T ...

The
consequence of the C++ "maximum munch" parser, where trailing
embedded template parameters need a space "vector<int, Allocator<T>
should have been done away with a long time ago.

It has been done away with now, in the working paper; the next C++
standard will allow
std::vector<int, Allocator<T>>
though at the cost of a little more complexity in the compiler and standard
and the possibility of breaking some obscure existing code.

-------------------------------------------------------------------------
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

Re: [Felix-language] pattern calculus

Reply via email to