Domain Specific Language Research - Revision history

Ed at 17:47, 21 September 2020

2020-09-21T17:47:35Z

Ed at 17:34, 21 September 2020

2020-09-21T17:34:29Z

Ed at 16:29, 20 September 2020

2020-09-20T16:29:11Z

LasyaRajan at 18:10, 5 April 2019

2019-04-05T18:10:36Z

LasyaRajan at 19:24, 19 March 2019

2019-03-19T19:24:31Z

LasyaRajan at 18:58, 19 March 2019

2019-03-19T18:58:22Z

Ed: Ed moved page Domain Specific Language Research - Primary to Domain Specific Language Research without leaving a redirect

2019-03-18T20:30:29Z

Ed moved page Domain Specific Language Research - Primary to Domain Specific Language Research without leaving a redirect

Ed at 20:30, 18 March 2019

2019-03-18T20:30:20Z

Ed at 20:20, 18 March 2019

2019-03-18T20:20:02Z

Janice: Created page with "{{Task |Project Component=Listing Page Extractor |Has Task Description=Domain Specific Language Research - Primary |Has Start Date=2019/03/12 |Has Target Completion Date=2019/..."

2019-03-18T14:12:19Z

Created page with "{{Task |Project Component=Listing Page Extractor |Has Task Description=Domain Specific Language Research - Primary |Has Start Date=2019/03/12 |Has Target Completion Date=2019/..."

New page

{{Task
|Project Component=Listing Page Extractor
|Has Task Description=Domain Specific Language Research - Primary
|Has Start Date=2019/03/12
|Has Target Completion Date=2019/03/15
|Has Team Member=Lasya Rajan,
|Has Task Status=In Progress
}}

@@ Line 1: / Line 1: @@
 {{Project
-|Has project output=
+|Has project output=Tool
 |Has sponsor=Kauffman Incubator Project
 |Has title=Domain Specific Language Research

@@ Line 1: / Line 1: @@
 {{Project
 |Has sponsor=Kauffman Incubator Project
 |Has title=Domain Specific Language Research

@@ Line 1: / Line 1: @@
 {{Project
 |Has title=Domain Specific Language Research
 |Has owner=Lasya Rajan

@@ Line 6: / Line 6: @@
 |Has project status=Active
 }}
 ==Background==

← Older revision		Revision as of 19:24, 19 March 2019
Line 34:		Line 34:
	===Time and Feasibility of Development===		===Time and Feasibility of Development===

−	The time required for this development would vary depending on the complexity of the DSL language structure. For the example in “Project Goal v2,” I would assume a rough estimate of 20-25 hours for one person to develop it with no prior knowledge of developing a DSL, allotting 5-10 hours for debugging/ thorough unit testing. Whether a compiler/interpreter would need be to written would also be a significant variable in the total time necessary to develop the DSL. However, from my preliminary research, I believe the attributes of the above DSL are a good fit to express the output of the proposed HTML parser, and developing such a DSL would be a manageable and achievable goal.	+	The time required for this development would vary depending on the complexity of the DSL language structure. For the example in “Project Goal v2,” I would assume a rough estimate of 25-30 hours for one person to develop it with no prior knowledge of developing a DSL, allotting 5-10 hours for debugging/ thorough unit testing. Whether a compiler/interpreter would need be to written would also be a significant variable in the total time necessary to develop the DSL. However, from my preliminary research, I believe the attributes of the above DSL are a good fit to express the output of the proposed HTML parser, and developing such a DSL would be a manageable and achievable goal.

← Older revision		Revision as of 18:58, 19 March 2019
Line 6:		Line 6:
	\|Has project status=Active		\|Has project status=Active
	}}		}}
		+
		+	==Background==
		+
		+	In contrast to General Programming Languages (GPLs), Domain Specific Languages (DSLs) are created to optimize solving problems within a specific domain. While GPLs provide broad functionality, some domains contain a unique architecture that can better modelled by unique abstractions and notations. In addition, the target solution in the domain might not require the full processing power and overhead of a Turing complete GPL. When presented with such a domain, and such a target solution, a DSL can be a powerful tool.
		+
		+	===DSL Advantages===
		+
		+	The specificity of a DSL provides several key advantages. Namely, domain-specific constructs can be emulated within the language, increasing efficiency of runtime and accuracy of output. Efficiency can be increased by creating notation that reduces redundancy for repetitive functions within the domain. Specialized compilers and error-checkers can be programmed to enforce domain constraints, improving accuracy of output. Beyond their performance, a subset of DSLs called application domain DSLs can be useful for facilitating program interaction with non-programmers. For example, the software testing DSL Gherkin, written in Ruby, takes natural language syntax and implements it as a software test. Through their ability to create unique idiomatic expressions, DSLs can allow domain experts to interact with data and processing through domain-specific functions and notation.
		+
		+	===DSL Disadvantages===
		+
		+	DSL development also presents a number of disadvantages. Because DSLs require domain expertise and programming expertise, they are difficult to create effectively, and manage long-term over a large user base. DSLs can also often add no new functionality to a GPL, or offer no additional efficiency. These DSLs tend to be scripts that simply “hide” the usage of libraries. However, if a target solution is specific enough, and the abstraction of the domain into the DSL is simple enough, then a true DSL can be built efficiently.
		+
		+	==Project Recommendation==
		+
		+	As suggested by the concept diagram, a DSL could be used to express output of an HTML parser that simplifies web page into a tree structure. (This is in the “Information Detector” cloud of the current version of the diagram, as of 3/15/19.) This is an opportunity for a concise mark-up based DSL. The possible steps in creating this DSL would be:
		+
		+	# Determine a host language. The language’s abstractions should be similar enough to the domain abstractions so that the domain can be concisely implemented. Though I’m unfamiliar with many languages at a level this specific, I would recommend Python, for the relatively simplicity of this DSL.
		+	# Write a concrete syntax. This should include all the features the language supports. For this, we would likely borrow and simplify HTML syntax. The “stack,” “row,” and “footer” elements included on the example could represent categories of DOM elements, depending on how detailed we want this abstraction to be.
		+	# Write the grammar. Many parsing libraries support expressing grammar in ENBF (Extended Backus-Naur form), so defining all the grammar in this format would be efficient.
		+	# Run a parsing library on the grammar expressed in ENBF.
		+	# The output of the specific parsing library will determine the next steps. In the example I am looking at, the parsing library used generates a simple parse tree that is then interpreted by a simple Python function. However, if more complex compiler is necessary, then this would be the point at which to write the compiler to turn the parse tree into efficient byte code.
		+	# With the appropriate linking statements, this simply formulated DSL should run as a call from a Python program. There will likely be two Python files, and one file written in our DSL. The first Python file will contain the implementation for our DSL; the second Python file will be the Python module that the DSL will call and execute indirectly using the DSL; the third file will be the DSL source file written by users.
		+
		+
		+
		+	===Time and Feasibility of Development===
		+
		+	The time required for this development would vary depending on the complexity of the DSL language structure. For the example in “Project Goal v2,” I would assume a rough estimate of 20-25 hours for one person to develop it with no prior knowledge of developing a DSL, allotting 5-10 hours for debugging/ thorough unit testing. Whether a compiler/interpreter would need be to written would also be a significant variable in the total time necessary to develop the DSL. However, from my preliminary research, I believe the attributes of the above DSL are a good fit to express the output of the proposed HTML parser, and developing such a DSL would be a manageable and achievable goal.

← Older revision	Revision as of 20:30, 18 March 2019
(No difference)

@@ Line 1: / Line 1: @@
-{{Task
+{{Project
-|Project Component=Listing Page Extractor
+|Has image=
-|Has Task Description=Domain Specific Language Research - Primary
+|Has title=Domain Specific Language Research - Primary
-|Has Start Date=2019/03/12
+|Has owner=Lasya Rajan
-|Has Target Completion Date=2019/03/15
+|Has start date=2019/03/12
-|Has Team Member=Lasya Rajan,
+|Has deadline date=2019/03/15
-|Has Task Status=In Progress
+|Has keywords=
 }}