I think the #true thing is not bad. It may be worth considering treating
special cases like that as if "true" were a boolean literal rather than an
identifier, and doesn't require a parameter. But that said, #true isn't
that bad. In LISP they always write #t and it doesn't bother people much.
I've been playing around with Stratego/XT and they decided to use a rule
"if it's undefined, bind it - if it has a value already, match it" It's
bitten me many times where I thought I was binding a new variable but
actually there was already a variable bound with that name so it tried to
match instead and failed. So ... that's an error-prone path to avoid
despite allowing even less syntax. Having it syntactically clear whether
one is binding or matching is definitely better for readability.
On Mon, Dec 24, 2012 at 10:28 PM, john skaller <
skal...@users.sourceforge.net> wrote:
> because pattern matching is desugared early, before lookup or typing, Felix
> requires you to write
>
> match x with | Int ?i => ...
>
> You can also write
>
> val ONE = 1;
> match x with | $(ONE) => ...
>
> to match a value, which just means
>
> match x with | _ as tmp when tmp == ONE => ...
>
> Anyhow the need for $ and ? is because we have to tell, syntactically,
> the difference between a constructor name, a value, and a pattern variable.
> So plain names are constructors, values need a $, and pattern variables
> need a ? in front.
>
> It's inconsistent, because really one should regard function calls and val
> bindings as pattern matches:
>
> let ?x = 1 in ..
>
> looks plain ugly.
>
> However, this is almost unambiguous:
>
> match x with | Int i => ...
>
> Given we don't allow values except in $(expr) that i pretty clearly meant
> to be a variable.
>
> The confusing case is this one:
>
> match x with | true => ..
>
> i.e. where we have an constant constructor. Note the argument of Int might
> also be
> a constant constructor, we cannot be sure. However, ATS solves this problem
> by simply requiring "argumentless" constructors to really have a unit
> argument
> in some sense, and writing it:
>
> match x with | true () => ...
>
> The extra () here (which in Felix might be rewritten #true) is only needed
> in patterns,
> and if we insisted on this we can dispense with the need for ? before
> variables by
> observing that constructors always have arguments .. so something without
> an
> argument is a pattern variable. It might be a pain to write
>
> true () or even #true
>
> in code everywhere (though the latter is not bad) but we're only talking
> about
> patterns here.
>
>
> --
> john skaller
> skal...@users.sourceforge.net
> http://felix-lang.org
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Felix Language" group.
> To post to this group, send email to felix-langu...@googlegroups.com.
> To unsubscribe from this group, send email to
> felix-language+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/felix-language?hl=en.
>
>
------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
